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