Re: new group commit behavior not helping?
От | Robert Haas |
---|---|
Тема | Re: new group commit behavior not helping? |
Дата | |
Msg-id | CA+Tgmob-uimAaMymscJynam9ZA36hfHYiMJ4wVevOFk6VxW9Bg@mail.gmail.com обсуждение исходный текст |
Ответ на | new group commit behavior not helping? (Jeff Janes <jeff.janes@gmail.com>) |
Список | 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 по дате отправления: