I'd also like to see concurrent workloads with synchronous_commit=off -
I've seen absolutely horrible latency behaviour for that, and I'm hoping
this will help. It's also a good way to simulate faster hardware than
you have.
It helps. I've done a few runs, where the very-very-bad situation is
improved to... I would say very-bad:
medium3: scale=200 shared_buffers=4GB checkpoint_timeout=15min
max_wal_size=4GB warmup=1200 time=6000 clients=4
synchronous_commit=off
flush sort | tps | percent of seconds offline
off off | 296 | 83% offline
off on | 1496 | 33% offline
off on | 1641 | 59% offline
on on | 1515 | 31% offline
The offline figure is the percentage of seconds in the 6000 seconds run
where 0.0 tps are reported, or where nothing is reported because pgbench
is stuck.
It is somehow better... on an abysmal scale: sorting and flushing reduced
the offline time by a factor of 2.6. Too bad it is so high to begin with.
The tps is improved by a factor of 5 with either options.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
