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 1jUvTt-0002NL-HG for pgsql-hackers@arkaria.postgresql.org; Sat, 02 May 2020 16:59:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jUvTs-0001aZ-CZ for pgsql-hackers@arkaria.postgresql.org; Sat, 02 May 2020 16:59:12 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jUvTs-0001aS-1F for pgsql-hackers@lists.postgresql.org; Sat, 02 May 2020 16:59:12 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jUvTp-0005QW-FU for pgsql-hackers@postgresql.org; Sat, 02 May 2020 16:59:11 +0000 Received: by mail-wr1-x443.google.com with SMTP id j1so15675987wrt.1 for ; Sat, 02 May 2020 09:59:09 -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=czQnxntNxu7C0Xvc2ChVwI604b0YbCS7KmG4b4EKK+U=; b=bPyCBoD3gJQuX56a9chUBJX0kFM2RXADGhAD9QTMbD19idiZ7fcepJE3auSSMn5cAM aLYmDzdF8jXb02FT3UEN23xb3pMu84FmaDcFJXLbcRxl+y4hlLIaxlqnIorQRPsaFL8d ixuMU0GJlWbROTiQCR694pVaSjQIjGwt3nV8SsnTRW87FmjiVzXLMaAwGFt+XifvDz5j 2IQeK0Q5CvKyZjTDe3posxKXhBbCtPT5F7WKxm1gIdg+t68r0SjiipvdJIBmWtzzQu+S qDIFch8DihQqD7XyOKNIEgptybCHp93HqKZipcLwI3AzqWutEGgcgvWG+cUUjOWa6VFh qMeg== 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=czQnxntNxu7C0Xvc2ChVwI604b0YbCS7KmG4b4EKK+U=; b=S4JH6fcAGcugDy3EndzgkOHbyfmS6yCFgdUWhk62EjT6e/+/TjLn2y2EETEpMN8kSS y7JZYFnS1WS3g0V46V6Ly8WecT2/Oo2+hQts/Ax509kvGdg5lp1gza+L/e9DuZIxFMYq jrLXBlc5kdY5sAWRXpwAbQPoVbkSSk2sqrz7B4o9S4B55IiNwvT/vtwBXrvB/XH9NJuZ gzGJbrDJbQabR/sDjtnjo/jXaI4e8AhCHfXEi8VY9M1CAZR9Wl6gEdMqKCQOqw/0YNWV JyMp11GFcF7E/BFWQJK/FsShW94VqbCs/Z3R08mv//rWJiIScs/t/TXNAd5gFBllSQLT fyJg== X-Gm-Message-State: AGi0PuaDKyyCvm3bP3kaNlCUhYrtVcJptw5FPC8T7GKIqV5PS4Y0vaWJ RjSaG2P2BAR2qBO0PxJpWF/4/A== X-Google-Smtp-Source: APiQypKUTzsUcGaD2JDY6/AKCwQu4kWmdmfI+l58rf4hq0IhNjg1xlBdrNsPAcBVPxOGFrGAfhDhYQ== X-Received: by 2002:a5d:4211:: with SMTP id n17mr9497290wrq.286.1588438747983; Sat, 02 May 2020 09:59:07 -0700 (PDT) Received: from localhost (ip-86-49-253-141.net.upcbroadband.cz. [86.49.253.141]) by smtp.gmail.com with ESMTPSA id o6sm10702141wrw.63.2020.05.02.09.59.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 May 2020 09:59:07 -0700 (PDT) Date: Sat, 2 May 2020 18:59:05 +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: <20200502165905.brfxv6dk5vjdbgti@development> References: <20200229205518.xrxo535zgd7cl6no@development> <20200327004111.md4suoi6u5suv2qe@development> <20200328002630.2nz5y3dvymqnvxtv@development> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200502105500.hwhba3d6s3hlrqf6@development> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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? > 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. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services