On 8/4/2016 9:15 AM, Eduardo Morras wrote:
If you set max_connections too high, those connections will compete/figth for same resources, CPU processing, I/O to disks, Memory and caches, Locks, and postgres will spend more time managing the resources than doing real work. Believe me (or us) set it as we say and use a bouncer like pgbouncer. It can run on the same server.
idle connections only use a small amount of memory, a process, a socket, and some file handles. when you have multiple databases, its impossible to share a connection pool across them.
the OP is talking about having 350 'tenants' each with their own database and user on a single server.
your 1 connection per core suggestion is ludicrious for this scenario. in many database applications, most connections are idle most of the time. sure you don't want much over about 2-4X your cpu thread count actually active doing queries at the same time if you want the max transaction/second aggregate throughput, but you can still get acceptable performance several times higher than that, depending on the workload, in my benchmarks the aggregate TPS rolls off fairly slowly for quite a ways past the 2-4 connections per hardware thread or core level, at least doing simple OLTP stuff on a high concurrency storage system (lots of fast disks in raid10)
-- john r pierce, recycling bits in santa cruz -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
