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

Reply via email to