On 26 November 2010 03:00, Greg Smith <greg@2ndquadrant.com> wrote:
> Two suggestions to improve your results here:
>
> 1) Don't set shared_buffers to 10GB. There are some known issues with large
> settings for that which may or may not be impacting your results. Try 4GB
> instead, just to make sure you're not even on the edge of that area.
>
> 2) pgbench itself is known to become a bottleneck when running with lots of
> clients. You should be using the "-j" option to spawn multiple workers,
> probably 12 of them (one per core), to make some of this go away. On the
> system I saw the most improvement here, I got a 15-25% gain having more
> workers at the higher client counts.
> It will be interesting to see if that's different after the changes
> suggested above.
Too late, can't test on the hardware anymore. I did use -j on pgbench,
but after 2 threads there were not significant improvements - the two
threads did not saturate two CPU cores.
However, I did run a similar select-only test on tmpfs on different
hardware with much less memory (4 GB total), with shared_buffers
somewhere around 2 GB, with the same performance curve:
http://ivoras.sharanet.org/blog/tree/2010-07-21.postgresql-on-tmpfs.html
so I doubt the curve would change by reducing shared_buffers below
what I used in the original post.
