Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Lonni J Friedman <netllama(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time
Date: 2011-11-23 02:57:41
Message-ID: 11335.1322017061@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Lonni J Friedman <netllama(at)gmail(dot)com> writes:
> When I strace PID 30188, I see tons of this scrolling past quickly,
> but I'm not really sure what it means beyond a 'Timeout' not looking
> good:
> select(0, NULL, NULL, NULL, {0, 32000}) = 0 (Timeout)
> lseek(95, 753901568, SEEK_SET) = 753901568
> read(95, "\202\1\0\0\260\315\250\245\1\0\0\0\220\0\360\20\360\37\4
> \0\0\0\0p\237\0\1\360\236\0\1"..., 8192) = 8192
> lseek(95, 753917952, SEEK_SET) = 753917952
> read(95, "\202\1\0\0 N\253\245\1\0\0\0\220\0\360\20\360\37\4
> \0\0\0\0p\237\0\1\360\236\0\1"..., 8192) = 8192
> select(0, NULL, NULL, NULL, {0, 32000}) = 0 (Timeout)

I'm betting the selects are implementing vacuum_cost_delay, and that
the reason this is taking forever is that you have that cranked up
to an unreasonably high value. There's no evidence of looping in
what you showed us, because the seek addresses are changing.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Lonni J Friedman 2011-11-23 03:05:56 Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time
Previous Message Bruce Momjian 2011-11-23 02:57:33 Re: synchronous replication + fsync=off?