On Feb 15, 2008 10:38 PM, Phoenix Kiula <phoenix.kiula@xxxxxxxxx> 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. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
