Thanks for posting the tweaks, I have been running into the same issue with my Spacewalk server also. I am going to see if switching the DB backend to Oracle will help at all (I doubt it will however its worth a try)
Regards, Dan Burkland On 5/15/12 11:00 AM, "[email protected]" <[email protected]> wrote: > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 14 May 2012 17:38:02 -0400 >From: Paul Robert Marino <[email protected]> >To: [email protected] >Subject: Re: [Spacewalk-list] Spacewalk 1.7 Postgres out of > connections >Message-ID: > <capjdpdadyovlpgnveeotxsmbeneqo+-w0q7hbmxvamosdr8...@mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >here is what to look at in the postgresql.conf > ># - TCP Keepalives - ># see "man 7 tcp" for details > >#tcp_keepalives_idle = 0 # TCP_KEEPIDLE, in seconds; > # 0 selects the system default >#tcp_keepalives_interval = 0 # TCP_KEEPINTVL, in seconds; > # 0 selects the system default >#tcp_keepalives_count = 0 # TCP_KEEPCNT; > # 0 selects the system default > > >but I would start with the setting in sysctl.conf setting the >following will cause it to heartbeat if the client is idle for 10 >minutes. This should kill off most of the stale connections but leave >the all of the connections where the client is really still there >intact. It's also not a bad thing for your firewall connection >tracking. I like 10 minutes as an interval for this because it doesn't >flood your network needlessly since it only triggers if an connection >is idle for the entire 10 minutes, however does significantly help >clean up dead client connections while keeping false positives down to >a minimum. >" >net.ipv4.tcp_keepalive_time = 600 >" >You can also increase the maximum connections in the postgresql.conf >but that will require you to be a little more aware of how memory >consumption in PostgreSQL works. i have it set to 100 (the default) in >my install >" >max_connections = 100 >" > > > > >On Sat, May 12, 2012 at 7:54 PM, Paul Robert Marino <[email protected]> >wrote: >> Ill send you the exact paramiters I tuned on Monday. >> >> On May 12, 2012 1:56 PM, "Scott Piazza" <[email protected]> >>wrote: >>> >>> Good to know it isn't just me having this issue. >>> >>> I agree that monitoring must play a role, since it wasn't happening in >>> 1.6, and started when I enabled monitoring in 1.7. ?With osa-dispatcher >>> turned off on the server, the issue hasn't reappeared. ?But I'd rather >>> keep osa on. >>> >>> How did you change the idle connection timeout in Postgresql? ?I admit, >>> I don't use Postgres all that often, but I don't see any way of doing >>>it >>> without using something like pgpool. ?Am I missing something obvious? >>> >>> ---------- >>> >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of Paul Robert >>> Marino >>> Sent: Friday, May 11, 2012 6:56 PM >>> To: [email protected] >>> Subject: Re: [Spacewalk-list] Spacewalk 1.7 Postgres out of connections >>> >>> >>> Well I've worked around it by reducing the tcp heartbeat to 10 minutes >>> in /etc/sysctl.conf and reducing the idle client timeout in postgresqls >>> configuration. >>> But yes there is an issue with this. >>> I think it the monitoring that does it but I'm not sure. I can tell you >>> the incidents of it do go up with monitoring turned on. >>> The problem is is seems like its a shared library that isn't logging if >>> the class goes out of scope out of the database correctly that make >>> tracking the root cause significantly harder. >>> I'm not familiar enough with python to figure explain how it should be >>> fixed but in perl the DBI driver had. DESTROY method that catches if >>>the >>> programer forgot to logout of the database before the instance of the >>> class goes out of scope or the application exits. It seems to me this >>>is >>> missing from the python postgresql driver and if that functionality >>> could be added it would resolve the issue. >>> >>> _______________________________________________ >>> Spacewalk-list mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/spacewalk-list > > > >------------------------------ > >_______________________________________________ >Spacewalk-list mailing list >[email protected] >https://www.redhat.com/mailman/listinfo/spacewalk-list > >End of Spacewalk-list Digest, Vol 48, Issue 40 >********************************************** _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
