new group commit behavior not helping?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: new group commit behavior not helping?
Date: 2012-04-01 00:10:05
Message-ID: CA+TgmoY8P3sD=oUViG+xZjmZk5-phuNV39rtfyzUQxU8hJtZxw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. By
number of clients:

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)

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2012-04-01 00:31:02 Re: new group commit behavior not helping?
Previous Message Greg Stark 2012-03-31 22:01:52 Re: measuring lwlock-related latency spikes