[Spacewalk-list] Spacewalk 1.7 Postgres out of connections

Paul Robert Marino prmarino1 at gmail.com
Wed May 16 13:16:31 UTC 2012


Well as it is stated on the site the postgresql code is new and does still
have errors. Oracle as the database is more stable for now but the
developers are improveing the postgresql support with every release. The
next release 1.8 will have a huge number of patches specificly for
postgresql.

The question is are you willing to deal with a few issues now and file bug
reports in exchange for ease of upgrade and better scaleability latter"

If the answer is no use Oracle.

If the answer is yes use PostgreSQL
On May 16, 2012 1:30 AM, "Dan Burkland" <dburklan at nmdp.org> wrote:

> 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, "spacewalk-list-request at redhat.com"
> <spacewalk-list-request at redhat.com> wrote:
>
> >
> >----------------------------------------------------------------------
> >
> >Message: 1
> >Date: Mon, 14 May 2012 17:38:02 -0400
> >From: Paul Robert Marino <prmarino1 at gmail.com>
> >To: spacewalk-list at redhat.com
> >Subject: Re: [Spacewalk-list] Spacewalk 1.7 Postgres out of
> >       connections
> >Message-ID:
> >       <
> CAPJdpdADYOVLpGNveEOTxSmbeNEQo+-w0q7hBmxVAMoSdr80zw at 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 <prmarino1 at gmail.com>
> >wrote:
> >> Ill send you the exact paramiters I tuned on Monday.
> >>
> >> On May 12, 2012 1:56 PM, "Scott Piazza" <scott.piazza at bespokess.com>
> >>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: spacewalk-list-bounces at redhat.com
> >>> [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of Paul Robert
> >>> Marino
> >>> Sent: Friday, May 11, 2012 6:56 PM
> >>> To: spacewalk-list at redhat.com
> >>> 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
> >>> Spacewalk-list at redhat.com
> >>> https://www.redhat.com/mailman/listinfo/spacewalk-list
> >
> >
> >
> >------------------------------
> >
> >_______________________________________________
> >Spacewalk-list mailing list
> >Spacewalk-list at redhat.com
> >https://www.redhat.com/mailman/listinfo/spacewalk-list
> >
> >End of Spacewalk-list Digest, Vol 48, Issue 40
> >**********************************************
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20120516/09bc7a28/attachment.htm>


More information about the Spacewalk-list mailing list