| From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
|---|---|
| To: | "List, Postgres" <pgsql-general(at)postgresql(dot)org> |
| Subject: | max_connections proposal |
| Date: | 2011-05-26 02:58:21 |
| Message-ID: | 4DDDC1CD.3010600@postnewspapers.com.au |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
There might be a very cheap and simple way to help reduce the number of
people running into problems because they set massive max_connections
values that their server cannot cope with instead of using pooling.
In the default postgresql.conf, change:
max_connections = 100 # (change requires restart)
# Note: Increasing max_connections costs ~400 bytes of shared memory
# per connection slot, plus lock space (see max_locks_per_transaction).
to:
max_connections = 100 # (change requires restart)
# WARNING: If you're about to increase max_connections above 100, you
# should probably be using a connection pool instead. See:
# http://wiki.postgresql.org/max_connections
#
# Note: Increasing max_connections costs ~400 bytes of shared memory
# per connection slot, plus lock space (see max_locks_per_transaction).
#
... where wiki.postgresql.org/max_connections (which doesn't yet exist)
explains the throughput costs of too many backends and the advantages of
configuring a connection pool instead.
Sure, this somewhat contravenes the "users don't read - ever" principle,
but we can hope that _some_ people will read a comment immediately
beside the directive they're modifying.
--
Craig Ringer
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2011-05-26 03:08:13 | Re: PostgreSQL 8.4.8 bringing my website down every evening |
| Previous Message | Craig Ringer | 2011-05-26 02:45:50 | Re: PostgreSQL 8.4.8 bringing my website down every evening |