Re: Monitoring time of fsyncing WALs
От | Craig Ringer |
---|---|
Тема | Re: Monitoring time of fsyncing WALs |
Дата | |
Msg-id | CAMsr+YGK-tSXNLpU6GhGzRWKEgjvU-xRQ7C4OT+ZbJ7xb+g5nw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Monitoring time of fsyncing WALs (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Monitoring time of fsyncing WALs
|
Список | pgsql-hackers |
On 1 July 2018 at 11:29, Michael Paquier <michael@paquier.xyz> wrote:
--
So at the end, I would like to use the proposed patch and call it a
day. Thoughts?
Patch looks good.
I'll hijack the thread to add a few more perf/dtrace tracepoints in the WAL code, as they were also missing. Proposed rider patch attached.
I've updated https://wiki.postgresql.org/wiki/Profiling_with_perf#PostgreSQL_pre-defined_tracepoint_events to document how to add tracepoints.
It's not that hard to trace duration of a given function call with dtrace without such annotations, but they make it much easier to discover where in a large codebase to look, providing a form of documentation. With perf they make life much easier. I should add some more to make it easier to analyse relation extension contention on indexes and the heap, instrument btree index ops like page splits, instrument heavyweight locking (beyond LOCK_WAIT_START), etc. They're also handy for gdb - https://sourceware.org/gdb/onlinedocs/gdb/Static-Probe-Points.html - also handy for gdb's "info probes".
BTW, we might want to instrument the pgstat_ counter calls and pgstat_report_wait_start / pgstat_report_wait_end, but it's easy enough to use dynamic tracepoints for those so I haven't yet. Maybe even just document them as points of interest.
Вложения
В списке pgsql-hackers по дате отправления: