<table cellpadding=3 cellspacing=0 border=0 width=100% bgcolor=white><tr valign=top><td width=100%>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@vicom.com.br > wrote: <BLOCKQUOTE style="PADDING-LEFT: 7px; MARGIN-LEFT: 7px; BORDER-LEFT: orange 2px solid">From: Marcio Queiroz [mailto: marcioqueiroz@vicom.com.br] To: mav@juniper.net, alikhalidi@excite.com, chet@rcn.com, nagios-users@lists.sourceforge.net Cc: marcioqueiroz@vicom.com.br Date: Wed, 10 Sep 2003 12:08:57 -0300 Subject: RES: [Nagios-users] Urgent: nagios + apan memory chewing up I have 200 services using apan and i have the same problem, but it only happens when i increse the number_of_concurrent_checks for more than 30. The problem is that if i limit in 30, my check latency goes for something like 5 minutes. If the solution is to take off apan, i would like to know. Any ideias ? []s Marcio Q. Dall Agnol phone : 55-21-3873-5826 Fax : 55-21-3873-5845 marcioqueiroz@vicom.com.br VICOM Net Serviços de Comunicação S/A Visite nossas páginas: Redes Corporativas: <HTTP: www.vicom.com.br> Internet Banda Larga: <HTTP: www.virtua.com.br> TV por Assinatura : <HTTP: www.net.tv.br> Institucional: http://www.netservicos.com > ----- Mensagem original ----- > De: Ian Davidson [SMTP:mav@juniper.net] > Enviada em: quarta-feira, 10 de setembro de 2003 09:59 > Para: alikhalidi@excite.com; chet@rcn .com; > nagios-users@lists.sourceforge.net > Cc: marcioqueiroz@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@lists.sourceforge.net > [mailto:nagios-users-admin@lists.sourceforge.net] On Behalf Of ali > Sent: 16 August 2003 08:30 > To: chet@rcn.com; alikhalidi@excite.com; > nagios-users@lists.sourceforge.net > Cc: marcioqueiroz@vicom.com.br > > > > Thanks for the reply, and I realy appriciate your input. > I ha ve 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 get 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@rcn.com > wrote: > > > From: Chet Luther [mailto: chet@rcn.com] &gt ; To: alikhalidi@excite.com, nagios-users@lists.sourceforge.net > Cc: marcioqueiroz@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 > initiative to get that done. > > Hope this helps, > > Chet Luther > chet@rcn.com > > ----- Original Message ----- > From: ali > To: nagios-users@lists.sourceforge.net > Sent: Thursday, August 14, 2003 5:40 AM > Subject: [Nagios-users] Urgent: nagios + apan memory chewing up > > ! Greetin gs, > > 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 proble m.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@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 </BLOCKQUOTE></td></tr></table><hr>Join Excite! - <a href=http://www.excite.com target=_blank>http://www.excite.com</a> The most personalized portal on the Web!