Re: Slow Vacuum was: vacuum output question

Поиск
Список
Период
Сортировка
От Dan Armbrust
Тема Re: Slow Vacuum was: vacuum output question
Дата
Msg-id 82f04dc40901120901jedd8c6bjdea32d30dc6208c8@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Slow Vacuum was: vacuum output question  ("Scott Marlowe" <scott.marlowe@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Shane Ambler
Дата:
Сообщение: Re: Data comparison SQL in PG 8.2.9
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: PgUS 2008 end of year summary