Re: Behaviour patterns on pgsql (7.1.3)

From: Denis Braekhus <denis(at)startsiden(dot)no>
To: pgsql-admin(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Behaviour patterns on pgsql (7.1.3)
Date: 2002-10-31 09:27:14
Message-ID: 200210311027.14914.denis@startsiden.no
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

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

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Andrew Perrin 2002-10-31 12:49:22 Re: URGENT: undoing a mistake
Previous Message Eric L. Blevins 2002-10-31 06:15:00 Signal 11