Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id D16A5101438F for ; Thu, 1 Mar 2012 19:42:13 -0400 (AST) Received: from mail-pw0-f46.google.com ([209.85.160.46]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1S3FdT-000698-ED for pgsql-admin@postgresql.org; Thu, 01 Mar 2012 23:42:12 +0000 Received: by pbcup15 with SMTP id up15so1449946pbc.19 for ; Thu, 01 Mar 2012 15:41:58 -0800 (PST) Received-SPF: pass (google.com: domain of brianf@consistentstate.com designates 10.68.216.4 as permitted sender) client-ip=10.68.216.4; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brianf@consistentstate.com designates 10.68.216.4 as permitted sender) smtp.mail=brianf@consistentstate.com Received: from mr.google.com ([10.68.216.4]) by 10.68.216.4 with SMTP id om4mr8666022pbc.19.1330645318355 (num_hops = 1); Thu, 01 Mar 2012 15:41:58 -0800 (PST) Received: by 10.68.216.4 with SMTP id om4mr7157451pbc.19.1330645318313; Thu, 01 Mar 2012 15:41:58 -0800 (PST) Received: from sidon.consistentstate.com (74-93-229-125-Colorado.hfc.comcastbusiness.net. [74.93.229.125]) by mx.google.com with ESMTPS id 2sm3275987pbw.57.2012.03.01.15.41.56 (version=SSLv3 cipher=OTHER); Thu, 01 Mar 2012 15:41:57 -0800 (PST) Message-ID: <4F500868.8060603@consistentstate.com> Date: Thu, 01 Mar 2012 16:38:16 -0700 From: Brian Fehrle User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.26) Gecko/20120129 Lightning/1.0b2 Thunderbird/3.1.18 MIME-Version: 1.0 To: Simon Riggs CC: pgsql-admin@postgresql.org Subject: Re: Hot standby having high requested checkpoints? References: <4F4D5AE0.9020204@consistentstate.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmeMHUfVlgEkP3W68DEVw8tscLYOo+ePkddc0fSCszt+IyTXx8BKBr13S6Jmh67lFkCXvCZ X-Pg-Spam-Score: -2.6 (--) X-Archive-Number: 201203/5 X-Sequence-Number: 39193 I just now ran the following query a few times after each other on the hot standby: select now(), * from pg_stat_bgwriter; Here are the results: now | checkpoints_timed | checkpoints_req | buffers_checkpoint | buffers_clean | maxwritten_clean | buffers_backend | buffers_alloc -------------------------------+-------------------+-----------------+--------------------+---------------+------------------+-----------------+--------------- 2012-03-01 23:24:49.099194+00 | 11546 | 145300 | 1000409459 | 38483026 | 170724 | 5058186 | 438703950 2012-03-01 23:24:52.139176+00 | 11546 | 145300 | 1000409459 | 38483027 | 170724 | 5058191 | 438703975 2012-03-01 23:24:59.129171+00 | 11546 | 145302 | 1000409459 | 38483081 | 170724 | 5058214 | 438704438 2012-03-01 23:25:05.957532+00 | 11546 | 145304 | 1000409459 | 38483118 | 170724 | 5058230 | 438704689 2012-03-01 23:25:09.519175+00 | 11546 | 145305 | 1000409459 | 38483160 | 170724 | 5058239 | 438704968 2012-03-01 23:25:37.019194+00 | 11546 | 145308 | 1000409459 | 38483259 | 170724 | 5058255 | 438705566 2012-03-01 23:25:40.659164+00 | 11546 | 145308 | 1000409459 | 38483268 | 170724 | 5058257 | 438705639 2012-03-01 23:25:47.239281+00 | 11546 | 145309 | 1000409459 | 38483283 | 170724 | 5058266 | 438705815 2012-03-01 23:26:23.858716+00 | 11546 | 145312 | 1000409459 | 38483393 | 170724 | 5058307 | 438706561 2012-03-01 23:26:46.467493+00 | 11546 | 145317 | 1000409670 | 38483524 | 170724 | 5058354 | 438707619 in two minutes, I saw 17 checkpoints_req, and the number of buffers_checkpoint didn't budge till the last few and even then not much. checkpoint_segments = 256 - Brian F On 03/01/2012 01:35 AM, Simon Riggs wrote: > On Tue, Feb 28, 2012 at 10:53 PM, Brian Fehrle > wrote: > >> I have two PostgreSQL 9.0.5 clusters, one is a master and the other is a hot >> standby via streaming replication. I'm monitoring some stats on each and I'm >> noticing something very odd. On the master, I get between 2 and 4 requested >> checkpoints per hour, but on the hot standby I'm seeing between 200 and 300 >> requested checkpoints per hour. > We don't do a restartpoint on the standby unless we see a checkpoint > record, so that result should be impossible. > > So I'm guessing you're reading the stats wrong? >