On 16/03/15 13:07, Tomas Vondra wrote:
On 16.3.2015 00:55, michael@xxxxxxxxxxx wrote:
Why is 500 connections "insane". We got 32 CPU with 96GB and 3000
max connections, and we are doing fine, even when hitting our max
concurrent connection peaks around 4500. At a previous site, we were
using 2000 max connections on 24 CPU and 64GB RAM, with about 1500
max concurrent connections. So I wouldn't be too hasty in saying more
than 500 is asking for trouble. Just as long as you got your kernel
resources set high enough to sustain it (SHMMAX, SHMALL, SEMMNI, and
ulimits), and RAM for work_mem.
[...]
Also, if part of the query required a certain amount of memory for part
of the plan, it now holds that memory for much longer too. That only
increases the change of OOM issues.
[...]
Also you could get a situation where a small number of queries & their
data, relevant indexes, and working memory etc can all just fit into
RAM, but the extra queries suddenly reduce the RAM so that even these
queries spill to disk, plus the time required to process the extra
queries. So a nicely behaved system could suddenly get a lot worse.
Even before you consider additional lock contention and other nasty things!
It all depends...
Cheers,
Gavin
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
