Matthew,
This is from long ago, but I've finally had some time to continue to
investigate the problem of CPU spikes in pg_autovacuum. update_db_list
is provably one of the culprits, but it doesn't seem to be the only
one.
In looking through the code, it doesn't seem as though any vacuuming
can be done during the update of the list, correct? But after I
increased my debug setting (>= 2 is what's needed, actually, for the
update message to show up), I waited around for the next update and,
sure enough, CPU shot up. But it never dropped across the course of the
entire run of the db_list loop.
I'm going to increase UPDATE_INTERVAL per your suggestion, but I should
expect heavy CPU usage during each pass through the db_list loop,
regardless of whether or not the list has been updated?
Thanks!
-tfo
--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005
On Sep 2, 2004, at 6:28 AM, Matthew T. O'Connor wrote:
> Thomas F.O'Connell wrote:
>> On Sep 1, 2004, at 10:27 PM, Matthew T. O'Connor wrote:
>>> Number of rows is irrelevant, but the number of tables might not be.
>>> It could be that the process of checking it's list of tables
>>> against the server might be slow when used with lots of tables.
>>> Does this cpu spike happen every other loop?
>> Is there an easy way to determine if it's happening every other loop?
>
> Yes, if you are running pg_autovacuum with a debug setting >= 1 it
> will write out a message at the end of every loop.
>
>>> Try the simple recompile with the larger update interval first and
>>> see if that's the problem.
>> How difficult would it be to make this a command-line argument if it
>> turns out to be a run-time issue?
>
> Very Easy.
