Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)

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

In response to

Responses

Browse pgsql-hackers by date

  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)