[Spacewalk-list] Massive problems with slow updates on rhnServerAction

[Jonathan Scott]

Paul,

This is reading like the exact same issue you and I discussed on-list a few
weeks ago. I had closed out that thread as resolved, but the issue has
since creeped its way back up. Patrick breaks it down well, I too just get
a pile up of "idle in transaction" db connections which do not clear with
any configuration change I have made (tcp timeout, idle timeout and
connection limit adjustments in postgresql.conf); a restart of all
associated services gives me about 3-5 days before the app becomes
unresponsive.

Patrick, may I ask how are you loading your errata?

- Jonathan

On Thu, Sep 20, 2012 at 2:45 AM, Patrick Hurrelmann <
patrick.hurrelmann at lobster.de> wrote:

> Hi,
>
> On 19.09.2012 20:13, Paul Robert Marino wrote:
> > run a full vacuum analyze on the database.
> > once it completes you should be in better shape
>
> Thanks for that suggestion, but been there, done that. This is one of
> the frist steps for postgres related performance issues ;) Right now I
> disabled osad on most local systems and I'm in much better shape now.
> Right now it only has 40 connections open an one hanging "update
> rhnServerAction". Wonder if this really happens due to the use of push
> to the clients?
>
> > and if the count still keeps going up consider utilizing pgpool.
> > pgpool if configured correctly will really just reuse the stale idle
> > connections.
>
> Good idea actually. I will consider this. But it won't help for "Idle in
> transaction", right?
>
> Thanks,
> Patrick
>
> --
> Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg
>
> HRB 178831, Amtsgericht München
> Geschäftsführer: Dr. Martin Fischer, Rolf Henrich
>
> _______________________________________________
> 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/20120920/1b15136d/attachment.htm>