On 3/18/09 4:36 AM, "Gregory Stark" <st...@enterprisedb.com> wrote:
> > > "Jignesh K. Shah" <j.k.s...@sun.com> writes: > >> In next couple of weeks I plan to test the patch on a different x64 based >> system to do a sanity testing on lower number of cores and also try out other >> workloads ... > > I'm actually more interested in the large number of cores but fewer processes > and lower max_connections. If you set max_connections to 64 and eliminate the > wait time you should, in theory, be able to get 100% cpu usage. It would be > very interesting to track down the contention which is preventing that. My previous calculation in this thread showed that even at 0 wait time, the client seems to introduce ~3ms wait time overhead on average. So it takes close to 128 threads in each test to stop the linear scaling since the average processing time seems to be about ~3ms. Either that, or the tests actually are running on a system capable of 128 threads. > > -- > Gregory Stark > EnterpriseDB http://www.enterprisedb.com > Ask me about EnterpriseDB's PostGIS support! > > - > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > - Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
