On Fri, Jan 6, 2012 at 2:24 PM, Robert Haas <robertmh...@gmail.com> wrote: > It's been a while since I did any testing with LWLOCK_STATS defined, > so I thought it might be about time to do that again and see how > things look. Here's how they looked back in July: > > http://archives.postgresql.org/pgsql-hackers/2011-07/msg01373.php > > Here are the results from a test I ran today on latest sources, again > on Nate Boley's machine. Five-minute pgbench run, scale factor 100, > permanent tables, my usual config settings.
What was the tps/or and number of transactions? I assume this was -c80 -j40? Also, do you know what percent of CPU time was spend idle during the test? If the very little time is spend sleeping on lwlocks (i.e. CPU time near 100%), it doesn't matter much how that waiting is distributed. Also, was there a big difference in tps between LWLOCK_STATS defined and not defined (i.e. the overhead of doing the accounting)? > Somewhat depressingly, > virtually all of the interesting activity still centers around the > same three locks that were problematic back then, which means that - > although overall performance has improved quite a bit - we've not > really delivered any knockout punches. Here are the perpetrators: I don't think that is depressing at all. Certain locks needs to exist to protect certain things, and a benchmark which tests those things is going to take those locks rather than some other set of locks. X times faster is still X times faster, even if the bottleneck hasn't move to some other part of the code. > ....but we haven't done anything about WALInsertLock and it's > therefore grown from just over a third of the blocks to almost half. But not all blocks are for the same length of time. Do we know how much time is spent blocking? I've seen some code around that tries to instrument that, but on my machine of the time it added a lot of overhead so it couldn't be used effectively. I can try to dig it up and update it to git-head if you want to try it and aren't already aware of it. (My code was based on something I found somewhere in this list.) Also, I assume this is without the recent "Moving more work outside WALInsertLock" applied? Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers