Re: shared-memory based stats collector

At Mon, 15 Mar 2021 19:04:29 -0700, Andres Freund <andres(at)anarazel(dot)de> wrote in
> I have a few questions about the patch:
>
> - Why was collect_oids() changed to a different hashtable as part of
> this change? Seems fairly independent?

Right. It is changed at the time I used simplehash for some other
stuff.

> - What's the point of all those cached_* stuff? There's not a single
> comment explaining it as far as I can tell...
>
> Several of them are never used as a cache! E.g. cached_archiverstats,
> cached_bgwriterstats, ...

They're just local copies of them on shared memory. That works to
allow early release of locks on shared objects. And they're to avoid
repeated copying of the same stats entry and to offer a consistent
values. For example, pgstat_fetch_stat_tabentry() is called repeatedly
in a single view.

About cached_archiverstats... cached_archvierstats_is_valid is utterly
useless. Since we don't offer in-transaction consistency for the
values, I think *_is_valid are useless.

> - What is the idea behind pgstat_reset_shared_counters() using
> pgstat_copy_global_stats() to reset, using StatsShmem->*_reset_offset?
> But then still taking a lock in pgstat_fetch_stat_*? Again, no
> comments explaining what the goal is.
>
> It kinda looks like you tried to make both read and write paths not
> use the lock, but then ended up using a lock?

Mmm. That is a kind of inconsistent between the view from upper side
and from lower side. As you say, I tried to get rid of *the*
StatsLock in pgstat_reset_shared_counters and eventually I forgot to
remove the locking. I think the lock is no longer necessary.

> Do you have some benchmarks that you used to verify performance?

https://www.postgresql.org/message-id/20201008.160326.2246946707652981235.horikyota.ntt%40gmail.com

It is using pgbench, with 800 clients with 20 threads.

Graphs of performance gain/loss from the master for the following
benchmarks are attached.

> - Fetching 1 tuple from 1 of 100 tables from 100 to 800 clients.
> - Fetching 1 tuple from 1 of 10 tables from 100 to 800 clients.

v36 showed about 60% of degradation (TPS redued to 1/3 of master) at
600 clients, but it has been dissapeared as of v39. The graphs are of
v39. I'm asking for the script that was used for the benchark and will
send them later.

> I think I'm going to try to split the storage of fixed-size stats in
> StatsShmemStruct into a separate patch. That's already a pretty large
> change, and it's pretty much unrelated to the rest.

I'm not sure the ratio between the "Global stats structs" (aka
fixed-size stats?) and other stuff but agreed that they are almost
unrelated to each other.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center