On 3/15/15 7:17 PM, michael@sqlexec.com wrote:
Please avoid top-posting.
> I agree with your counter argument about how high max_connections "can"
> cause problems, but max_connections may not part of the problem here.
> There's a bunch of "depends stuff" in there based on workload details, #
> cpus, RAM, etc.
Sure, but the big, huge danger with a very large max_connections is that
you now have a large grenade with the pin pulled out. If *anything*
happens to disturb the server and push the active connection count past
the number of actual cores the box is going to fall over and not recover.
In contrast, if max_connections is <= the number of cores this is far
less likely to happen. Each connection will get a CPU to run on, and as
long as they're not all clamoring for the same locks the server will be
making forward progress. Clients may have to wait in the pool for a free
connection for some time, but once they get one their work will get done.
> I'm still waiting to find out how many CPUs on this DB server. Did i
> miss it somewhere in the email thread below?
http://blog.musicbrainz.org/2015/03/15/postgres-troubles/ might show it
somewhere...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
