Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
Melanie Plageman <melanieplageman@gmail.com>
On Wed, Jul 20, 2022 at 12:50 PM Andres Freund <andres@anarazel.de> wrote:
>
> On 2022-07-14 18:44:48 -0400, Melanie Plageman wrote:
>
> > @@ -1427,8 +1445,10 @@ pgstat_read_statsfile(void)
> > FILE *fpin;
> > int32 format_id;
> > bool found;
> > + PgStat_BackendIOPathOps io_stats;
> > const char *statfile = PGSTAT_STAT_PERMANENT_FILENAME;
> > PgStat_ShmemControl *shmem = pgStatLocal.shmem;
> > + PgStatShared_BackendIOPathOps *io_stats_shmem = &shmem->io_ops;
> >
> > /* shouldn't be called from postmaster */
> > Assert(IsUnderPostmaster || !IsPostmasterEnvironment);
> > @@ -1486,6 +1506,22 @@ pgstat_read_statsfile(void)
> > if (!read_chunk_s(fpin, &shmem->checkpointer.stats))
> > goto error;
> >
> > + /*
> > + * Read IO Operations stats struct
> > + */
> > + if (!read_chunk_s(fpin, &io_stats))
> > + goto error;
> > +
> > + io_stats_shmem->stat_reset_timestamp =
> io_stats.stat_reset_timestamp;
> > +
> > + for (int i = 0; i < BACKEND_NUM_TYPES; i++)
> > + {
> > + PgStat_IOPathOps *stats = &io_stats.stats[i];
> > + PgStatShared_IOPathOps *stats_shmem =
> &io_stats_shmem->stats[i];
> > +
> > + memcpy(stats_shmem->data, stats->data,
> sizeof(stats->data));
> > + }
>
> Why can't the data be read directly into shared memory?
>
>
It is not the same lock. Each PgStatShared_IOPathOps has a lock so that
they can be accessed individually (per BackendType in
PgStatShared_BackendIOPathOps). It is optimized for the more common
operation of flushing at the expense of the snapshot operation (which
should be less common) and reset operation.
> > +void
> > +pgstat_io_ops_snapshot_cb(void)
> > +{
> > + PgStatShared_BackendIOPathOps *all_backend_stats_shmem =
> &pgStatLocal.shmem->io_ops;
> > + PgStat_BackendIOPathOps *all_backend_stats_snap =
> &pgStatLocal.snapshot.io_ops;
> > +
> > + for (int i = 0; i < BACKEND_NUM_TYPES; i++)
> > + {
> > + PgStatShared_IOPathOps *stats_shmem =
> &all_backend_stats_shmem->stats[i];
> > + PgStat_IOPathOps *stats_snap =
> &all_backend_stats_snap->stats[i];
> > +
> > + LWLockAcquire(&stats_shmem->lock, LW_EXCLUSIVE);
>
> Why acquire the same lock repeatedly for each type, rather than once for
> the whole?
>
>
This is also because of having a LWLock in each PgStatShared_IOPathOps.
Because I don't want a lock in the backend local stats, I have two data
structures PgStatShared_IOPathOps and PgStat_IOPathOps. I thought it was
odd to write out the lock to the file, so when persisting the stats, I
write out the relevant data only and when reading it back in to shared
memory, I read in the data member of PgStatShared_IOPathOps.
Commits
-
Stabilize pg_stat_io writes test
- ef719e7b32fc 16.0 landed
-
Fix flakey pg_stat_io test
- 1be0fdb9de55 16.0 landed
-
Suppress more compiler warnings in new pgstats code.
- b1b86820d84e 16.0 landed
-
Suppress compiler warnings in new pgstats code.
- 728560db7d86 16.0 landed
-
Add tests for pg_stat_io
- 10a082bf7215 16.0 landed
-
Create regress_tblspc in test_setup
- 9c83bbcf7ef6 16.0 landed
-
Add pg_stat_io view, providing more detailed IO statistics
- a9c70b46dbe1 16.0 landed
-
pgstat: Track more detailed relation IO statistics
- f30d62c2fc60 16.0 landed
-
pgstat: Infrastructure for more detailed IO statistics
- 28e626bde00e 16.0 landed
-
doc: Fix some issues in logical replication section
- 4f74f5641d53 16.0 cited
-
Manual cleanup and pgindent of pgstat and bufmgr related code
- 250c8ee07ede 16.0 landed
-
Have the planner consider Incremental Sort for DISTINCT
- 3c6fc58209f2 16.0 cited
-
Use actual backend IDs in pg_stat_get_backend_idset() and friends.
- d7e39d72ca1c 16.0 cited
-
Remove redundant call to pgstat_report_wal()
- 1bdd54e662d5 16.0 landed
-
Add BackendType for standalone backends
- 0c679464a837 16.0 landed
-
Initialize backend status reporting during bootstrap.
- 3b34645678d1 15.0 landed