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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
