On 22 Červenec 2011, 10:29, Albe Laurenz wrote: > Have you considered the possibility that the limit and the error do not > originate in that database, but in the application server? If the max_connections is 1200 and you get that error with 1000 of them, it's probably a problem with a connection pool in your application server (not such whit platform you're working on). >> If possible guide me how to calculate max_connections based on > available hardware. > > It is almost unlimited on any hardware. That does not mean that things > will > perform well beyond a certain limit. The limiting factor I mentioned is > the > operating system, and these limits can usually be adjusted. Theoretically it's unlimited, in practice the optimal value is much lower. The general rule of thmub is usually max_connections = number of cores + number of drives so with a 4-core CPU and 10 drives you'll get about 14 connections. That's very rough - it might be a bit higher, but I don't expect to grow it above 30. So having 1200 connections is a bit extreme - if the connections are active all the time (not idle, doing something), the overhead of managing them will be severe. Don't forget each connection is equal to a separate process, so it's not exactly cheap. Do you really need that number of connections? What I'd suggest is to run a series of pgbench tests with various "-c" values (10, 20, 30, ...) to get some basic starting point. Then I'd set pgbouncer with this number of db connections and 1000 of client connections, and pool_mode=transaction. Tomas -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
