Re: Performance Problem - Mailing list pgsql-admin

From Frank Smith
Subject Re: Performance Problem
Date
Msg-id s0bdfbc0.056@uk.aeat.com
Whole thread Raw
In response to Performance Problem  ("Frank Smith" <frank.smith@aeat.co.uk>)
List pgsql-admin
Thanks to all

I will try the various options out and look to see if we can upgrade
and let you know the result.

It will take a few days as I am not officially here but on
holiday??????

Frank

>>> Frank Finner <postgresql@finner.de> 31/05/04 15:03:02 >>>
Hi,

I had a similiar problem with 7.3.5 some time ago (march 23rd). The
query durations increased extremely, as did the time vacuum needed. The
database
continuously (every 10 minutes) drops and creates tables as replication
of a
production database. "Vacuum analyze" did obviously not take care of
that and
did not release space correctly. Because my database is not so big
(about 1 GB),
I finally decided to dump, drop and recreate it out of the dump every
night.
This works fine for me. I was told on the list (Tom Lane did), that in
7.4 vacuum does handle these things in a much better way, so
dump/recreate is
no longer necessary. If possible (alas, not for me with my database),
I
recommend to upgrade to 7.4.

Regards, Frank Finner.


On 31 May 2004 12:41:07 +0200 Harald Fuchs <hf517@protecting.net> sat
down,
thought long and then wrote:

> In article <s0b610a3.089@uk.aeat.com>,
> "Frank Smith" <frank.smith@aeat.co.uk> writes:
>
> > Hi
> > ID:77777
>
> > I am running PostgreSQL 7.2.2 on Red Hat 9 and I am suffering a
growing
> > performance problem. The problem shows through a slowing of queries
and
> > an increase in the system CPU usage. Queries that took less than 6
> > seconds clime to take more than 5 minutes and as the system is
driven by
> > Apache through Perl scripts, the web server times out. Clearly I
could
> > reset the Apache timers, however this would just hide the problem
for a
> > little longer and of course once the problem starts to happen the
system
> > tends to cascade because the users try again and the orphaned
processes
> > continue to use processor time until they complete.
>
> > I use Cron to 'VACUUM ANALIZE' the system every night and this
greatly
> > improved the performance but has not stopped the delay from
growing. The
> > strange thing is that apart from the delay everything seems fine.
>
> If VACUUM does not stop the delay from growing, you might be
suffering
> index bloat.  Either REINDEX by crontab, or upgrade to 7.4, where
> VACUUM seems to take care of that.


***********************************************************************
This transmission contains information which may be confidential and
which may also be privileged.  It is intended for the named addressee
only.  Unless you are the named addressee, or authorised to receive it
on behalf of the addressee you may not copy or use it, or disclose it
to anyone else.  If you have received this transmission in error please
contact the sender.  Thank you for your cooperation.
***********************************************************************

For more information about AEA Technology please visit our website at http://www.aeat.co.uk

AEA Technology plc registered office 329 Harwell, Didcot, Oxfordshire OX11 0QJ.
Registered in England and Wales, number 3095862.


pgsql-admin by date:

Previous
From: "W. Scott Gibson"
Date:
Subject: Re: Postgresql lib and include files for SuSE 9.0 RPMS?
Next
From: "Krishna R Palati"
Date:
Subject: Re: Hot backup