database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-24 14:22:24 +03:00
Code Activity

Re-add GUC track_wal_io_timing

Browse Source 
This commit is a rework of 2421e9a51d, about which Andres Freund has
raised some concerns as it is valuable to have both track_io_timing and
track_wal_io_timing in some cases, as the WAL write and fsync paths can
be a major bottleneck for some workloads.  Hence, it can be relevant to
not calculate the WAL timings in environments where pg_test_timing
performs poorly while capturing some IO data under track_io_timing for
the non-WAL IO paths.  The opposite can be also true: it should be
possible to disable the non-WAL timings and enable the WAL timings (the
previous GUC setups allowed this possibility).

track_wal_io_timing is added back in this commit, controlling if WAL
timings should be calculated in pg_stat_io for the read, fsync and write
paths, as done previously with pg_stat_wal.  pg_stat_wal previously
tracked only the sync and write parts (now removed), read stats is new
data tracked in pg_stat_io, all three are aggregated if
track_wal_io_timing is enabled.  The read part matters during recovery
or if a XLogReader is used.

Extra note: more control over if the types of timings calculated in
pg_stat_io could be done with a GUC that lists pairs of (IOObject,IOOp).

Reported-by: Andres Freund <andres@anarazel.de>
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Co-authored-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/3opf2wh2oljco6ldyqf7ukabw3jijnnhno6fjb4mlu6civ5h24@fcwmhsgmlmzu
This commit is contained in:
Michael Paquier
2025-02-26 09:49:59 +09:00
parent a5cbdeb98a
commit 6c349d83b6
15 changed files with 96 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
doc/src/sgml/config.sgml
View File

@ -8378,9 +8378,11 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
displayed in <link linkend="monitoring-pg-stat-database-view">
<structname>pg_stat_database</structname></link>,
<link linkend="monitoring-pg-stat-io-view">
<structname>pg_stat_io</structname></link>, in the output of the
<structname>pg_stat_io</structname></link> (if <varname>object</varname>
is not <literal>wal</literal>), in the output of the
<link linkend="pg-stat-get-backend-io">
<function>pg_stat_get_backend_io()</function></link> function, in the
<function>pg_stat_get_backend_io()</function></link> function (if
<varname>object</varname> is not <literal>wal</literal>), in the
output of <xref linkend="sql-explain"/> when the <literal>BUFFERS</literal>
option is used, in the output of <xref linkend="sql-vacuum"/> when
the <literal>VERBOSE</literal> option is used, by autovacuum
@ -8393,6 +8395,32 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
</listitem>
</varlistentry>
<varlistentry id="guc-track-wal-io-timing" xreflabel="track_wal_io_timing">
<term><varname>track_wal_io_timing</varname> (<type>boolean</type>)
<indexterm>
<primary><varname>track_wal_io_timing</varname> configuration parameter</primary>
</indexterm>
</term>
<listitem>
<para>
Enables timing of WAL I/O calls. This parameter is off by default,
as it will repeatedly query the operating system for the current time,
which may cause significant overhead on some platforms.
You can use the <application>pg_test_timing</application> tool to
measure the overhead of timing on your system.
I/O timing information is displayed in
<link linkend="monitoring-pg-stat-io-view">
<structname>pg_stat_io</structname></link> for the
<varname>object</varname> <literal>wal</literal> and in the output of
the <link linkend="pg-stat-get-backend-io">
<function>pg_stat_get_backend_io()</function></link> function for the
<varname>object</varname> <literal>wal</literal>.
Only superusers and users with the appropriate <literal>SET</literal>
privilege can change this setting.
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-track-functions" xreflabel="track_functions">
<term><varname>track_functions</varname> (<type>enum</type>)
<indexterm>

31
doc/src/sgml/monitoring.sgml
View File

@ -183,6 +183,11 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
of block read, write, extend, and fsync times.
</para>
<para>
The parameter <xref linkend="guc-track-wal-io-timing"/> enables monitoring
of WAL read, write and fsync times.
</para>
<para>
Normally these parameters are set in <filename>postgresql.conf</filename> so
that they apply to all server processes, but it is possible to turn
@ -2723,7 +2728,11 @@ description | Waiting for a newly initialized WAL file to reach durable storage
</para>
<para>
Time spent in read operations in milliseconds (if
<xref linkend="guc-track-io-timing"/> is enabled, otherwise zero)
<xref linkend="guc-track-io-timing"/> is enabled and
<varname>object</varname> is not <literal>wal</literal>,
or if <xref linkend="guc-track-wal-io-timing"/> is enabled
and <varname>object</varname> is <literal>wal</literal>,
otherwise zero)
</para>
</entry>
</row>
@ -2757,7 +2766,11 @@ description | Waiting for a newly initialized WAL file to reach durable storage
</para>
<para>
Time spent in write operations in milliseconds (if
<xref linkend="guc-track-io-timing"/> is enabled, otherwise zero)
<xref linkend="guc-track-io-timing"/> is enabled and
<varname>object</varname> is not <literal>wal</literal>,
or if <xref linkend="guc-track-wal-io-timing"/> is enabled
and <varname>object</varname> is <literal>wal</literal>,
otherwise zero)
</para>
</entry>
</row>
@ -2816,8 +2829,12 @@ description | Waiting for a newly initialized WAL file to reach durable storage
<structfield>extend_time</structfield> <type>double precision</type>
</para>
<para>
Time spent in extend operations in milliseconds (if
<xref linkend="guc-track-io-timing"/> is enabled, otherwise zero)
Time spent in extend operations in milliseconds. (if
<xref linkend="guc-track-io-timing"/> is enabled and
<varname>object</varname> is not <literal>wal</literal>,
or if <xref linkend="guc-track-wal-io-timing"/> is enabled
and <varname>object</varname> is <literal>wal</literal>,
otherwise zero)
</para>
</entry>
</row>
@ -2887,7 +2904,11 @@ description | Waiting for a newly initialized WAL file to reach durable storage
</para>
<para>
Time spent in fsync operations in milliseconds (if
<xref linkend="guc-track-io-timing"/> is enabled, otherwise zero)
<xref linkend="guc-track-io-timing"/> is enabled and
<varname>object</varname> is not <literal>wal</literal>,
or if <xref linkend="guc-track-wal-io-timing"/> is enabled
and <varname>object</varname> is <literal>wal</literal>,
otherwise zero)
</para>
</entry>
</row>

4
doc/src/sgml/wal.sgml
View File

@ -808,7 +808,7 @@
<para>
There are two internal functions to write WAL data to disk:
<function>XLogWrite</function> and <function>issue_xlog_fsync</function>.
When <xref linkend="guc-track-io-timing"/> is enabled, the total
When <xref linkend="guc-track-wal-io-timing"/> is enabled, the total
amounts of time <function>XLogWrite</function> writes and
<function>issue_xlog_fsync</function> syncs WAL data to disk are counted as
<varname>write_time</varname> and <varname>fsync_time</varname> in
@ -828,7 +828,7 @@
<literal>fsync</literal>, or <literal>fsync_writethrough</literal>,
the write operation moves WAL buffers to kernel cache and
<function>issue_xlog_fsync</function> syncs them to disk. Regardless
of the setting of <varname>track_io_timing</varname>, the number
of the setting of <varname>track_wal_io_timing</varname>, the number
of times <function>XLogWrite</function> writes and
<function>issue_xlog_fsync</function> syncs WAL data to disk are also
counted as <varname>writes</varname> and <varname>fsyncs</varname>