Re: Slow Vacuum was: vacuum output question

From: "Dan Armbrust" <daniel(dot)armbrust(dot)list(at)gmail(dot)com>
To: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Slow Vacuum was: vacuum output question
Date: 2009-01-12 17:01:11
Message-ID: 82f04dc40901120901jedd8c6bjdea32d30dc6208c8@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Joshua D. Drake 2009-01-12 20:23:45 PgUS 2008 end of year summary
Previous Message Shane Ambler 2009-01-12 16:07:53 Re: Data comparison SQL in PG 8.2.9