Re: Group commit, revised

On 2012-01-29 01:48, Jeff Janes wrote:

I ran three modes, head, head with commit_delay, and the group_commit patch

shared_buffers = 600MB
wal_sync_method=fsync

optionally with:
commit_delay=5
commit_siblings=1

pgbench -i -s40

for clients in 1 5 10 15 20 25 30
pgbench -T 30 -M prepared -c $clients -j $clients

ran 5 times each, taking maximum tps from the repeat runs.

The results are impressive.

clients	head	head_commit_delay	group_commit
1	23.9	23.0	23.9
5	31.0	51.3	59.9
10	35.0	56.5	95.7
15	35.6	64.9	136.4
20	34.3	68.7	159.3
25	36.5	64.1	168.8
30	37.2	83.8	71.5

I haven't inspected that deep fall off at 30 clients for the patch.

By way of reference, if I turn off synchronous commit, I get
tps=1245.8 which is 100% CPU limited.  This sets an theoretical upper
bound on what could be achieved by the best possible group committing
method.

If the group_commit patch goes in, would we then rip out commit_delay
and commit_siblings?

Adding to the list of tests that isn't excactly a real-world system I decided
to repeat Jeff's tests on a Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
with 4GB of memory and an Intel X25-M 160GB SSD drive underneath.

body, div, table, thead, tbody, tfoot, tr, th, td, p { font-family: "Arial"; font-size: x-small; }

	Baseline	Commitdelay	Group commit
1	1168.67	1233.33	1212.67
5	2611.33	3022.00	2647.67
10	3044.67	3333.33	3296.33
15	3153.33	3177.00	3456.67
20	3087.33	3126.33	3618.67
25	2715.00	2359.00	3309.33
30	2736.33	2831.67	2737.67

Numbers are average over 3 runs.

I have set checkpoint_segments to 30 .. otherwise same configuration as Jeff.
Attached is a graph.

Nice conclusion is.. group commit outperforms baseline in all runs (on this system).

My purpose was actual more to try to quantify the difference between a single SSD and
a single rotating disk.

--
Jesper