Re: Performance under contention

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux