Urgent: nagios + apan memory chewing up

[Chet Luther]

Stanley,
    I am still running netsaint-plugins-1.2.9-4 under nagios-1.0b6.  My
analysis wasn't in depth.  I just noticed that my Nagios process would grow
to upwards of 200mb after a couple of weeks.  When I disabled the perl cache
and embedded perl support, I no longer had the problem.
    I once had the same problem with a mod_perl enabled Apache, and it
turned out that I had just been putting too much stuff in the global
namespace.  As far as I'm aware, mod_perl uses the same "put each script in
its own package" approach.
    I would guess (usually meaning I'm wrong) that Ali has less RAM/Swap
than you, which is why his memory usage could exhibit more severe problems
than yours.  Personally I am running with 1GB of RAM plus twice that much
swap, so I didn't have the serious problems that Ali is reporting either.
    Another thing to take into consideration is that he is using APAN.  I
haven't tried it myself, but I think I read that it uses it's own
uber-plugin to do everything.  Could it be possible that it isn't ePN safe?
    I suppose I'm overdue for an upgrade.  I'll compile the latest version
of Nagios/Plugins with ePN/cache enabled sometime today, and see if I still
have the same issues.

Chet Luther
chet at rcn.com

> Dear Sir,
>
> I am writing to thank you for your letter and say,
>
> > From: "Chet Luther" <chet at rcn.com>
> > To: <alikhalidi at excite.com>,
> > <nagios-users at lists.sourceforge.net>
> > Cc: <marcioqueiroz at vicom.com.br>
> > Subject: Re: [Nagios-users] Urgent: nagios + apan memory chewing up
> > Date: Thu, 14 Aug 2003 11:00:13 -0400
> >
> > Ali,
> >     Recompile Nagios without embedded perl or perl caching support.  I
had
> > this same problem, and it was due to global namespace pollution in the
> > embedded perl cache.
>
> would you mind providing some more detail about the analysis that lead
> to this conclusion ?
>
> This Nag ($this->nagios) is monitoring more services with less hardware
> (Dell 350/256 MB, 200 hosts, 340 active services) using ePN and doesn't
> show the problem reported by Ali. However, Ali's host could have a
> greater load.
>
> (The only problem I think may be ePN related is a Nag process hogs the
> CPU and needs to be HUP'd, once each 2-4 weeks. The ePN memory leaks
> are _much_ less dramatic: Nag gets restarted each fortnight or so when
> the resident size above 60 MB or so)
>
> In this case, I am using a lot of local Perl plugins (hemi mod_perl
> safe) and some of the old 1.2.9 series (with some local mods).
>
> The ePN support puts each plugin in it's own Perl package and then calls
> it as a subroutine in that package; it seems unlikely therefore that
> other variables are being trampled (impossible if the plugins use
> lexicals - carefully because of the closure issues).
>
> > The real solution to this problem would be rewriting
> > all the perl plugins/extensions in a mod_perl safe way, but I don't see
any
> > initiative to get that done.
> >
>
> IIRC, Subhendu dealt with the ePN safety issues in the 1.3.x release (ie
> sometime ago).
>
> If there are more than 5 plugins that aren't mod_perl safe would you let
> me know ?
>
> Otherwise, would you write the list with the names of the malefactors ?
>
> > Hope this helps,
> >
> > Chet Luther
> > chet at rcn.com
>
> Yours sincerely.
>
> -- 
> ------------------------------------------------------------------------
> Stanley Hopcroft
> ------------------------------------------------------------------------



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null