On Tue, Sep 15, 2015 at 3:30 PM, Jesper Pedersen
<jesper.pedersen@redhat.com> wrote:
> X-axis is sort of "up in the air" with flame graphs -- similar call stacks
> are grouped together, and here it is the queue size.
>
> Y-axis is the lock queue size -- e.g. CLogControlLock is "max'ed" out, since
> there is a queue size of 80 with the -c/-j 80 run.
Oh, OK, I think I sorta get it now. I've seen flamegraphs before, but of CPU.
> Thanks for looking at the patch.
I haven't really, just the email. But it seems like a neat concept.
So if I understand this correctly:
74.05% of spin delays are attributable to CLogControLock, 20.01% to
ProcArrayLock, and 3.39% to XidGenLock. Incredibly, the queue length
reaches the number of backends (80) for both CLogControlLock and
XidGenLock, but for ProcArrayLock it "only" reaches a length of 75.
44.46% of blocking is attributable to CLogControlLock and 1.34% to
XidGenLock. 32.62% is due to ProcArrayLock. The WALInsertLocks
account for 2.34% each, so 2.34% * 8 = 18.72%. The WALInsertLock have
a maximum queue depths between 28 and 42.
This seems to suggest that relieving pressure on CLogControlLock would
be very beneficial, but I'm not sure what else to make of it. It
would be nice to get a better sense of how *long* we block on various
locks. It's hard to tell whether some other lock might be have fewer
blocking events but for a much longer average duration.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
