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 workers and 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@xxxxxxxx>: > 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
