Re: Postgres benchmarking with pgbench
От
Scott Carey
Тема
Re: Postgres benchmarking with pgbench
Дата
Msg-id
C5E80E3E.3886%scott@richrelevance.com
Ответ на
Re: Postgres benchmarking with pgbench (ml@bortal.de)
Список
Дерево обсуждения
Postgres benchmarking with pgbench "ml@bortal.de" <ml@bortal.de>
Re: Postgres benchmarking with pgbench Greg Smith <gsmith@gregsmith.com>
Re: Postgres benchmarking with pgbench "ml@bortal.de" <ml@bortal.de>
Re: Postgres benchmarking with pgbench "Jignesh K. Shah" <J.K.Shah@Sun.COM>
Re: Postgres benchmarking with pgbench Scott Carey <scott@richrelevance.com>
Re: Postgres benchmarking with pgbench Scott Marlowe <scott.marlowe@gmail.com>
Re: Postgres benchmarking with pgbench Gregory Stark <stark@enterprisedb.com>
Re: Postgres benchmarking with pgbench Greg Smith <gsmith@gregsmith.com>
Re: Postgres benchmarking with pgbench Gregory Stark <stark@enterprisedb.com>
Re: Postgres benchmarking with pgbench Greg Smith <gsmith@gregsmith.com>
Re: Postgres benchmarking with pgbench Scott Marlowe <scott.marlowe@gmail.com>
On 3/19/09 2:25 PM, "ml@bortal.de" wrote: > > Here is my config (maybe with some odd setting): > http://pastebin.com/m5d7f5717 > > I played around with: > - max_connections > - shared_buffers > - work_mem > - maintenance_work_mem > - checkpoint_segments > - effective_cache_size > > ..but whatever i do, the graph looks the same. Any hints or tips what my > config should look like? Or are these results even okay? Maybe i am > driving myself crazy for nothing? > > Cheers, > Mario > I'm assuming this is linux: What linux version? What is your kernel's dirty_ratio and background_dirty_ratio? The default for a long time was 40 and 10, respectively. This is far too large for most uses on today's servers, you would not want 40% of your RAM to have pages not yet flushed to disk except perhaps on a small workstation. See Current kernels default to 10 and 5, which is better. What is best for your real life workload will differ from pg_bench here. I don't know if this is the cause for any of your problems, but it is related closely to the checkpoint_segments and checkpoint size/time configuration. Is your xlog on the same device as the data? I have found that for most real world workloads, having the xlog on a separate device helps tremendously. Even more so for 'poor' RAID controllers like the PERC5 -- your sync writes in xlog will be interfering with the RAID controller cache of your data due to bad design. But my pg_bench knowledge with respect to this is limited.
В списке pgsql-performance по дате отправления