Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iK4vr-0007J0-OF for pgsql-performance@arkaria.postgresql.org; Mon, 14 Oct 2019 18:18:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iK4vq-0006lT-AD for pgsql-performance@arkaria.postgresql.org; Mon, 14 Oct 2019 18:18:58 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iK4vp-0006kh-Np for pgsql-performance@lists.postgresql.org; Mon, 14 Oct 2019 18:18:58 +0000 Received: from mail-wm1-x341.google.com ([2a00:1450:4864:20::341]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iK4vk-0007X2-8E for pgsql-performance@postgresql.org; Mon, 14 Oct 2019 18:18:56 +0000 Received: by mail-wm1-x341.google.com with SMTP id r19so18236291wmh.2 for ; Mon, 14 Oct 2019 11:18:51 -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:content-transfer-encoding:in-reply-to :user-agent; bh=0qFXJup6x4PL7DwlFFj9rwsMNcr+0ydB+VHcJ3ggLV0=; b=tT61gVlg4fvyWwieGrOkXNmavokSxKmvsnwIjyJChHGlJzNEkdYUEMgIlAtuPL3tHW R3Hn23u7XT7+ubI2yq7YFUvaVzGK1P6rVDq4J/FVy2W5C69vlDQ49TzHYj1LscLr9K4W eraTo2Syd9syUwfR29jmUiOm8y7ups/BtEjIUgAOB+9+kWqxSM4Q3Tlh3RzW1oDze0KG YpGHAKD55SpcJJPptPBOfLSPlG/8EPdX2QpeRCmtX7QhzCszlcMlExVDDu8mgFKSXZcx xLdLdtgIKh9pwV8oea5ONlC6+850RoVfbUhhYvxonU1sMNWcg7pnqvEBP46onXUzCQrB qayA== 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:content-transfer-encoding :in-reply-to:user-agent; bh=0qFXJup6x4PL7DwlFFj9rwsMNcr+0ydB+VHcJ3ggLV0=; b=uHqtDwiryQn/MC7Xj2tIzyB1xY6rldiyWq8AQFvs/onp8e4KODq46GVrsLKRFRmcLQ 8uXklzAVK631ZiMWtn1OMqNhdtzVx7UCscUS7PunIzClrAwtBSeOQoLQkJuyG3teaDLX ds9AoeCcwvrGXtwOgT37U5iYCTIXc9ue3akWrRpen7wZayUtCvS25WpiI0zCad+qHStG qgJbHfG0SdHgu8MPVCPNV4jI4+o1kO3wHvvNBylu0wS3N6+XW8XAnq2PPxR2+Db/1/Pg Aw2Yn0DpffAwUsVZC429ktuaxZh/sAJWdg0Mn2bd2e21R96zMz8q8IdeLU/OPNC1uJKj dKsg== X-Gm-Message-State: APjAAAU8KXmwant9wRNKO2lmEtH9pn581OMnWLmt/UFCZPvVEwuFrxN2 J/2xsScsCWL75P0O2eJFV+us+g== X-Google-Smtp-Source: APXvYqytApFX5HD39jf9XRbGabVHAqBECyeL7QHn4a0vSFF4Cvp5kDI6cLCNni0suqYfCrzTo/g+NA== X-Received: by 2002:a1c:b654:: with SMTP id g81mr15757724wmf.172.1571077129999; Mon, 14 Oct 2019 11:18:49 -0700 (PDT) Received: from localhost (net-188-219-235-30.cust.vodafonedsl.it. [188.219.235.30]) by smtp.gmail.com with ESMTPSA id o9sm27490737wrh.46.2019.10.14.11.18.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Oct 2019 11:18:49 -0700 (PDT) Date: Mon, 14 Oct 2019 20:18:47 +0200 From: Tomas Vondra To: dangal Cc: pgsql-performance@postgresql.org Subject: Re: pg_stat_bgwriter Message-ID: <20191014181847.6lf5s3fwuh7ui25r@development> References: <1571016455698-0.post@n3.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1571016455698-0.post@n3.nabble.com> User-Agent: NeoMutt/20180716 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sun, Oct 13, 2019 at 06:27:35PM -0700, dangal wrote: >Dear I would like to share with you to see what you think about the >statistics of pg_stat_bgwriter > >postgres = # select * from pg_stat_bgwriter; > checkpoints_timed | checkpoints_req | checkpoint_write_time | >checkpoint_sync_time | buffers_checkpoint | buffers_clean | maxwritten_clean >| buffers_backend | buffers_ >backend_fsync | buffers_alloc | stats_reset >------------------- + ----------------- + ------------ ----------- + >---------------------- + --------------- ----- + --------------- + >------------------ + --------- -------- + --------- >-------------- + --------------- + ------------------- ------------ >               338 | 6 | 247061792 | 89418 | 2939561 | 19872289 | 54876 | >6015787 | >            0 | 710682240 | 2019-10-06 19: 25: 30.688186-03 >(1 row) > >postgres = # show bgwriter_delay; > bgwriter_delay >---------------- > 200ms >(1 row) > >postgres = # show bgwriter_lru_maxpages; > bgwriter_lru_maxpages >----------------------- > 100 >(1 row) > >postgres = # show bgwriter_lru_multiplier; > bgwriter_lru_multiplier >------------------------- > 2 >(1 row) > > >Do you think it should increase bgwriter_lru_maxpages due to the value of >maxwritten_clean? >Do you think it should increase bgwriter_lru_maxpages, >bgwriter_lru_multiplier, and decrease bgwriter_delay due to the value of >buffers_backend compared to buffers_alloc? >Do you think a modification is necessary? >What values ​​would you recommend? buffers_alloc does not really matter, here, IMO. You need to compare buffers_checkpoint, buffers_backend and buffers_clean, and ideally you'd have (checkpoints > clean > backend). In your case it's already buffers_checkpoint | buffers_clean | buffers_backend 2939561 | 19872289 | 6015787 You could make bgwriter even more aggressive, but that's unlikely to be a huge improvement. You should investigate why buffers_checkpoint is so low. This is usually a sign of shared_buffers being too small for the active set, so perhaps you need to increase shared_buffers, or see which queries are causing this and optimize them. Note: FWIW, a single snapshot of pg_stats* may be misleading, because it's cumulative, so it's not clear how accurately it reflects current state. Next time take two snapshots and subtract them. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services