Skip site navigation (1) Skip section navigation (2)

Re: Postgres filling up hard drive with swap files

From: Joe Lester <joe_lester(at)sweetwater(dot)com>
To: postgres list <pgsql-general(at)postgresql(dot)org>
Cc: Bill Moran <wmoran(at)potentialtech(dot)com>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Postgres filling up hard drive with swap files
Date: 2004-08-20 19:59:27
Message-ID: 71050674-F2E3-11D8-BDD7-000A95A58EA0@sweetwater.com (view raw or flat)
Thread:
Lists: pgsql-general
On Aug 20, 2004, at 2:43 PM, Tom Lane wrote:
> Bill Moran <wmoran(at)potentialtech(dot)com> writes:
>> Joe Lester <joe_lester(at)sweetwater(dot)com> wrote:
>>>> I'm wondering, however, if you have a connection leak instead.  i.e.
>>>> is it possible that your client application is opening a whole bunch
>>>> of connections and never closing them?
>>>
>>> No. The clients open only one connection (and hang onto it for dear
>>> life  :-).
>
>> If these clients aren't utilizing the database, it might be worthwhile
>> to have them disconnect after a period of inactivity, and reconnect 
>> when
>> things get busy again.
>
> If my theory is right, this would actually be counterproductive.  The
> leak I think I'm seeing is associated with backend exit and so the way
> to slow it as much as possible is to prolong backend lifetime as much
> as possible.  Joe, what is the mean lifetime of your connections 
> anyway?
> I assume they don't stay up forever.

They are "permanent connections", meaning that the same connection 
stays open on the server as long as the client application is running. 
And it's common for the clients to stay running for days at a time. I'd 
say the average length of a connection is 3 days.



In response to

Responses

pgsql-general by date

Next:From: Bill MoranDate: 2004-08-20 20:01:11
Subject: Re: Postgres filling up hard drive with swap files
Previous:From: Tom LaneDate: 2004-08-20 19:49:33
Subject: Re: Postgresql 8.0 beta 1 - strange cpu usage statistics and slow vacuuming

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group