Re: postgres eating CPU on HP9000

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Fabio Esposito <nfesposi(at)sourceweave(dot)net>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: postgres eating CPU on HP9000
Date: 2004-03-26 22:17:51
Message-ID: Pine.LNX.4.33.0403261516420.8192-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, 23 Mar 2004, Fabio Esposito wrote:

>
> Hello fellow PostgreSQL users.
>
> We've been working on this interesting issue for some time now, and we're
> hoping that someone can help.
>
> We've recently integrated postgres into an existing mature app. Its a
> time sensitive 24x7 system. It runs on HP9000, a K370 Dual Processor
> system. Postgres is version 7.3.2. Its spawned as a child from a parent
> supervisory process, and they communicate to eachother via shared memory.
>
> We preform 9-12K selects per hour
> 6-8K inserts per hour (a few updates here as well)
> 1-1.5K Deletes per hour.
>
> It maintains 48hours of data, so its not a large database; roughly
> <600mbs. We do this by running a housekeeping program in a cron job.
> It deletes all data older then 48hours, then vaccuum analyzes. It will
> also preform a reindex if the option is set before it vaccuum's.
>
> Postgres initially worked wonderfully, fast and solid. It
> preformed complex joins in 0.01secs, and was able to keep up with our
> message queue. It stayed this way for almost a year during our
> development.
>
> Recently it started eating up the cpu, and cannot keepup with the system
> like it used to. The interesting thing here is that it still runs great
> on an older system with less ram, one slower cpu, and an older disk.
>
> We tried the following with no success:
>
> running VACCUUM FULL
> dropping all tables and staring anew
> reinstalling postgres
> tweaking kernel parameters (various combos)
> tweaking postgres parameters (various combos)
> a number of other ideas

This almost sounds like a problem (fixed in 7.4 I believe) where some
system catalog indexes would get huge over time, and couldn't be vacuumed
or reindexed while the database was up in multi-user mode.

I'll defer to Tom or Bruce or somebody to say if my guess is even close...

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message scott.marlowe 2004-03-26 22:20:00 Re: odd planner choice
Previous Message Tom Lane 2004-03-26 21:53:40 Re: postgres eating CPU on HP9000