Re: Decrease MAX_BACKENDS to 2^16
От
Robert Haas
Тема
Re: Decrease MAX_BACKENDS to 2^16
Дата
Msg-id
CA+Tgmoa6PtSBGQSm6hfG-MOTBBCm4GqizyOJTAPPKu6BBurvkg@mail.gmail.com
Ответ на
Re: Decrease MAX_BACKENDS to 2^16 (Andres Freund)
Список
Дерево обсуждения
Decrease MAX_BACKENDS to 2^16 Andres Freund <andres@2ndquadrant.com>
Re: Decrease MAX_BACKENDS to 2^16 David Fetter <david@fetter.org>
Re: Decrease MAX_BACKENDS to 2^16 Andres Freund <andres@2ndquadrant.com>
Re: Decrease MAX_BACKENDS to 2^16 Tom Lane <tgl@sss.pgh.pa.us>
Re: Decrease MAX_BACKENDS to 2^16 Andres Freund <andres@2ndquadrant.com>
Re: Decrease MAX_BACKENDS to 2^16 Jim Nasby <jim@nasby.net>
Re: Decrease MAX_BACKENDS to 2^16 Heikki Linnakangas <hlinnakangas@vmware.com>
Re: Decrease MAX_BACKENDS to 2^16 Andres Freund <andres@2ndquadrant.com>
Re: Decrease MAX_BACKENDS to 2^16 Heikki Linnakangas <hlinnakangas@vmware.com>
Re: Decrease MAX_BACKENDS to 2^16 Andres Freund <andres@2ndquadrant.com>
Re: Decrease MAX_BACKENDS to 2^16 Robert Haas <robertmhaas@gmail.com>
Re: Decrease MAX_BACKENDS to 2^16 Tom Lane <tgl@sss.pgh.pa.us>
Re: Decrease MAX_BACKENDS to 2^16 Andres Freund <andres@2ndquadrant.com>
Re: Decrease MAX_BACKENDS to 2^16 Tom Lane <tgl@sss.pgh.pa.us>
Re: Decrease MAX_BACKENDS to 2^16 Andres Freund <andres@2ndquadrant.com>
Re: Decrease MAX_BACKENDS to 2^16 Greg Stark <stark@mit.edu>
Re: Decrease MAX_BACKENDS to 2^16 Andres Freund <andres@2ndquadrant.com>
Re: Decrease MAX_BACKENDS to 2^16 Tom Lane <tgl@sss.pgh.pa.us>
Re: Decrease MAX_BACKENDS to 2^16 David Fetter <david@fetter.org>
Re: Decrease MAX_BACKENDS to 2^16 Andres Freund <andres@2ndquadrant.com>
Re: Decrease MAX_BACKENDS to 2^16 Noah Misch <noah@leadboat.com>
Re: Decrease MAX_BACKENDS to 2^16 Tom Lane <tgl@sss.pgh.pa.us>
Re: Decrease MAX_BACKENDS to 2^16 Peter Geoghegan <pg@heroku.com>
Re: Decrease MAX_BACKENDS to 2^16 Peter Geoghegan <pg@heroku.com>
On Mon, Apr 28, 2014 at 7:37 AM, Andres Freund 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
В списке pgsql-hackers по дате отправления