Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WV6aL-00060p-TN for pgsql-performance@arkaria.postgresql.org; Tue, 01 Apr 2014 21:51:10 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WV6aL-0001Bk-8E for pgsql-performance@arkaria.postgresql.org; Tue, 01 Apr 2014 21:51:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WV6aK-0001Bc-8t for pgsql-performance@postgresql.org; Tue, 01 Apr 2014 21:51:08 +0000 Received: from mail-la0-f43.google.com ([209.85.215.43]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WV6aG-0004Ws-Ac for pgsql-performance@postgresql.org; Tue, 01 Apr 2014 21:51:07 +0000 Received: by mail-la0-f43.google.com with SMTP id e16so7635482lan.30 for ; Tue, 01 Apr 2014 14:51:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=MaPO5X91b0jnqeQXldczbjPgQbGY3JECOanB9eggAgw=; b=ck6fYp410Fy65OBmPi+y1ZbaFmwTlHbWXE6u4gqCq24IfZCWM1VsXgvysl9lj94M5Y eXEnNK9oSlhXtn88HdKvLsg6ZOHbCQUy/5mFE2DEsY3XIACz56jrlJUGcyr8F7Cy8Gy5 0ZHS3fu6sG5UxMOF+eMHrii4kwvMjfUOs/okfZ+7AFodccB4ILoApCW0DtjXSIaDJf5A KMLicKQ5kDV0/rUMTu6gLog5YyuW1MQr3xjcRELuVpTT+5c6SnPPmmirXJsD2lANDyEp mQ7Z5VQTdxD6BmVw1V/s3EX/GWg35MJNTBb40cFw0XzUSZo2b9gOd1Uz6tjvTRIfok7G +vYg== X-Gm-Message-State: ALoCoQnFT5lZhXihf3p8G48hZfueVQ1g/NYZBa8Y0s6eIwYnIGsbz/ebOTHv0KfXNN2zQoJlAExl X-Received: by 10.112.128.131 with SMTP id no3mr154780lbb.57.1396389062916; Tue, 01 Apr 2014 14:51:02 -0700 (PDT) Received: from [192.168.0.16] (x1-6-84-1b-5e-20-07-92.cpe.webspeed.dk. [80.167.117.15]) by mx.google.com with ESMTPSA id tq9sm12940108lbb.10.2014.04.01.14.51.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 14:51:01 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D5B93B2A-9F2F-4CFD-A36B-4BD266215DE1" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Sudden crazy high CPU usage From: =?iso-8859-1?Q?Niels_Kristian_Schj=F8dt?= In-Reply-To: Date: Tue, 1 Apr 2014 23:50:59 +0200 Cc: "pgsql-performance@postgresql.org list" Message-Id: References: <24BBD031-7384-4FFF-848B-90F5664C0063@autouncle.com> To: Will Platnick X-Mailer: Apple Mail (2.1874) 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 --Apple-Mail=_D5B93B2A-9F2F-4CFD-A36B-4BD266215DE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Sorry, but nothing unusual here either, I have compared the time just = before with the same time the days before and the throughput pattern is = exactly the same. No differences. Den 31/03/2014 kl. 22.01 skrev Will Platnick : >=20 > In New Relic, go back a half hour before the problem started so you = can't see that this spike happened and send the same screenshot in. My = guess is you have increased activity hitting the DB. Do you have = pgbouncer or some kind of connection pooling sitting in front? 198 open = server connections could account for an increase in load like you're = seeing. Do you have postgresql addon in New Relic to show you how many = queries are hitting the system to correlate data to? >=20 > On Mon, Mar 31, 2014 at 1:36 PM, Sergey Konoplev = wrote: > On Mon, Mar 31, 2014 at 3:25 AM, Niels Kristian Schj=F8dt > wrote: > > I'm running postgresql 9.3 on a production server. An hour ago, out = of the "blue", I ran into an issue I have never encountered before: my = server started to use CPU as crazy. The server is a standard ubuntu = 12.04 LTE installation running only Postgres and Redis. > > > > The incident can be seen on the in numbers below: > > > > https://s3-eu-west-1.amazonaws.com/autouncle-public/other/cpu.png >=20 > The increase doesn't look so sudden. My guess is that the server got > some new activity. The advice is to setup the statistics collecting > script by the link [1] and review the results for a period of hour or > so. It shows charts of statements by CPU/IO/calls with aggregated > stats, so you could probably find out more than with pure > pg_stat_statements. >=20 > [1] = https://github.com/grayhemp/pgcookbook/blob/master/statement_statistics_co= llecting_and_reporting.md >=20 > -- > Kind regards, > Sergey Konoplev > PostgreSQL Consultant and DBA >=20 > http://www.linkedin.com/in/grayhemp > +1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979 > gray.ru@gmail.com >=20 >=20 > -- > Sent via pgsql-performance mailing list = (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance >=20 --Apple-Mail=_D5B93B2A-9F2F-4CFD-A36B-4BD266215DE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Sorry, but nothing unusual here either, I = have compared the time just before with the same time the days before = and the throughput pattern is exactly the same. No = differences.


Den 31/03/2014 kl. 22.01 skrev Will Platnick = <wplatnick@gmail.com>:


In New Relic, go = back a half hour before the problem started so you can't see that this = spike happened and send the same screenshot in. My guess is you have = increased activity hitting the DB. Do you have pgbouncer or some kind of = connection pooling sitting in front? 198 open server connections could = account for an increase in load like you're seeing. Do you have = postgresql addon in New Relic to show you how many queries are hitting = the system to correlate data to?

On Mon, Mar 31, 2014 at 1:36 PM, Sergey = Konoplev <gray.ru@gmail.com> wrote:
On Mon, Mar 31, 2014 at 3:25 AM, = Niels Kristian Schj=F8dt
<nielskristian@autouncle.com> wrote:
> I'm running postgresql 9.3 on a production server. An hour ago, out = of the "blue", I ran into an issue I have never encountered before: my = server started to use CPU as crazy. The server is a standard ubuntu = 12.04 LTE installation running only Postgres and Redis.
>
> The incident can be seen on the in numbers below:
>
> https://s3-eu-west-1.amazonaws.com/autouncle-public/othe= r/cpu.png

The increase doesn't look so sudden. My guess is that the server = got
some new activity. The advice is to setup the statistics collecting
script by the link [1] and review the results for a period of hour = or
so. It shows charts of statements by CPU/IO/calls with aggregated
stats, so you could probably find out more than with pure
pg_stat_statements.

[1] https://github.com/grayhemp/pgcookbook/blob/master/state= ment_statistics_collecting_and_reporting.md

--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA

http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray.ru@gmail.com


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance=


= --Apple-Mail=_D5B93B2A-9F2F-4CFD-A36B-4BD266215DE1--