Skip site navigation (1) Skip section navigation (2)

Re: Performance under contention

From: Jignesh Shah <jkshah(at)gmail(dot)com>
To: Ivan Voras <ivoras(at)freebsd(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance under contention
Date: 2010-11-22 06:54:50
Message-ID: AANLkTinzSxBeV6DSg-5JgXd_t4RKyZ_mxw+_-_0BNreg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
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:
> 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

In response to

Responses

pgsql-performance by date

Next:From: Martin BoeseDate: 2010-11-22 08:59:30
Subject: Slow SELECT on small table
Previous:From: Humair MohammedDate: 2010-11-22 06:21:40
Subject: Re: Query Performance SQL Server vs. Postgresql

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group