Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id DE6C4B5DBDA for ; Mon, 5 Sep 2011 17:05:19 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 87949-02 for ; Mon, 5 Sep 2011 20:05:09 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zeus.simkin.ca (zeus.simkin.ca [72.51.27.124]) by mail.postgresql.org (Postfix) with ESMTP id 91517B5D803 for ; Mon, 5 Sep 2011 17:05:08 -0300 (ADT) Received: from charon.medialogik.com (S0106c43dc79b28be.vc.shawcable.net [96.49.251.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zeus.simkin.ca (Postfix) with ESMTPSA id 16C802700AA for ; Mon, 5 Sep 2011 13:05:07 -0700 (PDT) From: Alan Hodgson Organization: Simkin Network Consulting To: pgsql-performance@postgresql.org Subject: Re: Rather large LA Date: Mon, 5 Sep 2011 13:05:06 -0700 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; i686; ; ) References: <4E64D0FE.6020704@squeakycode.net> <97BCA6CA-A1DB-43C7-B710-C2836B656FD6@aggress.net> In-Reply-To: <97BCA6CA-A1DB-43C7-B710-C2836B656FD6@aggress.net> X-KMail-Markup: true MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary-01=_ytSZOOOFavOGtHc" Content-Transfer-Encoding: 7bit Message-Id: <201109051305.07010@hal.medialogik.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.403 tagged_above=-10 required=5 tests=BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.504 X-Spam-Level: X-Archive-Number: 201109/48 X-Sequence-Number: 44824 --Boundary-01=_ytSZOOOFavOGtHc Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On September 5, 2011, Richard Shaw wrote: > Hi Andy, > > It's not a new issue no, It's a legacy system that is in no way ideal but > is also not in a position to be overhauled. Indexes are correct, tables > are up to 25 million rows. > > On startup, it hits CPU more than IO, I'll provide some additional stats > after I restart it tonight. I bet it's I/O bound until a good chunk of the active data gets cached. Run a vmstat 1 while it's that busy, I bet most of the cpu time is really in io_wait. --Boundary-01=_ytSZOOOFavOGtHc Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

On September 5, 2011, Richard Shaw <richard@aggress.net> wrote:

> Hi Andy,

>

> It's not a new issue no, It's a legacy system that is in no way ideal but

> is also not in a position to be overhauled. Indexes are correct, tables

> are up to 25 million rows.

>

> On startup, it hits CPU more than IO, I'll provide some additional stats

> after I restart it tonight.


I bet it's I/O bound until a good chunk of the active data gets cached. Run a vmstat 1 while it's that busy, I bet most of the cpu time is really in io_wait.


--Boundary-01=_ytSZOOOFavOGtHc--