From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bgwriter strategies |
Date: | 2007-07-06 20:10:32 |
Message-ID: | 468EA1B8.9040607@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas wrote:
> I scheduled a test with the moving average method as well, we'll see how
> that fares.
No too well :(.
Strange. The total # of writes is on par with having bgwriter disabled,
but the physical I/O graphs show more I/O (on par with the aggressive
bgwriter), and the response times are higher.
I just noticed that on the tests with the moving average, or the simple
"just enough" method, there's a small bump in the CPU usage during the
ramp up period. I believe that's because bgwriter scans through the
whole buffer cache without finding enough buffers to clean. I ran some
tests earlier with unpatched bgwriter tuned to the maximum, and it used
~10% of CPU, which is the same level that the bump rises to.
Unfortunately I haven't been taking pg_buffercache snapshots until after
the ramp up; it should've shown up there.
I've been running these test with bgwriter_delay of 10 ms, which is
probably too aggressive. I used that to test the idea of starting the
scan from where it left off, instead of always starting from clock hand.
If someone wants to have a look, the # of writes are collected to a
separate log file in <test number>/server/buf_alloc_stats.log. There's
no link to it from the html files. There's also summary snapshots of
pg_buffercache every 30 seconds in <test number>/server/bufcache.log.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew T. O'Connor | 2007-07-06 20:11:39 | Re: Still recommending daily vacuum... |
Previous Message | Guan Wang | 2007-07-06 19:43:10 | CurrentMemoryContext is NULL |