Re: High CPU load caused by the autovacuum launcher process

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Owayss Kabtoul <owayssk(at)gmail(dot)com>
Cc: pgsql-admin(at)lists(dot)postgresql(dot)org
Subject: Re: High CPU load caused by the autovacuum launcher process
Date: 2018-06-08 15:41:13
Message-ID: 24641.1528472473@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

Owayss Kabtoul <owayssk(at)gmail(dot)com> writes:
> I ran into an issue where, on Postgres instances that have a very large
> number of databases per cluster (~15K), the autovacuum process seems to
> have a very high impact on CPU usage.

That's, um, not a very reasonable configuration.

> So auto-vacuum never really sleeps. Even changing the autovacuum_naptime
> and setting it to a much higher value (from 1min to 50min) did not have any
> effect at all.

Simple arithmetic says that even at 50min, the launcher will have to
launch one worker every 0.2 seconds in order to visit every database
once per naptime.

You could raise the naptime setting by another factor of 10 and then
the launcher would only have to wake up every other second ... but
these DBs had better all have extremely light workloads, or you're
risking terrible bloat due to tables only getting vacuumed a couple
times per day.

On the whole, I'd revisit why you need so many DBs per cluster.
Quite aside from autovacuum performance issues, you're expending
~100GB just on redundant copies of the system catalogs; that can't
be helping disk cache performance, for instance. (Or, if you've
got a box that's so beefy you just don't care about that, why are
you worried about the launcher?)

regards, tom lane

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Saeed Ahmed (DB) 2018-06-08 18:27:53 pg_basebackup: could not get write-ahead log end position from server: ERROR
Previous Message Jeff Janes 2018-06-08 13:59:20 Re: High CPU load caused by the autovacuum launcher process

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-06-08 15:57:47 Re: Code of Conduct plan
Previous Message Alvaro Herrera 2018-06-08 15:24:20 Re: Needless additional partition check in INSERT?