On Sun, Nov 21, 2010 at 9:18 PM, Ivan Voras <ivoras(at)freebsd(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
Try it with systemtap or dtrace and see if you find the same
bottlenecks as I do in
I will probably retry it with pgBench and see what I find ..
In response to
pgsql-performance by date
|Next:||From: Martin Boese||Date: 2010-11-22 08:59:30|
|Subject: Slow SELECT on small table|
|Previous:||From: Humair Mohammed||Date: 2010-11-22 06:21:40|
|Subject: Re: Query Performance SQL Server vs. Postgresql|