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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
