On Mon, Apr 28, 2014 at 7:37 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> Well, often that's still good enough.
>
> That may be true for 2-4k max_connections, but >65k? That won't even
> *run*, not to speak of doing something, in most environments because of
> the number of processes required.
>
> Even making only 20k connections will probably crash your computer.
I'm of two minds on this topic. On the one hand, "cat
/proc/sys/kernel/pid_max" on a Linux system I just tested (3.2.6)
returns 65536, so we'll run out of PID space before we run out of 64k
backends. On the other hand, that value can easily be increased to a
few million via, e.g., sysctl -w kernel.pid_max=4194303, and I imagine
that as machines continue to get bigger there will be more and more
people wanting to do things like that.
I think the fact that making 20k connections might crash your computer
is an artifact of other problems that we really ought to also fix
(like per-backend memory utilization, and lock contention on various
global data structures) rather than baking it into more places. In
PostgreSQL 25.3, perhaps we'll be able to run distributed PostgreSQL
clusters that can service a million simultaneous connections across
dozens of physical machines. Then again, there might not be much left
of our current buffer manager by that point, so maybe what we decide
right now isn't that relevant.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
