Re: 8.3 synchronous_commit
От
Greg Smith
Тема
Re: 8.3 synchronous_commit
Дата
Msg-id
Pine.GSO.4.64.0801211912340.10359@westnet.com
Ответ на
Re: 8.3 synchronous_commit (Jeff Davis)
Список
Дерево обсуждения
8.3 synchronous_commit Hannes Dorbath <light@theendofthetunnel.de>
Re: 8.3 synchronous_commit Jeff Davis <pgsql@j-davis.com>
Re: 8.3 synchronous_commit "Pavel Stehule" <pavel.stehule@gmail.com>
Re: 8.3 synchronous_commit Florian Weimer <fweimer@bfk.de>
Re: 8.3 synchronous_commit "Guillaume Smet" <guillaume.smet@gmail.com>
Re: 8.3 synchronous_commit Hannes Dorbath <light@theendofthetunnel.de>
Re: 8.3 synchronous_commit Florian Weimer <fweimer@bfk.de>
Re: 8.3 synchronous_commit Greg Smith <gsmith@gregsmith.com>
Re: 8.3 synchronous_commit Jeff Davis <pgsql@j-davis.com>
Re: 8.3 synchronous_commit Fernando Ike <fike@midstorm.org>
Re: 8.3 synchronous_commit Greg Smith <gsmith@gregsmith.com>
Re: 8.3 synchronous_commit Hannes Dorbath <light@theendofthetunnel.de>
On Mon, 21 Jan 2008, Jeff Davis wrote: > He was referring to the CFQ I/O scheduler. I don't think that will > affect pgbench itself, because it doesn't read/write to disk, right? It does if you are writing latency log files but it shouldn't be in the cases given. But there's something weird about the interplay between the server disk I/O under CFQ and the time slices the pgbench client gets when they're all on the same system. pgbench is certainly a badly scaling (in regards to how it handles simulating many clients) single process utility and anything that starves its execution sometimes is deadly. I never dug deep into the exact scheduler issues, but regardless in this case it's kind of unrealistic for Hannes to expect to simulate 100 clients on a small system and still get a true view of how the server on that system performs. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-performance по дате отправления