2009/5/28 Scott Mead <scott.li...@enterprisedb.com> > On Thu, May 28, 2009 at 4:53 PM, Fabrix <fabrix...@gmail.com> wrote: > >> >> >>> >>> Wow, that's some serious context-switching right there - 300k context >>> switches a second mean that the processors are spending a lot of their >>> time fighting for CPU time instead of doing any real work. >> >> > There is a bug in the quad core chips during a massive amount of > connections that will cause all cores to go to 100% utilization and no work > be done. I'm digging to find links, but if I remember correctly, the only > way to fix it was to disable the 4th core in linux (involved some black > magic in /proc). You really need to lower the number of processes you're > forcing each processor bus to switch through (or switch to AMD's > hyper-transport bus). >
The server HP is already AMD proccesor. The server with 4 dual core had max_connections = 5000 too, but the maximum of connections at time were 1800 and work very well. If you get the link on the bug's quad core I would greatly appreciate > > >> >>> >>> It appears that you have the server configured with a very high number >>> of connections as well? My first suggestion would be to look at a way >>> to limit the number of active connections to the server at a time >>> (pgPool or similar). >> >> >> yes, i have max_connections = 5000 >> can lower, but at least i need 3500 connections >> > > Typically, it's a bad idea to run run with anything over 1000 connections > (many will suggest lower than that). If you need that many connections, > you'll want to look at a connection pool like pgBouncer or pgPool. > Postgres does not support more than 1000? even the server is very robust? I will try to lower... and already i have a pool (not pgpool and not pgBouncer). I have distributed all connections in three servers :). > > --Scott > > >
