On Feb 15, 2008 10:38 PM, Phoenix Kiula <phoenix.kiula@gmail.com> wrote:
> My hosting provider tells me that the Postgresql server is taking up a
> lot of memory but I've been running the same db with the same config
> for over 2 years. Yes we have been growing but what happened in the
> last 3 days to warrant a sudden spike in memory consumption??!!
OK, you've repeated this a few times. Unless your load has been the
same the whole time, this statement means little. If the same config
works for 2 years at load x, but fails in 1 day at load 3x then the
problem might have been there all along, and you just weren't running
the system hard enough to find the problem.
Just because PostgreSQL is exhibiting problems doesn't mean it's all
postgresql's fault.
150 or 100 connections is a LOT for a postgresql server, but
especially so if you went from actually using 5 or 10 to using 98.
The setting's the same, but the number is use is vastly different and
will have vastly different results on how postgresql runs.
Hanging connections could EASILY cause the problem you're seeing. If
the network loses your connection from your app tier to your database,
your database might have 100 connections open doing nothing but
sitting idle in transaction holding data in memory until the
tcp_keepalive kicks in and kills them.
The earlier host connection errors point to that problem as well.
So, do you have mysteriously crashing or disappearing apache child
processes? What do the error logs for apache have to say?
Can you tell what your load was when the system worked and what it is
now by trawling through the logs or something? (apache or pgsql as
long as their equivalent for both time periods.)
If you start leaving hanging connections to the database then you are
in fact DOSing the database server. Not all DOS attacks are
intentional, and a crashing apache - php can do it even without
persistent connections.
I'd say you haven't proven where the problem is yet, and should look
at the app tier.
