Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jYmeV-0003CH-Rq for pgsql-hackers@arkaria.postgresql.org; Wed, 13 May 2020 08:22:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jYmeU-0007dD-QS for pgsql-hackers@arkaria.postgresql.org; Wed, 13 May 2020 08:22:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jYmeU-0007d6-EO for pgsql-hackers@lists.postgresql.org; Wed, 13 May 2020 08:22:06 +0000 Received: from mail-wr1-x442.google.com ([2a00:1450:4864:20::442]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jYmeR-00023J-HS for pgsql-hackers@postgresql.org; Wed, 13 May 2020 08:22:06 +0000 Received: by mail-wr1-x442.google.com with SMTP id l17so6150070wrr.4 for ; Wed, 13 May 2020 01:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=uMhLTqLFXJRLEJcRlvT55SJ/Qoc8AcVwoQrBWTdNqls=; b=NSScyVHeo3kUv9bA6FaBLn+lBfiYjwsjLJk3c++gO+VShMsSiYpSHPxgiNNglKUHFk K2DteXFqcp3F/FIX2766xCbj3yJ+KyaR+ok9pMU5XhftvnrGN0rogNUmxhdA+tKykKvj gN8CTa9cMttzGI0wxXZyAERPeN3uo9kydkYke5JeJxUfFyXgrYZCw1sCCZFBsomKKWnv A6wo0pw1PuImgZow3xNdSKutgP3kj4WPLQOpu8TesSi0+2IztC0Ai7cd/WWGKhP0XuU+ lsWm+g4fgLUhWhi/H/Kxu8ragW0tBL5mOyzOETCdDRGKc4uaRF5m3oNPIbq91gm+cqhn Q9oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=uMhLTqLFXJRLEJcRlvT55SJ/Qoc8AcVwoQrBWTdNqls=; b=XsISPwgjshFgnZc2A6nnbVlvl9nf1G91rLVoK+Ett7imq1y4Y8xtdKnefK0nJv9ER9 wg4Fgb1xw7txPeQR02fViMcQvizFqS26hoFD0/4mZWd1U7vXXCP1/fjWN/ANV3IiRUso Z1X/ggxNGiXu2xhI8j/3WH3Y+2zExXKrMtdG3wk/AW+AVTkYEufpbsXkVXpCtG/U/9JJ L73BQWdy0omfZuHtzw+t2+ZDAYkPWzDlLqkBzB8r07y30tsPnLkwgtIFdxftwfinFyya jDKEDbso9gL1h/Zz6HruPeJ0CQmaesgIDoTd/trBNoLAZclkRkGd4FUI4MlZNwDMJlWy cw8A== X-Gm-Message-State: AGi0PuYgIX1J801TfAbWVYAhpsVPCmNzd4EqJlyQQTu9lUx3ottXPwx1 Nqf2PpzaI9KKO+RY6KeBor4szJpD9sU= X-Google-Smtp-Source: APiQypJgUJT/GAMJrf/h09TckQRK0hR9AZdZ3JkH4hAE/v66LBbO14olCTLmnMBmgKzHOCYAlm7/Ng== X-Received: by 2002:adf:810a:: with SMTP id 10mr30681791wrm.101.1589358122698; Wed, 13 May 2020 01:22:02 -0700 (PDT) Received: from localhost (ip-86-49-253-141.net.upcbroadband.cz. [86.49.253.141]) by smtp.gmail.com with ESMTPSA id m82sm24035312wmf.3.2020.05.13.01.22.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2020 01:22:01 -0700 (PDT) Date: Wed, 13 May 2020 10:21:59 +0200 From: Tomas Vondra To: Fujii Masao Cc: Alvaro Herrera , Masahiko Sawada , "tsunakawa.takay@fujitsu.com" , "pgsql-hackers@postgresql.org" Subject: Re: SLRU statistics Message-ID: <20200513082159.myflgcs5fnhnujbk@development> References: <20200402004136.wodwftan45mcwggm@development> <20200430181901.24tlriahmafi4sfn@development> <0e1c8904-13be-ab70-0096-54f0b30e43ba@oss.nttdata.com> <20200502000818.nn4kpewiput42bnb@development> <49b8ad17-f6d9-a086-a952-ff1fec3ac1b3@oss.nttdata.com> <20200502105500.hwhba3d6s3hlrqf6@development> <20200502165905.brfxv6dk5vjdbgti@development> <976bbb73-a112-de3c-c488-b34b64609793@oss.nttdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, May 13, 2020 at 04:10:30PM +0900, Fujii Masao wrote: > > >On 2020/05/07 13:47, Fujii Masao wrote: >> >> >>On 2020/05/03 1:59, Tomas Vondra wrote: >>>On Sat, May 02, 2020 at 12:55:00PM +0200, Tomas Vondra wrote: >>>>On Sat, May 02, 2020 at 03:56:07PM +0900, Fujii Masao wrote: >>>>> >>>>>... >>>> >>>>>>>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? >> >>No. For now what I'm in mind are just checkpointer, autovacuum worker, >>logical replication walsender and parallel query worker. Seems logical >>replication worker and syncer have sent slru stats via pgstat_report_stat(). >> >>>I've looked at places calling pgstat_send_* functions, and I found >>>thsese places: >>> >>>src/backend/postmaster/bgwriter.c >>> >>>- AFAIK it merely writes out dirty shared buffers, so likely irrelevant. >>> >>>src/backend/postmaster/checkpointer.c >>> >>>- This is what we're already discussing here. >>> >>>src/backend/postmaster/pgarch.c >>> >>>- Seems irrelevant. >>> >>> >>>I'm a bit puzzled why we're not sending any stats from walsender, which >>>I suppose could do various stuff during logical decoding. >> >>Not sure why, but that seems an oversight... >> >> >>Also I found another minor issue; SLRUStats has not been initialized to 0 >>and which could update the counters unexpectedly. Attached patch fixes >>this issue. > >This is minor issue, but basically it's better to fix that before >v13 beta1 release. So barring any objection, I will commit the patch. > >+ values[8] = Int64GetDatum(stat.stat_reset_timestamp); > >Also I found another small issue: pg_stat_get_slru() returns the timestamp >when pg_stat_slru was reset by using Int64GetDatum(). This works maybe >because the timestamp is also int64. But TimestampTzGetDatum() should >be used here, instead. Patch attached. Thought? > I agree with both fixes. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services