Re: tuning auto vacuum for highly active tables

From: "Bhella Paramjeet-PFCW67" <PBhella(at)Motorola(dot)com>
To: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
Cc: <pgsql-admin(at)postgresql(dot)org>
Subject: Re: tuning auto vacuum for highly active tables
Date: 2010-03-23 23:28:03
Message-ID: C84662912D280D4AB5C50100A100F0C50574C7DD@ct11exm61.ds.mot.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-performance

Hi Scott,

Thanks for replying.
Can you explain what you mean by increase the number of threads or how I can increase the number of threads? I just have 2 tables that are very active. I am using postgres version 8.2.7 and 3510 storagetek array with 10 disks in raid 1+0.

Thanks
Paramjeet Kaur

-----Original Message-----
From: Scott Marlowe [mailto:scott(dot)marlowe(at)gmail(dot)com]
Sent: Tuesday, March 23, 2010 2:42 PM
To: Bhella Paramjeet-PFCW67
Cc: pgsql-admin(at)postgresql(dot)org; pgsql-performance(at)postgresql(dot)org
Subject: Re: [ADMIN] tuning auto vacuum for highly active tables

On Tue, Mar 23, 2010 at 2:54 PM, Bhella Paramjeet-PFCW67
<PBhella(at)motorola(dot)com> wrote:
> Hi All,
>
>
>
> We have a postgres database in which couple of tables get bloated due to
> heavy inserts and deletes. Auto vacuum is running. My question is  how can I
> make auto vacuum more aggressive? I am thinking of enabling
> autovacuum_vacuum_cost_delay and autovacuum_vacuum_cost_limit parameters.
> Can anyone suggest how to calculate the appropriate values for these
> parameters and if there are any side effects of enabling these parameters.
>  Any help will be highly appreciated.

OK, autovacuum runs x number of threads, and these threads can have
their IO impact limited by cost delay and cost limit.

Your first choice is based a lot on your db needs. If you have a lot
of large tables that all need to be vacuumed a lot, then you might
want to first increase the number of threads before making any of them
more aggressive. Then you might want to make the vacuums more
aggressive by lower cost_delay down from 20 to 10 or 5 or so
milliseconds.

On our servers we run 6 threads with a cost_delay of 3 or 4
milliseconds, and autovacuum keeps up without getting in the way. We
have a decent DAS array, so we can handle a lot of vacuum threads
running at once before they become an issue.

The smaller your disk set, the less you can throw vacuum at it and not
expect it to mess up the rest of the app. It's all a trade off, but
if you don't have more than a disk or two to throw at your db don't
expect vacuum to keep up with really heavy activity without impacting
your system's performance.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Scott Marlowe 2010-03-23 23:59:10 Re: tuning auto vacuum for highly active tables
Previous Message Scott Marlowe 2010-03-23 21:41:48 Re: tuning auto vacuum for highly active tables

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Marlowe 2010-03-23 23:30:48 Re: mysql to postgresql, performance questions
Previous Message Dave Crooke 2010-03-23 23:07:07 Re: mysql to postgresql, performance questions