> Here is a v8,
I collected a few performance figures with this patch on an old box with 8
cores, 16 GB, RAID 1 HDD, under Ubuntu precise.
postgresql.conf: shared_buffers = 4GB checkpoint_timeout = 15min checkpoint_completion_target = 0.8
max_wal_size= 4GB
init> pgbench -i -s 250 warmup> pgbench -T 1200 -M prepared -S -j 2 -c 4
# 400 tps throttled "simple update" test sh> pgbench -M prepared -N -P 1 -T 4000 -R 400 -L 100 -j 2 -c 4
sort/flush : percent of skipped/late transactions on on : 2.7 on off : 16.2 off on : 68.4
off off : 68.7
# 200 tps sh> pgbench -M prepared -N -P 1 -T 4000 -R 200 -L 100 -j 2 -c 4
sort/flush : percent of skipped/late transactions on on : 2.7 on off : 9.5 off on : 47.4
off off : 48.8
The large "percent of skipped/late transactions" is to be understood as
"fraction of time with postgresql offline because of a write stall".
# full speed 1 client sh> pgbench -M prepared -N -P 1 -T 4000
sort/flush : tps avg & stddev (percent of time beyond 10.0 tps) on on : 631 +- 131 (0.1%) on off :
564+- 303 (12.0%) off on : 167 +- 315 (76.8%) # stuck... off off : 177 +- 305 (71.2%) # ~ current pg
# full speed 2 threads 4 clients sh> pgbench -M prepared -N -P 1 -T 4000 -j 2 -c 4
sort/flush : tps avg & stddev (percent of time below 10.0 tps) on on : 1058 +- 455 (0.1%) on off :
1056+- 942 (32.8%) off on : 170 +- 500 (88.3%) # stuck... off off : 209 +- 506 (82.0%) # ~ current pg
The combined features provide a tps speedup of 3-5 on these runs, and
allow to have some control on write stalls. Flushing is not effective on
unsorted buffers, at least on these example.
--
Fabien.
