Re: autovacuum daemon stops doing work after about an hour

From: Vivek Khera <khera(at)kcilink(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: autovacuum daemon stops doing work after about an hour
Date: 2003-12-04 16:33:59
Message-ID: 16335.25079.106697.7521@yertle.int.kciLink.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

>>>>> "MTO" == Matthew T O'Connor <matthew(at)zeut(dot)net> writes:

>> Then it just sits there. I started it at 11:35am, and it is now
>> 3:30pm.

MTO> Weird.... Alphabetically speaking, is vkmlm."public"."user_list" be the
MTO> last table in the last schema in the last database? You are running

conveniently, yes it is...

MTO> with -d4, so you would get a message about going to sleep shortly after
MTO> dealing with the last table, but you didn't get the sleep message, so I
MTO> don't think the problem is that pg_autovacuum is sleeping for an
MTO> inordinate amount time.

The only sleep logged was

[2003-12-03 04:47:13 PM] 1 All DBs checked in: 84996853 usec, will sleep for 469 secs.

Here's all it did on yesterday afternoon's "hour of work":

[2003-12-03 04:45:48 PM] Performing: ANALYZE "public"."url_track"
[2003-12-03 04:46:27 PM] Performing: ANALYZE "public"."msg_recipients"
[2003-12-03 04:46:55 PM] Performing: ANALYZE "public"."deliveries"
[2003-12-03 04:46:55 PM] Performing: ANALYZE "public"."user_list"
[2003-12-03 04:47:12 PM] Performing: ANALYZE "public"."sessions"
[2003-12-03 04:55:02 PM] Performing: ANALYZE "public"."url_track"
[2003-12-03 04:55:22 PM] Performing: VACUUM ANALYZE "public"."msg_recipients"
[2003-12-03 05:40:11 PM] Performing: VACUUM ANALYZE "public"."user_list"

then 18 minutes later, it reported:

[2003-12-03 05:58:25 PM] select relfilenode,reltuples,relpages from pg_class where relfilenode=18588202
[2003-12-03 05:58:25 PM] table name: vkmlm."public"."user_list"
[2003-12-03 05:58:25 PM] relfilenode: 18588202; relisshared: 0
[2003-12-03 05:58:25 PM] reltuples: 9; relpages: 427920
[2003-12-03 05:58:25 PM] curr_analyze_count: 2559236; cur_delete_count: 2475824
[2003-12-03 05:58:25 PM] ins_at_last_analyze: 2559236; del_at_last_vacuum: 2475824
[2003-12-03 05:58:25 PM] insert_threshold: 509; delete_threshold 1001

and stopped doing anything.

MTO> when you kill it, do you get a core file? Could you do a backtrace and
MTO> see where pg_autovacuum is hung up?

nope. unfortunately my PG libs are without debugging, too. I'll
rebuild pg_autovacuum with debugging and run it under gdb so I can see
where it gets stuck.

I'll report back when I find something. I just wanted to check first
if anyone else ran into this.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2003-12-04 16:37:18 Re: Minor (very) feature request...
Previous Message Steve Wampler 2003-12-04 16:29:53 Minor (very) feature request...

Browse pgsql-performance by date

  From Date Subject
Next Message Josh Berkus 2003-12-04 16:59:06 Re: tuning questions
Previous Message Jack Coates 2003-12-04 16:06:23 tuning questions