Re: Vacuum I/O throttling

Поиск
Список
Период
Сортировка
От Guy Thornley
Тема Re: Vacuum I/O throttling
Дата
Msg-id 20030901234859.GB25592@conker.esphion.com
обсуждение исходный текст
Ответ на Re: Vacuum I/O throttling  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Vacuum I/O throttling  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On Mon, Sep 01, 2003 at 09:05:33AM -0400, Tom Lane wrote:
> Guy Thornley <guy@esphion.com> writes:
> > Below is a patch for the lazy vacuum. It implements a simple I/O throttle so
> > boxen arnt killed for hours a day when VACUUM runs.
>
> Wasn't this idea tried and rejected already?  You haven't given us any
> information about actual performance.
I don't know, sorry; when I looked at the archives I only saw posts about
tuning vacuums, memory usage, etc, and people griping about the way it nukes
the I/O system. I'm new here.

What sort of performance numbers are you looking for? Without the throttle,
I/O is nuked and other database activity takes an age, and with it, its much
happier?

More seriously, this patch isnt meant to actually deal with vacuumed tuples.
The application being developed by the company I am working for requires
24x7x365 unattended operation. Even if vacuum ran every 6 months, for the
transaction renumbering stuff, the way it nukes I/O is not acceptable.
Especially on (potentially) several-hundred gig databases.

We are beginning to learn that "DBMS" and "unattended" dont belong in the
same sentence.

> > The usleep() could be replaced with a select() call with a timeout an no
> > fd_set's to aid portability..
>
> usleep is not portable, AFAIR.
>
>             regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: session variable
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Vacuum I/O throttling