RES: Urgent: nagios + apan memory chewing up

[ali]

 sorry for taking too long to answer.I have a bit more than your number of services now, and the end result that I've reached is that I've used NAGIOS version 1.0 compiled from source along with apan, and its working perfectly fine. I've played with concurrent_checks parameter to the extent where the:nagios -s /usr/local/nagios/etc, but always used the value proposed value. Ali Al-Khalidi--- On Wed 09/10, Marcio Queiroz < marcioqueiroz at vicom.com.br > wrote:From: Marcio Queiroz [mailto: marcioqueiroz at vicom.com.br]To: mav at juniper.net, alikhalidi at excite.com, chet at rcn.com, nagios-users at lists.sourceforge.netCc: marcioqueiroz at vicom.com.brDate: Wed, 10 Sep 2003 12:08:57 -0300Subject: RES: [Nagios-users] Urgent: nagios + apan memory chewing upI have 200 services using apan and i have the same problem, but it onlyhappens when i increse the number_of_concurrent_checks for more than 30. Theproblem is that if i limit in 30, my check latency goes for something like 5minutes. If the 
 solution is to take off apan, i would like to know. Anyideias ?[]sMarcio Q. Dall Agnolphone : 55-21-3873-5826Fax : 55-21-3873-5845marcioqueiroz at vicom.com.brVICOMNet Serviços de Comunicação S/AVisite nossas páginas:Redes Corporativas: Internet Banda Larga: TV por Assinatura : Institucional: http://www.netservicos.com> ----- Mensagem original -----> De: Ian Davidson [SMTP:mav at juniper.net]> Enviada em: quarta-feira, 10 de setembro de 2003 09:59> Para: alikhalidi at excite.com; chet at rcn.com;> nagios-users at lists.sourceforge.net> Cc: marcioqueiroz at vicom.com.br> Assunto: RE: [Nagios-users] Urgent: nagios + apan memory> chewing up> > What was the final conclusion to all of this? I've just hit the same> problem of swap-space being chewed up to the point of distraction but> cannot pinpoint from this thread what the exact -fix- is. Is it really> the perl stuff that's causing it to barf?> > Cheers,> > Ian> > > > ______________
 __________________> > From: nagios-users-admin at lists.sourceforge.net> [mailto:nagios-users-admin at lists.sourceforge.net] On Behalf Of ali> Sent: 16 August 2003 08:30> To: chet at rcn.com; alikhalidi at excite.com;> nagios-users at lists.sourceforge.net> Cc: marcioqueiroz at vicom.com.br> > > > Thanks for the reply, and I realy appriciate your input.> I have my nagios installed from an RPM, version 1.1> I've read somewhere in the posts about this recommendation (compile> without embedded per and perl cache), but after I've checed the RPM spec> built file, it seems that the person who built the RPM has disabled> these two options for RedHat 8 and 9. so I am running a version with> these two options off (any other suggestions), but I might have mis-read> the sepc file!.> > So you're telling me that nagios (v 1.1) has this core problem, even> without Embeded Perl and Perl Cache, or is it this factor that you> eleminated to ge
 t around the problem, please clearify the issue> pertaining to the nagios plugings (especially check_snmp)?> Has the disabling of these two options solved the problem completely in> your case (because if so, I can drop ! the RPMS and go for source)?> > thanks,> > > > > > --- On Thu 08/14, Chet Luther < chet at rcn.com > wrote:> > > From: Chet Luther [mailto: chet at rcn.com]> To: alikhalidi at excite.com, nagios-users at lists.sourceforge.net> Cc: marcioqueiroz at vicom.com.br> Date: Thu, 14 Aug 2003 11:00:13 -0400> Subject: Re: [Nagios-users] Urgent: nagios + apan memory chewing> up> > 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. 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> initiati
 ve to get that done.> > Hope this helps,> > Chet Luther> chet at rcn.com> > ----- Original Message ----- > From: ali> 
 To: nagios-users at lists.sourceforge.net> Sent: Thursday, August 14, 2003 5:40 AM> Subject: [Nagios-users] Urgent: nagios + apan memory chewing up> > ! Greetings,> > I am experiencing a strange behaiviour for nagios and apan.> I'de run nagios for a long time, using the standard plugins> (check_host_alive for 50 services), and my system> (CPU 1GHz, RAM 512, swap 512) was very stable.> not untill I've installed apan (155 services) that the server> starts chewing> memory so fast that the system becomes cloged and the only way> to regain> control for the system is to REBOOT.> I've read and practiced a lot with the tunning paramers of> nagios, and> reached a level where these parameters> max_concurrent_checks (for concurrency)> service_reaper_freq> size of rrd files (to prevent caching of large databse files)> added the -m to snmp_get (based on a recommendation of one of> the users) to> disable the loading of the 
 mib with each call> > but all with no help. I can't put my hands on the problem.the> system starts> memory usage in almost a linear fashion, untill the free section> of> buffers/cache st! arts comming down, and the systems goes to> swap till it> exhast all system Memory.> it is only the difference between the concurrency factor> (max_concurrent_checks) that slows down the rate at which memory> is lost.> > its a production system, and I really appriciate help> > thanks,> > > > > > > ________________________________> > Join Excite! - http://www.excite.com> The most personalized portal on the Web! > > > -------------------------------------------------------> This sf.net email is sponsored by:ThinkGeek> Welcome to geek heaven.> http://thinkgeek.com/sf> _______________________________________________> Nagios-users mailing list> Nagios-users at lists.sourceforge.net> https://lis
 ts.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

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20030916/0cf18494/attachment.html>