Re: new group commit behavior not helping? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: new group commit behavior not helping?
Date
Msg-id CA+Tgmob-uimAaMymscJynam9ZA36hfHYiMJ4wVevOFk6VxW9Bg@mail.gmail.com
Whole thread Raw
In response to new group commit behavior not helping?  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On Sun, Apr 1, 2012 at 1:40 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Saturday, March 31, 2012, Robert Haas <robertmhaas@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.
>
> Where I would expect (and have seen) much improvement is where #clients >>
> #CPU.  Or "cores", whatever the term of art is.

It seems you are right; see the email I just sent.

> Of course I've mostly seen this where CPU=1
>
> It looks like in your case tps was still scaling with clients when you gave
> up, so clients was probably too small.

What is kind of weird is that it actually seems to scale at almost
exactly half of linear.  Clients/tps on 9.2, with the pgbench-tools
test Peter recommended:

1 140
2 143
4 289
8 585
16 1157
32 2317
50 3377
150 9511
250 12721
350 12582
450 11370
700 6972

You'll notice that at 2 clients we get basically no improvement.  But
4 gets twice the single-client throughput; 8 gets about four times the
single-client throughput; 16 gets about eight times the single-client
throughput; 32 gets about sixteen times the single-client throughput;
and 50 gets nearly 25 times the single-client throughput.

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: new group commit behavior not helping?
Next
From: Jeff Janes
Date:
Subject: Re: new group commit behavior not helping?