Postgres crash during low-traffic period, need advice.

Hi,

We have a front-end server taking care of Nginx, memcached and
Postgresql. Last night the postgres daemon crashed (traffic was very
low at that time) with the following error:

2010-12-20 03:34:30 EST DETAIL:  Failed system call was
shmget(key=5432001, size=1124474880, 03600).
2010-12-20 03:34:30 EST HINT:  This error usually means that
PostgreSQL's request for a shared memory segment exceeded available
memory or swap space. To reduce the request size (currently 1124474880
bytes), reduce PostgreSQL's shared_buffers parameter (currently
131072) and/or its max_connections parameter (currently 963).

Front-end server has 4GB ram.

The reason why max_connections and shared buffers were so high was
that we recently had to run the server without a connection pooler
because our connection pooler died. We have since fixed the connection
pooler, and last night it was running normally. I didn't think there
would side effects to leaving Postgresql configured with 1024MB
shared_buffers and 963 max_connections

Anyways, I have now reduced the shared_buffers and max_connections to
: 256MB and 140 respectively.

Our connection pooler is configured to establish no more than 128
connections at a time so 140 max_connections will be fine.

The problem is that I am not sure what is the ideal shared_buffers
settings should be. How should we properly "guesstimate" the correct
value for shared_buffers? I saw some people using the values
max_connections * 16KB, so should I reduce it to 2.3MB ?

Also, was this error caused by kernel.shmmax value being too low? (I
just noticed this: Failed system call was shmget(key=5432001,
size=1124474880, 03600).

Thanks,

--
Ben