Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)
Date
Msg-id 22838.1412690986@sss.pgh.pa.us
Whole thread Raw
In response to Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> I think the easiest way to measure lwlock contention would be to put
> some counters in the lwlock itself.  My guess, based on a lot of
> fiddling with LWLOCK_STATS over the years, is that there's no way to
> count lock acquisitions and releases without harming performance
> significantly - no matter where we put the counters, it's just going
> to be too expensive.  However, I believe that incrementing a counter -
> even in the lwlock itself - might not be too expensive if we only do
> it when (1) a process goes to sleep or (2) spindelays occur.  Those
> operations are expensive enough that I think the cost of an extra
> shared memory access won't be too significant.

FWIW, that approach sounds sane to me as well.  I concur with Robert's
fear that adding cycles to the no-contention case will cost so much
as to make the feature unusable in production, or even for realistic
testing; which would mean it's pretty much useless.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)
Next
From: Andres Freund
Date:
Subject: Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)