Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)
От | Ilya Kosmodemiansky |
---|---|
Тема | Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept) |
Дата | |
Msg-id | CAG95seVst4EWhXmiNcJ+1b4Fvub4ZyNnwj-TixwBC4k6YaCvmQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Dynamic LWLock tracing via pg_stat_lwlock (proof of concept) (Ilya Kosmodemiansky <ilya.kosmodemiansky@postgresql-consulting.com>) |
Список | 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 по дате отправления: