On Sun, Nov 21, 2010 at 9:18 PM, Ivan Voras <ivoras@freebsd.org> 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@postgresql.org)
> 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