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.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
