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
