Message-ID: <5155A853.1080102@ulb.ac.be>
Date: Fri, 29 Mar 2013 15:42:27 +0100
From: Julien Cigar <jcigar@ulb.ac.be>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
	rv:17.0) Gecko/20130322 Thunderbird/17.0.4
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Postgresql performance degrading... how to diagnose the root
 cause
References: <5155A33A.4090000@axege.com>
In-Reply-To: <5155A33A.4090000@axege.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 03/29/2013 15:20, Franck Routier wrote:
> Hi,
>

Hello,

> I have a postgresql database (8.4) running in production whose 
> performance is degrading.
> There is no single query that underperforms, all queries do.
> Another interesting point is that a generic performance test 
> (https://launchpad.net/tpc-b) gives mediocre peformance when run on 
> the database, BUT the same test on a newly created database, on the 
> same pg cluster, on the same tablespace, does perform good.
>
> So the problem seems to be limited to this database, even on newly 
> created tables...
>
> What should I check to find the culprit of this degrading performance ?
>

Difficult to answer with so few details, but I would start by logging 
slow queries, and run an explain analyze on them (or use auto_explain).
Check if you're CPU bound or I/O bound (top, iostats, vmstat, systat, 
gstat..), check your configuration (shared_buffers, 
effective_cache_size, work_mem, checkpoint_segments, cpu_tuple_cost, ...)

> Franck
>


-- 
No trees were killed in the creation of this message.
However, many electrons were terribly inconvenienced.


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