Re: new group commit behavior not helping?
От | Peter Geoghegan |
---|---|
Тема | Re: new group commit behavior not helping? |
Дата | |
Msg-id | CAEYLb_XahYyP+enAyfvMy86zxLF6v0=wx0qt9_3b8Tfs9eK6DQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: new group commit behavior not helping? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: new group commit behavior not helping?
|
Список | pgsql-hackers |
On 1 April 2012 06:41, Robert Haas <robertmhaas@gmail.com> wrote: > There seem to be too relevant differences between your test and mine: > (1) your test is just a single insert per transaction, whereas mine is > pgbench's usual update, select, update, update, insert and (2) it > seems that, to really see the benefit of this patch, you need to pound > the server with a very large number of clients. On this test, 250 > clients was the sweet spot. *refers to original early January benchmark* While the graph that I produced was about the same shape as yours, the underlying hardware was quite different, and indeed with my benchmark group commit's benefits are more apparent earlier - at 32 clients, throughput has more-than doubled compared to pre group commit Postgres, which has already just about plateaued. I did include hdparm information for the disk that my benchmark was performed on at the time. While write-caching was not disabled, I would expect that the commit speed of my laptop - which has a fairly unremarkable 7200RPM disk - is slower than the 10K RPM SAS disks that you used. A formal benchmark of respective raw commit speeds may shed more light on this. Why did I even bother with such a sympathetic benchmark, when a benchmark on a large server could have been performed instead? Well, the reality is that many of our users have a commit speed that is comparable to my laptop. In particular, the increasing prevalence of "cloud" type deployments, make group commit a timely feature. If you wanted to demonstrate the wonders of group commit, I'd take that particular tone. I'm sure that if you re-ran this benchmark with a battery-backed cache, you would observe a much smaller though still very apparent benefit, but if you wanted to make the feature sound appealing to traditional enterprise users that are using a BBU, a good line would be "this is what will save your bacon that day that your procedures fail and your BBU battery dies". -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: