From: | Vincent de Phily <vincent(dot)dephily(at)mobile-devices(dot)fr> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Never-idle autovacuum, and does (auto)vacuuming fill the OS cache ? |
Date: | 2011-10-06 09:58:15 |
Message-ID: | 3861269.XRBYzV9rak@moltowork |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi list,
I've got a heavily-updated table, and about 30 customers on the same system
each with his own version of the table. The 3 configured autovacuum workers
take turns vacuuming the table in each customer db; autovacuum is never idle
and takes a large part of the available IO.
Fearing that vacuuming might accumulate lateness and hoping to see the system
idle every now and then, I increased autovacuum_vacuum_cost_limit to 500 and
decreased autovacuum_vacuum_cost_delay to 10. First question : is it an
intelligent thing to do or am I better off ignoring the constant vacuuming and
trusting that things will get done in time ? With the new settings, autovacuum
is still constant (even though each one takes less time), but I'm wary of
making autovacuum even less "io-nice".
Second thing : the vacuumed tables+indexes taken together are bigger than the
available OS disk cache. Does vacuuming them fill the cache, or is there some
kind of O_DIRECT in use ? I have a feeling (very un-verified) that this is not
the most usefull data I could have in my cache.
This is all on PG 8.3. I know upgrading would improve things (particularly
since a large percentage of the table remains static between vacuums), but
we're still too busy for that right now (unless you tell me I'm going to see a
night-and-day difference regarding this particular issue).
Thanks.
--
Vincent de Phily
From | Date | Subject | |
---|---|---|---|
Next Message | Alban Hertroys | 2011-10-06 10:01:12 | Re: Postgresql Data directory Issue |
Previous Message | Rory Campbell-Lange | 2011-10-06 09:57:26 | Strange primary key error on insertion |