On 1 April 2012 01:10, Robert Haas <robertmh...@gmail.com> wrote: > Hoping to demonstrate the wonders of our new group commit code, I ran > some benchmarks on the IBM POWER7 machine with synchronous_commit = > on. But, it didn't come out much better than 9.1. pgbench, scale > factor 300, median of 3 30-minute test runs, # clients = #threads, > shared_buffers = 8GB, maintenance_work_mem = 1GB, synchronous_commit = > on, checkpoint_segments = 300, checkpoint_timeout = 15min, > checkpoint_completion_target = 0.9, wal_writer_delay = 20ms.
Why the low value for wal_writer_delay? > master: > 01 tps = 118.968446 (including connections establishing) > 02 tps = 120.666865 (including connections establishing) > 04 tps = 209.624437 (including connections establishing) > 08 tps = 377.387029 (including connections establishing) > 16 tps = 695.172899 (including connections establishing) > 32 tps = 1318.468375 (including connections establishing) > > REL9_1_STABLE: > 01 tps = 117.037056 (including connections establishing) > 02 tps = 119.393871 (including connections establishing) > 04 tps = 205.958750 (including connections establishing) > 08 tps = 365.464735 (including connections establishing) > 16 tps = 673.379394 (including connections establishing) > 32 tps = 1101.324865 (including connections establishing) (presumably s/tps/clients/ was intended here) > Is this expected behavior? Is this not the case where it's supposed > to help? I thought Peter G. posted results showing a huge improvement > on this kind of workload, and I thought Heikki reproduced them on a > different server, so I'm confused why I can't. The exact benchmark that I ran was the update.sql pgbench-tools benchmark, on my laptop. The idea was to produce a sympathetic benchmark with a workload that was maximally commit-bound. Heikki reproduced similar numbers on his laptop, iirc. Presumably the default TPC-B-like transaction test has been used here. You didn't mention what kind of disks this server has - I'm not sure if that information is available elsewhere. That could be highly pertinent. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
