Okay, So to understand this better before I go with that solution:
In theory what difference should it make to the performance, to have a pool in front of the database, that all my
workersand web servers connect to instead of connecting directly? Where is the performance gain coming from in that
situation?
Den 30/11/2012 kl. 13.03 skrev "Kevin Grittner" <kgrittn@mail.com>:
> Niels Kristian Schjødt wrote:
>
>>> You said before that you were seeing high disk wait numbers. Now
>>> it is zero accourding to your disk utilization graph. That
>>> sounds like a change to me.
>
>> Hehe, I'm sorry if it somehow was misleading, I just wrote "a lot
>> of I/O" it was CPU I/O
>
>>>> A lot of both read and writes takes more than a 1000 times as
>>>> long as they usually do, under "lighter" overall load.
>>>
>>> As an odd coincidence, you showed your max_connections setting
>>> to be 1000.
>>>
>>> http://wiki.postgresql.org/wiki/Number_Of_Database_Connections
>
>> Back to the issue: Could it be that it is the fact that I'm using
>> ubuntus built in software raid to raid my disks, and that it is
>> not at all capable of handling the throughput?
>
> For high performance situations I would always use a high quality
> RAID controller with battery-backed RAM configured for write-back;
> however:
>
> The graphs you included suggest that your problem has nothing to do
> with your storage system. Now maybe you didn't capture the data for
> the graphs while the problem was occurring, in which case the
> graphs would be absolutely useless; but based on what slim data you
> have provided, you need a connection pool (like maybe pgbouncer
> configured in transaction mode) to limit the number of database
> connections used to something like twice the number of cores.
>
> If you still have problems, pick the query which is using the most
> time on your database server, and post it with the information
> suggested on this page:
>
> http://wiki.postgresql.org/wiki/SlowQueryQuestions
>
> -Kevin