(please quote properly) On 2015-03-15 19:55:23 -0400, 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. It may work acceptably in some scenarios, but it can lead to significant problems. Several things in postgres things in postgres scale linearly (from the algorithmic point of view, often CPU characteristics like cache sizes make it wors) with max_connections, most notably acquiring a snapshot. It usually works ok enough if you don't have a high number of queries per second, but if you do, you can run into horrible contention problems. Absurdly enough that matters *more* on bigger machines with several sockets. It's especially bad on 4+ socket systems. The other aspect is that such a high number of full connections usually just isn't helpful for throughput. Not even the most massive NUMA systems (~256 hardware threads is the realistic max atm IIRC) can process 4.5k queries at the same time. It'll often be much more efficient if all connections above a certain number aren't allocated a full postgres backend, with all it's overhead, but use a much more lightweight pooler connection. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
