On Wed, Oct 10, 2012 at 11:44 AM, Claudio Freire <klaussfreire@xxxxxxxxx> wrote: > On Wed, Oct 10, 2012 at 9:52 AM, Shaun Thomas <sthomas@xxxxxxxxxxxxxxxx> wrote: >> On 10/09/2012 06:30 PM, Craig James wrote: >> >>> ra:8192 walb:1M ra:256 walb:1M ra:256 walb:256kB >>> ---------------- ---------------- ----------------- >>> -c -t Run1 Run2 Run3 Run4 Run5 Run6 Run7 Run8 Run9 >>> 40 2500 4261 3722 4243 9286 9240 5712 9310 8530 8872 >>> 50 2000 4138 4399 3865 9213 9351 9578 8011 7651 8362 >> ... > But really interesting numbers in any case. It these results are on > the level, then maybe the kernel's read-ahead algorithm isn't as > fool-proof as we thought? Gotta read the source. BRB So, I've been digging. Newer kernels (above 2.6.23) have a new read-ahead algorithm, called the "on-demand" read ahead. Benchmarks on this new code[0] suggest there is a penalty for random writes that wasn't there before. This penalty is small in the benchmarks (less than 10% in all cases), but I would imagine the issue would be amplified in the case of a kernel with a misconfigured bg_writer (this case, IIRC). This makes sense, in fact. Back when I tested the 8MB read-ahead on my server, it was using 2.6.18. Now, 2.6.23 is in fact rather old, so those benchmarks may no longer be relevant. There are tons of commits since then[1], though only one pertaining writes from what I can tell. However, I'm inclined to blame the bg_writer. How about tweaking the dirty_background_ratio and dirty_ratio and re-trying? [0] http://lwn.net/Articles/235181/ [1] https://github.com/torvalds/linux/commits/f5a246eab9a268f51ba8189ea5b098a1bfff200e/mm/readahead.c?page=1 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
