Re: Idle connections - Mailing list pgsql-general

From mark
Subject Re: Idle connections
Date
Msg-id 029901cbcb0d$a0105770$e0310650$@com
Whole thread Raw
In response to Re: Idle connections  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Wednesday, October 06, 2010 11:14 PM
> To: mark
> Cc: rod@iol.ie; 'Mathieu De Zutter'; 'Georgi Ivanov'; pgsql-
> general@postgresql.org
> Subject: Re: [GENERAL] Idle connections
>
> "mark" <dvlhntr@gmail.com> writes:
> > If you get to many persistent or otherwise idle connections you might
> be
> > inducing a "thundering herd" condition. Seems like on our servers we
> hit a
> > wall with just having a lot of persistent connections from various
> apps. I
> > don't really understand everything involved here but....
>
> > It seems that a high number of idle connections processes will sleep
> on the
> > same semaphore. When this becomes run-able all the idle connections
> that
> > were sleeping on it become run-able at the same time. This means
> hundreds
> > (in our case) of idle processes do some work even though they are
> idle at
> > the same time. This eats all available cpu time for a few seconds
> then
> > everything goes back to sleep.
>
> What you're describing sounds a lot like the known issue with sinval
> queue overflow response ... but that was fixed in 8.4.  What version
> is this?
>


I Wanted to follow up on this, we upgraded to PG 9.0 (from 8.3) and it
appears this greatly improved our average CPU load. I am not seeing the
extremely large load spikes I used to.


Awesome job - thank you tom and everyone else on the core team.

mark



>             regards, tom lane


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Select + Functions + Composite Types: Behavior
Next
From: "David Johnston"
Date:
Subject: Re: Select + Functions + Composite Types: Behavior