Re: Vacuum I/O throttling - Mailing list pgsql-bugs

From Guy Thornley
Subject Re: Vacuum I/O throttling
Date
Msg-id 20030901234859.GB25592@conker.esphion.com
Whole thread Raw
In response to Re: Vacuum I/O throttling  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Vacuum I/O throttling  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: session variable
Next
From: Tom Lane
Date:
Subject: Re: Vacuum I/O throttling