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

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: ik(at)postgresql-consulting(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)
Date: 2014-10-02 03:25:15
Message-ID: 542CC59B.30802@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/02/2014 12:19 AM, Ilya Kosmodemiansky wrote:

> From an Oracle DBA's point of view, currently we have a lack of
> performance diagnostics tools.

Agreed. Sometimes very frustratingly so.

> Even better idea is to collect daily LWLock distribution, find most
> frequent of them etc.

While we could add this within PostgreSQL, I wonder if it's worth
looking at whether it can be done non-intrusively with operating system
facilities like perf.

I've had really good results using perf to trace and graph xlog
generation and other metrics in the past.

> The patch https://commitfest.postgresql.org/action/patch_view?id=885
> (discussion starts here I hope -
> http://www.postgresql.org/message-id/4FE8CA2C.3030809@uptime.jp)
> demonstrates performance problems; LWLOCK_STAT, LOCK_DEBUG and
> DTrace-like approach are slow, unsafe for production use and a bit
> clumsy for using by DBA.

It's not at all clear to me that a DTrace-like (or perf-based, rather)
approach is unsafe, slow, or unsuitable for production use.

Resolving lock IDs to names might be an issue, though.

With appropriate wrapper tools I think we could have quite a useful
library of perf-based diagnostics and tracing tools for PostgreSQL.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2014-10-02 03:53:17 Re: "Value locking" Wiki page
Previous Message Stephen Frost 2014-10-02 00:42:46 Re: superuser() shortcuts