Re: Monitoring time of fsyncing WALs
Craig Ringer <craig@2ndquadrant.com>
From: Craig Ringer <craig@2ndquadrant.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Robert Haas <robertmhaas@gmail.com>,
Konstantin Knizhnik <k.knizhnik@postgrespro.ru>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-07-02T03:36:06Z
Lists: pgsql-hackers
Attachments
- v1-0001-Add-more-statically-defined-tracepoints-around-xl.patch (text/x-patch) patch v1-0001
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. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
-
Add wait event for fsync of WAL segments
- c55de5e5123c 12.0 landed