From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: LWLOCK_STATS |
Date: | 2012-01-07 02:29:19 |
Message-ID: | CAMkU=1whpsuZWvyoQz7s-U-BgjjAWA1OV9uXZNzvqCEg0AnhQQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 6, 2012 at 2:24 PM, Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-01-07 02:40:06 | Re: LWLOCK_STATS |
Previous Message | Noah Misch | 2012-01-07 02:13:59 | Second thoughts on CheckIndexCompatible() vs. operator families |