[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-admin
Subject:    Re: [ADMIN] Behaviour patterns on pgsql (7.1.3)
From:       Denis Braekhus <denis () startsiden ! no>
Date:       2002-10-31 9:27:14
[Download RAW message or body]

On Wednesday 30 October 2002 20:09, Tom Lane wrote:
> This strikes me as a fault on the client side, not in Postgres --- to
> wit, poor connection management.  It is not Postgres' job to kill idle
> client connections.

I suppose you are right. The thing is we have never used persistant 
connections (tried to once, learned from the mistake..) and all the mod_php 
scripts (4.1.x version of PHP) do explicitly close their connections..

This might definitely be an apache problem of some kind. It seems to be less 
grave if I drop the MaxRequestsperChild config value for apache to an abysmal 
100.. (Should _not_ be necessary, and is affecting our performance..)

> But having said that, I do not think that idle connections per se would
> cause any performance degradation on the server side.  Perhaps they also
> have open transactions that are holding locks that other queries need?
> That again is really a client-side bug...

Well, believe me, it does.. It only begins to be a real _problem_ not a 
symptom after 10 or so idle connections, but indeed postgresql drops in 
performance with too many open connections.

I figured this part of the problem could possibly be lack of memory for the 
system, and I think I need to play with the postgresql.conf settings. 

I checked back in the archive for hints and tips, and found some, the box has 
1GB of RAM, so I should be able to find some nice balance for it !

Regards
-- 
Denis Braekhus - ABC Startsiden AS
http://www.startsiden.no

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
[prev in list] [next in list] [prev in thread] [next in thread]