This autovacuum has been hammering my server with purely random i/o
for half a week. The table is only 20GB and the i/o subsystem is good
for 250MB/s sequential and a solid 5kiops. When should I expect it to
end (if ever)?
current_query: VACUUM reuters.value
query_start: 2008-04-15
Jeffrey Baker [EMAIL PROTECTED] writes:
This autovacuum has been hammering my server with purely random i/o
for half a week. The table is only 20GB and the i/o subsystem is good
for 250MB/s sequential and a solid 5kiops. When should I expect it to
end (if ever)?
What have you got
On Fri, Apr 18, 2008 at 10:03 AM, Tom Lane [EMAIL PROTECTED] wrote:
Jeffrey Baker [EMAIL PROTECTED] writes:
This autovacuum has been hammering my server with purely random i/o
for half a week. The table is only 20GB and the i/o subsystem is good
for 250MB/s sequential and a solid
On Fri, Apr 18, 2008 at 10:32 AM, Jeffrey Baker [EMAIL PROTECTED] wrote:
On Fri, Apr 18, 2008 at 10:03 AM, Tom Lane [EMAIL PROTECTED] wrote:
Jeffrey Baker [EMAIL PROTECTED] writes:
This autovacuum has been hammering my server with purely random i/o
for half a week. The table is
On Fri, Apr 18, 2008 at 10:34 AM, Jeffrey Baker [EMAIL PROTECTED] wrote:
On Fri, Apr 18, 2008 at 10:32 AM, Jeffrey Baker [EMAIL PROTECTED] wrote:
On Fri, Apr 18, 2008 at 10:03 AM, Tom Lane [EMAIL PROTECTED] wrote:
Jeffrey Baker [EMAIL PROTECTED] writes:
This autovacuum has been
Jeffrey Baker escribió:
That's rather more like it. I guess I always imagined that VACUUM was
a sort of linear process, not random, and that it should proceed at
sequential scan speeds.
It's linear for the table, but there are passes for indexes which are
random in 8.1. That code was
Jeffrey Baker [EMAIL PROTECTED] writes:
I increased it to 1GB, restarted the vacuum, and system performance
seems the same. The root of the problem, that an entire CPU is in the
iowait state and the storage device is doing random i/o, is unchanged:
Yeah, but you just reduced the number of
Jeffrey Baker wrote:
On Fri, Apr 18, 2008 at 10:32 AM, Jeffrey Baker [EMAIL PROTECTED] wrote:
# show maintenance_work_mem ;
maintenance_work_mem
--
16384
That appears to be the default. I will try increasing this. Can I
increase it globally from a single backend,
