Обсуждение: Overhead for stats_command_string et al, take 2
> The bad news is that except in the stats_command_string cases, HEAD > is noticeably slower than 8.1 on the machine with slow gettimeofday. > In the single-transaction test this might be blamed on the addition > of statement_timestamp support (which requires a gettimeofday per > statement that wasn't there in 8.1) ... but in the one-transaction- > per-statement tests that doesn't hold water, because each branch is > doing a gettimeofday per statement, just in different places. > > Can anyone else reproduce this slowdown? It might be only an artifact > of these particular builds, but it's a bit too consistent in my x86 data > to just ignore. You don't perchance have ON_ERROR_ROLLBACK on do you? I did when I tried testing it and ltrace shows plenty of traffic caused by that. Even when I disable it I notice a few odd things. Aside from the rather high number of memset calls (presumably caused by palloc0) why is anything calling htonl at all? This is after the initial connection just executing "select 1" over and over, no inet data types or anything like that. 2771 memset 925 __sigsetjmp 744 strcmp 739 htonl 650 strncpy 556 memcpy 464 strcpy 462 htons 372 malloc 370 free 279 memcmp 186 __errno_location 93 strtol 93 send 93 recv 93 ntohl 93 memchr 93 gettimeofday 92 strncmp 92 sprintf -- greg
Greg Stark <gsstark@mit.edu> writes:
>> Can anyone else reproduce this slowdown? It might be only an artifact
>> of these particular builds, but it's a bit too consistent in my x86 data
>> to just ignore.
> You don't perchance have ON_ERROR_ROLLBACK on do you? I did when I tried
> testing it and ltrace shows plenty of traffic caused by that.
No --- I strace'd the backend and nothing is going back and forth except
"SELECT 1;" and the response to that. I would think the extra BEGINs
would lead to far more overhead than I'm seeing anyway.
> why is anything calling htonl at all?
Protocol message-length words and suchlike, no doubt.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Yep, I see 8% here. I will add a patch to allow the ps display to be > > turned off. > > I think we'd still want a backend to set the PS display once with its > identification data (user/DB name and client address). It's just the > transient activity updates that should stop. Oh, good point. Do we remove stats_command_string? Does it have any measurable overhead? I see a little here, like 1%. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> Oh, good point. Do we remove stats_command_string?
You mean, remove the option to turn it off? I don't think so. Aside
from whatever remaining overhead there is, there's a possible security
argument to be made that one might not want one's commands exposed,
even to other sessions with the same userid.
regards, tom lane
Bruce Momjian <bruce@momjian.us> writes:
> Yep, I see 8% here. I will add a patch to allow the ps display to be
> turned off.
I think we'd still want a backend to set the PS display once with its
identification data (user/DB name and client address). It's just the
transient activity updates that should stop.
regards, tom lane
Tom Lane wrote: > I wrote: > > IIRC, newer BSDen use a kernel call for this, so you should be able to > > measure it on your own machine. Just tweak ps_status.c to force it to > > select PS_USE_NONE instead of PS_USE_SETPROCTITLE to generate a > > comparison case. I'll try it on my old HPUX box too. > > On HPUX, I get a median time of 5.59 sec for CVS HEAD vs 5.36 sec with > ps_status diked out, for the test case of 10000 "SELECT 1;" as separate > transactions, assert-disabled build. So, almost 10% overhead. Given > that the transactions can't get any more trivial than this, that's about > a worst-case number. Not sure if it's worth worrying about or not. > However Kris Kennaway's report a couple weeks ago suggested things might > be worse on BSD. Yep, I see 8% here. I will add a patch to allow the ps display to be turned off. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Oh, good point. Do we remove stats_command_string? > > You mean, remove the option to turn it off? I don't think so. Aside > from whatever remaining overhead there is, there's a possible security > argument to be made that one might not want one's commands exposed, > even to other sessions with the same userid. OK. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +