Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time - Mailing list pgsql-general

From Tom Lane
Subject Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time
Date
Msg-id 11335.1322017061@sss.pgh.pa.us
Whole thread Raw
In response to autovacuum stuck on a table for 18+ hours, consuming lots of CPU time  (Lonni J Friedman <netllama@gmail.com>)
Responses Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time  (Lonni J Friedman <netllama@gmail.com>)
List pgsql-general
Lonni J Friedman <netllama@gmail.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

pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: synchronous replication + fsync=off?
Next
From: Lonni J Friedman
Date:
Subject: Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time