On Sun, Nov 21, 2010 at 9:18 PM, Ivan Voras <ivoras@xxxxxxxxxxx> wrote: > On 11/22/10 02:47, Kevin Grittner wrote: >> >> Ivan Voras wrote: >> >>> After 16 clients (which is still good since there are only 12 >>> "real" cores in the system), the performance drops sharply >> >> Yet another data point to confirm the importance of connection >> pooling. :-) > > I agree, connection pooling will get rid of the symptom. But not the > underlying problem. I'm not saying that having 1000s of connections to the > database is a particularly good design, only that there shouldn't be a sharp > decline in performance when it does happen. Ideally, the performance should > remain the same as it was at its peek. > > I've been monitoring the server some more and it looks like there are > periods where almost all servers are in the semwait state followed by > periods of intensive work - approximately similar to the "thundering herd" > problem, or maybe to what Josh Berkus has posted a few days ago. > > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > Try it with systemtap or dtrace and see if you find the same bottlenecks as I do in http://jkshah.blogspot.com/2010/11/postgresql-90-simple-select-scaling.html I will probably retry it with pgBench and see what I find .. Regards, Jignesh -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
