On 2016-06-01 15:33:18 -0700, Andres Freund wrote: > Cpu: i7-6820HQ > Ram: 24GB of memory > Storage: Samsung SSD 850 PRO 1TB, encrypted > postgres -c shared_buffers=6GB -c backend_flush_after=128 -c > max_wal_size=100GB -c fsync=on -c synchronous_commit=off > pgbench -M prepared -c 16 -j 16 -T 520 -P 1 -n -N
Using scale 5000 database, with wal compression enabled (otherwise the whole thing is too slow in both cases), and 64 clients gives: disabled: latency average = 11.896 ms latency stddev = 42.187 ms tps = 5378.025369 (including connections establishing) tps = 5378.248569 (excluding connections establishing) 128: latency average = 11.002 ms latency stddev = 10.621 ms tps = 5814.586813 (including connections establishing) tps = 5814.840249 (excluding connections establishing) With flushing disabled, rougly every 30s you see: progress: 150.0 s, 6223.3 tps, lat 10.036 ms stddev 9.521 progress: 151.0 s, 0.0 tps, lat -nan ms stddev -nan progress: 152.0 s, 0.0 tps, lat -nan ms stddev -nan progress: 153.0 s, 4952.9 tps, lat 39.050 ms stddev 249.839 progress: 172.0 s, 4888.0 tps, lat 12.851 ms stddev 11.507 progress: 173.0 s, 0.0 tps, lat -nan ms stddev -nan progress: 174.0 s, 0.0 tps, lat -nan ms stddev -nan progress: 175.0 s, 4636.8 tps, lat 41.421 ms stddev 268.416 progress: 196.0 s, 1119.2 tps, lat 9.618 ms stddev 8.321 progress: 197.0 s, 0.0 tps, lat -nan ms stddev -nan progress: 198.0 s, 1920.9 tps, lat 94.375 ms stddev 429.756 progress: 199.0 s, 5260.8 tps, lat 12.087 ms stddev 11.595 With backend flushing enabled there's not a single such pause. If you use spinning rust instead of SSDs, the pauses aren't 1-2s anymore, but easily 10-30s. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
