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
