From: | Craig James <craig_james(at)emolecules(dot)com> |
---|---|
To: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Who is causing all this i/o? |
Date: | 2011-06-19 15:35:50 |
Message-ID: | 4DFE1756.9060101@emolecules.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On 6/17/11 11:51 AM, Shianmiin wrote:
> Tom Lane-2 wrote:
>> What's not apparent however is why the stats collector is writing disk
>> so much. 8.4 does have the logic change to not write stats out unless
>> something is asking to see them. So either it's really pre-8.4, or you
>> have a monitoring task that is constantly asking to see stats.
>>
> 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.
>
> The I/O write storm seemed to be trigger by Vacuum.
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.
Craig
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-06-19 17:08:30 | Re: Who is causing all this i/o? |
Previous Message | Tom Lane | 2011-06-17 23:17:56 | Re: archive_command vs. cp -i |