Re: Decrease MAX_BACKENDS to 2^16

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Fetter <david(at)fetter(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Decrease MAX_BACKENDS to 2^16
Date: 2014-04-28 12:29:32
Message-ID: CA+Tgmoa6PtSBGQSm6hfG-MOTBBCm4GqizyOJTAPPKu6BBurvkg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 28, 2014 at 7:37 AM, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message amul sul 2014-04-28 12:49:08 Different behaviour of concate() and concate operator ||
Previous Message Christoph Berg 2014-04-28 12:29:06 Re: includedir_internal headers are not self-contained