Craig James <craig_james@xxxxxxxxxxxxxx> writes: > On 6/17/11 11:51 AM, Shianmiin wrote: >> We have a PostgreSQL 9.0.4 on CentOs for performance testing and we are >> seeing the similar issue. >> we have a "crazy" setup it has 1 database with 1000 identical schemas. There >> are occasional I/O write storm >> of over 100 MB/sec without any disk reads, and it could last for a couple of >> minutes when the schemas/data are aggressively populated by pg_restore. All >> the io writes seem to be on pgstat.tmp. > Based on the advice I got from my original question, I changed autovacuum_naptime to "5min", and the problem completely disappeared. (I know that's a long interval, but this particular server gets maybe 5-10 heavy updates per week and is idle the rest of the time.) > select count(1) from pg_database ; > count > ------- > 267 > It seems like there's a problem somewhere. Autovacuum has improved enormously in the last couple of years, but some change to its algorithm causes a lot of I/O thrashing when there are more than a few hundred separate databases. Well, if you have a lot of databases then you definitely need to increase the naptime to keep autovac's demands for stats within bounds. I don't find that surprising, though I do wonder if we ought to redefine the way that GUC works: right now, you get one autovac wakeup every naptime/databases seconds. The OP seems to have some other issue, though, since he says he's only got 1 database. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
