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 20:12:48.806885-04 think=# select * from pg_class where relname = 'value'; -[ RECORD 1 ]--+--------------------------------- relname | value relfilenode | 191425 relpages | 1643518 reltuples | 1.37203e+08 # find -name 191425\* ./16579/191425 ./16579/191425.1 ./16579/191425.10 ./16579/191425.11 ./16579/191425.12 ./16579/191425.13 ./16579/191425.14 ./16579/191425.15 ./16579/191425.16 ./16579/191425.17 ./16579/191425.18 ./16579/191425.19 ./16579/191425.2 ./16579/191425.3 ./16579/191425.4 ./16579/191425.5 ./16579/191425.6 ./16579/191425.7 ./16579/191425.8 ./16579/191425.9 # vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 1 30336 46264 60 7882356 0 0 250 299 1 1 6 2 87 5 0 1 30336 47412 60 7881308 0 0 2896 48 944 4861 3 2 71 24 0 2 30336 46696 60 7882188 0 0 816 4 840 5019 1 0 75 24 0 1 30336 49228 60 7879868 0 0 1888 164 971 5687 1 1 74 24 0 1 30336 49688 60 7878916 0 0 2640 48 1047 5751 1 0 75 23 autovacuum | on autovacuum_vacuum_cost_delay | -1 autovacuum_vacuum_cost_limit | -1 vacuum_cost_delay | 0 vacuum_cost_limit | 200 vacuum_cost_page_dirty | 20 vacuum_cost_page_hit | 1 vacuum_cost_page_miss | 10 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance