Re: Perf Benchmarking and regression.
От | Andres Freund |
---|---|
Тема | Re: Perf Benchmarking and regression. |
Дата | |
Msg-id | 20160513174309.nohwwqzlb526wora@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Perf Benchmarking and regression. (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Perf Benchmarking and regression.
Re: Perf Benchmarking and regression. |
Список | pgsql-hackers |
On 2016-05-13 10:20:04 -0400, Robert Haas wrote: > On Fri, May 13, 2016 at 7:08 AM, Ashutosh Sharma <ashu.coek88@gmail.com> wrote: > > Following are the performance results for read write test observed with > > different numbers of "backend_flush_after". > > > > 1) backend_flush_after = 256kb (32*8kb), tps = 10841.178815 > > 2) backend_flush_after = 512kb (64*8kb), tps = 11098.702707 > > 3) backend_flush_after = 1MB (128*8kb), tps = 11434.964545 > > 4) backend_flush_after = 2MB (256*8kb), tps = 13477.089417 > > So even at 2MB we don't come close to recovering all of the lost > performance. Can you please test these three scenarios? > > 1. Default settings for *_flush_after > 2. backend_flush_after=0, rest defaults > 3. backend_flush_after=0, bgwriter_flush_after=0, > wal_writer_flush_after=0, checkpoint_flush_after=0 4) 1) + a shared_buffers setting appropriate to the workload. I just want to emphasize what we're discussing here is a bit of an extreme setup. A workload that's bigger than shared buffers, but smaller than the OS's cache size; with a noticeable likelihood of rewriting individual OS page cache pages within 30s. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: