From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, ik(at)postgresql-consulting(dot)com, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept) |
Date: | 2014-10-07 14:30:24 |
Message-ID: | 20141007143024.GG22022@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-10-07 17:22:18 +0300, Heikki Linnakangas wrote:
> FWIW, I liked Ilya's design. Before going to sleep, store the lock ID in
> shared memory. When you wake up, clear it. That should be cheap enough to
> have it always enabled. And it can easily be extended to other "waits", e.g.
> when you're waiting for input from client.
I think there's a few locks where that's interesting. But in my
experience many slowdowns aren't caused by actual waits, but because of
cacheline contention. And for that the number of acquisitions is much
more relevant than the waiting. The primary example for this is probably
the procarray lock.
> I don't think counting the number of lock acquisition is that interesting.
> It doesn't give you any information on how long the waits were, for
> example.
Sure, that's a separate thing that we should be able to answer.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-10-07 14:30:54 | Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept) |
Previous Message | Heikki Linnakangas | 2014-10-07 14:22:18 | Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept) |