Re: pg_stat_io not tracking smgrwriteback() is confusing
Melanie Plageman <melanieplageman@gmail.com>
From: Melanie Plageman <melanieplageman@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Amit Kapila <amit.kapila16@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, "Jonathan S. Katz" <jkatz@postgresql.org>
Date: 2023-04-24T20:39:36Z
Lists: pgsql-hackers
On Wed, Apr 19, 2023 at 10:23:26AM -0700, Andres Freund wrote: > Hi, > > I noticed that the numbers in pg_stat_io dont't quite add up to what I > expected in write heavy workloads. Particularly for checkpointer, the numbers > for "write" in log_checkpoints output are larger than what is visible in > pg_stat_io. > > That partially is because log_checkpoints' "write" covers way too many things, > but there's an issue with pg_stat_io as well: > > Checkpoints, and some other sources of writes, will often end up doing a lot > of smgrwriteback() calls - which pg_stat_io doesn't track. Nor do any > pre-existing forms of IO statistics. > > It seems pretty clear that we should track writeback as well. I wonder if it's > worth doing so for 16? It'd give a more complete picture that way. The > counter-argument I see is that we didn't track the time for it in existing > stats either, and that nobody complained - but I suspect that's mostly because > nobody knew to look. Not complaining about making pg_stat_io more accurate, but what exactly would we be tracking for smgrwriteback()? I assume you are talking about IO timing. AFAICT, on Linux, it does sync_file_range() with SYNC_FILE_RANGE_WRITE, which is asynchronous. Wouldn't we just be tracking the system call overhead time? - Melanie
Commits
-
Add writeback to pg_stat_io
- 093e5c57d506 16.0 landed
-
Update parameter name context to wb_context
- 52676dc2e016 16.0 landed
-
Use BUFFER_USAGE_LIMIT to reduce needed test table size
- 322875597c0c 16.0 landed