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