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

From Ilya Kosmodemiansky
Subject Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)
Date
Msg-id CAG95seVst4EWhXmiNcJ+1b4Fvub4ZyNnwj-TixwBC4k6YaCvmQ@mail.gmail.com
Whole thread Raw
In response to Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)  (Ilya Kosmodemiansky <ilya.kosmodemiansky@postgresql-consulting.com>)
List pgsql-hackers
On Thu, Oct 2, 2014 at 5:25 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> 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.

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

It is not actually very slow, overhead is quite reasonable since we
want such comprehensive performance diagnostics. About stability, I
have had a couple of issues with postgres crushes with dtrace and dos
not without. Most of them was on FreeBSD, which is still in use by
many people and were caused actually by freebsd dtrace, but for me it
is quite enough to have doubts about keeping dtrace aware build in
production.


OK, OK -  maybe things were changed last couple of years or will
change soon - still dtrace/perf is well enough for those who is
familiar with it, but you need a really convenient wrapper to make
oracle/db2 DBA happy with using such approach.


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

I am afraid it is

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



-- 
Ilya Kosmodemiansky,

PostgreSQL-Consulting.com
tel. +14084142500
cell. +4915144336040
ik@postgresql-consulting.com



pgsql-hackers by date:

Previous
From: Ilya Kosmodemiansky
Date:
Subject: Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)
Next
From: Heikki Linnakangas
Date:
Subject: Re: NEXT VALUE FOR