Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1X1gU6-0006yv-LI for pgsql-performance@arkaria.postgresql.org; Mon, 30 Jun 2014 18:39:22 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1X1gU6-0002aB-5l for pgsql-performance@arkaria.postgresql.org; Mon, 30 Jun 2014 18:39:22 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1X1gU5-0002a3-9e for pgsql-performance@postgresql.org; Mon, 30 Jun 2014 18:39:21 +0000 Received: from mail.anarazel.de ([217.115.131.40]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1X1gTy-00073N-2K for pgsql-performance@postgresql.org; Mon, 30 Jun 2014 18:39:19 +0000 Received: by mail.anarazel.de (Postfix, from userid 108) id BD2D3500001; Mon, 30 Jun 2014 20:39:12 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail X-Spam-Level: X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from anarazel.de (p54AF441C.dip0.t-ipconnect.de [84.175.68.28]) (Authenticated sender: andres@anarazel.de) by mail.anarazel.de (Postfix) with ESMTPSA id A3DBD4F0001; Mon, 30 Jun 2014 20:39:08 +0200 (CEST) Received: by anarazel.de (Postfix, from userid 1000) id 380FC100041; Mon, 30 Jun 2014 20:39:08 +0200 (CEST) Date: Mon, 30 Jun 2014 20:39:08 +0200 From: Andres Freund To: Jeff Frost Cc: Soni M , Heikki Linnakangas , pgsql-performance@postgresql.org Subject: Re: Postgres Replaying WAL slowly Message-ID: <20140630183908.GT26930@awork2.anarazel.de> References: <53AFCEE3.4080009@vmware.com> <53B10C4C.8090701@vmware.com> <53B18CE0.4060501@vmware.com> <20140630171416.GK21422@awork2.anarazel.de> <8DA8C140-818D-4184-AAE6-CA37278B983C@pgexperts.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8DA8C140-818D-4184-AAE6-CA37278B983C@pgexperts.com> X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 2014-06-30 11:34:52 -0700, Jeff Frost wrote: > On Jun 30, 2014, at 10:29 AM, Soni M wrote: > > It is > > 96.62% postgres [.] StandbyReleaseLocks > > as Jeff said. It runs quite long time, more than 5 minutes i think > > > > i also use hot standby. we have 4 streaming replica, some of them has active connection some has not. this issue has last more than 4 days. On one of the standby, above postgres process is the only process that consume high cpu load. > > compiled with -fno-omit-frame-pointer doesn't yield much more info: You'd need to do perf record -ga instead of perf record -a to see additional information. But: > 76.24% postgres [.] StandbyReleaseLocks already is quite helpful. What are you doing on that system? Is there anything requiring large amounts of access exclusive locks on the primary? Possibly large amounts of temporary relations? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance