Re: autovacuum stress-testing our system - Mailing list pgsql-hackers

On 26-09-2012 09:43, Tomas Vondra wrote:
> I've been struggling with autovacuum generating a lot of I/O and CPU on some
> of our
> systems - after a night spent analyzing this behavior, I believe the current
> autovacuum accidentally behaves a bit like a stress-test in some corner cases
> (but
> I may be seriously wrong, after all it was a long night).
> 
It is known that statistic collector doesn't scale for a lot of databases. It
wouldn't be a problem if we don't have automatic maintenance (aka autovacuum).

> Next, I'm thinking about ways to solve this:
> 
> 1) turning of autovacuum, doing regular VACUUM ANALYZE from cron - certainly an
>    option, but it's rather a workaround than a solution and I'm not very fond of
>    it. Moreover it fixes only one side of the problem - triggering the statfile
>    writes over and over. The file will be written anyway, although not that
>    frequently.
> 
It solves your problem if you combine scheduled VA with pgstat.stat in a
tmpfs. I don't see it as a definitive solution if we want to scale auto
maintenance for several hundreds or even thousands databases in a single
cluster (Someone could think it is not that common but in hosting scenarios
this is true. DBAs don't want to run several VMs or pg servers just to
minimize the auto maintenance scalability problem).

> 2) tweaking the timer values, especially increasing PGSTAT_RETRY_DELAY and so on
>    to consider several seconds to be fresh enough - Would be nice to have this
>    as a GUC variables, although we can do another private patch on our own. But
>    more knobs is not always better.
> 
It doesn't solve the problem. Also it could be a problem for autovacuum (that
make assumptions based in those fixed values).

> 3) logic detecting the proper PGSTAT_RETRY_DELAY value - based mostly on the time
>    it takes to write the file (e.g. 10x the write time or something).
> 
Such adaptive logic would be good only iff it takes a small time fraction to
execute. It have to pay attention to the limits. It appears to be a candidate
for exploration.

> 4) keeping some sort of "dirty flag" in stat entries - and then writing only info
>    about objects were modified enough to be eligible for vacuum/analyze (e.g.
>    increasing number of index scans can't trigger autovacuum while inserting
>    rows can). Also, I'm not worried about getting a bit older num of index scans,
>    so 'clean' records might be written less frequently than 'dirty' ones.
> 
It minimizes your problem but harms collector tools (that want fresh
statistics about databases).

> 5) splitting the single stat file into multiple pieces - e.g. per database,
>    written separately, so that the autovacuum workers don't need to read all
>    the data even for databases that don't need to be vacuumed. This might be
>    combined with (4).
> 
IMHO that's the definitive solution. It would be one file per database plus a
global one. That way, the check would only read the global.stat and process
those database that were modified. Also, an in-memory map could store that
information to speed up the checks. The only downside I can see is that you
will increase the number of opened file descriptors.

> Ideas? Objections? Preferred options?
> 
I prefer to attack 3, sort of 4 (explained in 5 -- in-memory map) and 5.

Out of curiosity, did you run perf (or some other performance analyzer) to
verify if some (stats and/or autovac) functions pop up in the report?


--   Euler Taveira de Oliveira - Timbira       http://www.timbira.com.br/  PostgreSQL: Consultoria, Desenvolvimento,
Suporte24x7 e Treinamento