Date: Sat, 2 May 2020 12:55:00 +0200
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
	Masahiko Sawada <masahiko.sawada@2ndquadrant.com>,
	"tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: SLRU statistics
Message-ID: <20200502105500.hwhba3d6s3hlrqf6@development>
References: <20200229144426.GA32500@alvherre.pgsql>
 <20200229205518.xrxo535zgd7cl6no@development>
 <20200327004111.md4suoi6u5suv2qe@development>
 <20200328002630.2nz5y3dvymqnvxtv@development>
 <20200402004136.wodwftan45mcwggm@development>
 <f02fd0ec-a240-b5bf-9992-5faf582738f1@oss.nttdata.com>
 <20200430181901.24tlriahmafi4sfn@development>
 <0e1c8904-13be-ab70-0096-54f0b30e43ba@oss.nttdata.com>
 <20200502000818.nn4kpewiput42bnb@development>
 <49b8ad17-f6d9-a086-a952-ff1fec3ac1b3@oss.nttdata.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <49b8ad17-f6d9-a086-a952-ff1fec3ac1b3@oss.nttdata.com>
Precedence: bulk

On Sat, May 02, 2020 at 03:56:07PM +0900, Fujii Masao wrote:
>
>
>On 2020/05/02 9:08, Tomas Vondra wrote:
>>On Fri, May 01, 2020 at 11:49:51AM +0900, Fujii Masao wrote:
>>>
>>>
>>>On 2020/05/01 3:19, Tomas Vondra wrote:
>>>>On Fri, May 01, 2020 at 03:02:59AM +0900, Fujii Masao wrote:
>>>>>
>>>>>
>>>>>On 2020/04/02 9:41, Tomas Vondra wrote:
>>>>>>Hi,
>>>>>>
>>>>>>I've pushed this after some minor cleanup and improvements.
>>>>>
>>>>>+static char *slru_names[] = {"async", "clog", "commit_timestamp",
>>>>>+                              "multixact_offset", "multixact_member",
>>>>>+                              "oldserxid", "pg_xact", "subtrans",
>>>>>+                              "other" /* has to be last */};
>>>>>
>>>>>When I tried pg_stat_slru, I found that it returns a row for "pg_xact".
>>>>>But since there is no "pg_xact" slru ("clog" slru exists instead),
>>>>>"pg_xact" should be removed? Patch attached.
>>>>>
>>>>
>>>>Yeah, I think I got confused and accidentally added both "clog" and
>>>>"pg_xact". I'll get "pg_xact" removed.
>>>
>>>Thanks!
>>>
>>
>>OK, pushed. Thanks!
>
>Thanks a lot!
>
>But, like the patch that I attached in the previous email does,
>"pg_xact" should be removed from the description of pg_stat_reset_slru()
>in monitoring.sgml.
>

Whooops. My bad, will fix.

>>>Another thing I found is; pgstat_send_slru() should be called also by
>>>other processes than backend? For example, since clog data is flushed
>>>basically by checkpointer, checkpointer seems to need to send slru stats.
>>>Otherwise, pg_stat_slru.flushes would not be updated.
>>>
>>
>>Hmmm, that's a good point. If I understand the issue correctly, the
>>checkpointer accumulates the stats but never really sends them because
>>it never calls pgstat_report_stat/pgstat_send_slru. That's only called
>>from PostgresMain, but not from CheckpointerMain.
>
>Yes.
>
>>I think we could simply add pgstat_send_slru() right after the existing
>>call in CheckpointerMain, right?
>
>Checkpointer sends off activity statistics to the stats collector in
>two places, by calling pgstat_send_bgwriter(). What about calling
>pgstat_send_slru() just after pgstat_send_bgwriter()?
>

Yep, that's what I proposed.

>In previous email, I mentioned checkpointer just as an example.
>So probably we need to investigate what process should send slru stats,
>other than checkpointer. I guess that at least autovacuum worker,
>logical replication walsender and parallel query worker (maybe this has
>been already covered by parallel query some mechanisms. Sorry I've
>not checked that) would need to send its slru stats.
>

Probably. Do you have any other process type in mind?

>Atsushi-san reported another issue in pg_stat_slru.
>You're planning to work on that?
>https://postgr.es/m/CACZ0uYFe16pjZxQYaTn53mspyM7dgMPYL3DJLjjPw69GMCC2Ow@mail.gmail.com
>

Yes, I'll investigate.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services