Re: Effects of IDLE processes - Mailing list pgsql-performance

From Gaetano Mendola
Subject Re: Effects of IDLE processes
Date
Msg-id 4219C4A3.20100@bigfoot.com
Whole thread Raw
In response to Re: Effects of IDLE processes  (Christopher Browne <cbbrowne@acm.org>)
List pgsql-performance
Christopher Browne wrote:
> After a long battle with technology, Gaetano Mendola <mendola@bigfoot.com>, an earthling, wrote:
>
>>JM wrote:
>>
>>>Hi ALL,
>>>
>>>    I was wondering if there is a DB performance reduction if
>>>there are a lot of IDLE processes.
>>>
>>>30786 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>>32504 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>>32596 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>> 1722 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>> 1724 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>> 3881 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>> 6332 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>> 6678 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>> 6700 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>> 6768 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>> 8544 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>> 8873 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>> 8986 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>> 9000 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>> 9010 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>> 9013 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>> 9016 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>> 9019 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>> 9020 ?        S      0:00 postgres: user1 gmadb 10.10.10.1 idle
>>>
>
>
>>In my experience not at all, you have to wonder if some of that are
>>"idle in transaction" that are really a pain in the @#$
>
>
> I'd be concerned about "idle" processes insofar as they are holding on
> to _some_ memory that isn't shared.

For "not at all" I was refering the fact that the normal engine work and
maintenances are not affected ( at least your iron shall be able to
support all these connections and processes ).
A long transaction for example can stop the entire engine if for example
a "Vacuum full" remain stuck on some tables locked by that transaction


Regards
Gaetano Mendola




pgsql-performance by date:

Previous
From: Gaetano Mendola
Date:
Subject: Re: bad performances using hashjoin
Next
From: "Merlin Moncure"
Date:
Subject: Re: seq scan cache vs. index cache smackdown