Re: Slow Vacuum was: vacuum output question - Mailing list pgsql-general

From Dan Armbrust
Subject Re: Slow Vacuum was: vacuum output question
Date
Msg-id 82f04dc40901120901jedd8c6bjdea32d30dc6208c8@mail.gmail.com
Whole thread Raw
In response to Re: Slow Vacuum was: vacuum output question  ("Scott Marlowe" <scott.marlowe@gmail.com>)
List pgsql-general
> Well, your throughput on this machine is horrible.  It looks like with
> 8.1 all your time is sys + cpu for your cpus, while with 8.3 you've
> got more idle and more i/o wait, which tells me that 8.3 is smarter
> about vacuuming, so it's spending less time working the cpus and more
> time waiting for the i/o subsystem.
>
> Wither way, getting only 2 or so megs a second write is pretty bad.  I
> can get those numbers from a laptop.  An older laptop like a single
> core 1.6GHz pentium M based T42 or something.  My laptop, which is new
> from last year, is about twice as fast as your server in terms of I/O.

This is my problem in a nutshell.  As of yet, I have no rational
explanation for this performance.

The servers in question are not slow.  This particular server never
shows this problem when running a newer OS - but I have not yet
finished isolating which OS's have problems on this hardware.  No
other software on the system exhibits any sort of IO issue other than
PostgreSQL.

I have customers with $20K servers that can't handle the workload that
I can handle on an old cruddy laptop.  However, much of the appeal of
our product is low per-site installation costs, so expensive servers
don't fit into the mix.

Random futzing - reindexing, manual full vacuums, rebooting the server
- each of these has cleared the error condition on one site or
another, and allowed the system to go back to functioning the way it
should for months, until the problem randomly crops up again.

I'm still looking into it, but, at the same time, we have enough
workarounds to the issue now (scheduled reindex, install a newer OS,
upgrade to Postgres 8.3)  that this is becoming a low priority
mystery, rather than the high priority one it has been.

Thanks for your thoughts,

Dan

pgsql-general by date:

Previous
From: Shane Ambler
Date:
Subject: Re: Data comparison SQL in PG 8.2.9
Next
From: "Joshua D. Drake"
Date:
Subject: PgUS 2008 end of year summary