On 26 November 2010 03:00, Greg Smith <greg@xxxxxxxxxxxxxxx> 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. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
