On Tue, Sep 15, 2015 at 3:30 PM, Jesper Pedersen <jesper.peder...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
