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.


	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