Antwort: Re: Perf-Problem - Not more than 255 Childs?

[Ben Clewett]

Sorry, I think I missed the beginning of this thread.  But I can see if 
I can provide any relevant information.

Nagios only needs to open *one* file for PerfParse to work.  This file 
is help open permanently.  (serviceperf.log)  The 256 limit per process 
is unlikely to be of any relevance.

MySQL of course opens up hundreds.  (326 on my machine.)  If you have a 
problem here, try moving MySQL to another host.  This will also do 
wonders for your performance.

I can add to the comment about adjusting the max open files.  The fact 
that it's 256 and not 257 or 255 suggests this is not a limit you can 
change.  If you do this, you will probably make your system unstable, if 
it runs at all.  Don't do it :)

Regards, Ben.


Andreas Ericsson wrote:

> h.baecker at ecofis.de wrote:
> 
>> I'm sorry, this is not the answer because the system doesn't swap 
>> heavily and the memory is ok too.
>>
>> But I think there are some Kernel limits to 255 Procesess...
>>
>> ###
>> less /usr/src/linux/include/linux/limits.h
>> [...]
>> #define OPEN_MAX         256    /* # open files a process may have */
>> [...]
>> ###
>>
>> We will try to fix this in a few days...
>>
> 
> Please, please, please don't hack the kernel. The limits in it are there 
> for a reason, and shouldn't be tampered with to fix broken applications.
> 
> If nagios could be set up to print its perfdata to a local socket (maybe 
> it already can?) then heavy performance issues with forking a 
> child-process to write perfdata for each check can be done away with. 
> This would also take care of the issues with data-loss.
> 
> If you're going to do some hacking, I suggest you start in Nagios, and 
> then email Ben (Clewett, the PerfParse guy) what changes you've done so 
> he can make adjustments for the improvements.
> 
>> Thanks
>>
>>
>>
>>
>> Marco Ramos <mramos at co.sapo.pt> 18.06.2004 13:25
>>
>> An
>> h.baecker at ecofis.de
>> Kopie
>> nagios-users at lists.sourceforge.net
>> Thema
>> Re: [Nagios-users] Perf-Problem - Not more than 255 Childs?
>>
>>
>>
>>
>>
>>
>>
>> This should be the answer to your problem:
>>
>> http://www.nagios.org/faqs/viewfaq.php?faq_id=115
>>
>> HTH,
>> mramos
>>
>> On Fri, 2004-06-18 at 10:15, h.baecker at ecofis.de wrote:
>>
>>> Hi List,
>>>
>>> I have som performance Problems with my Nagios. It is running on an
>>> IBM Server with following specs:
>>>
>>> CPU Info:
>>> 4 x                 Intel(R) XEON(TM) CPU 2.00GHz
>>>
>>> Mem Info:
>>>        total:                    used:                free: 
>>> shared:         buffers:          cached:
>>> Mem:  2649300992         2368167936         281133056        0 
>>> 672956416         949780480
>>> Swap: 1081470976         48660480         1032810496
>>>
>>> I think it is not a small system.
>>>
>>> All about we've got 613 Hosts and 2600 Services.
>>>
>>> I would say that 99% of the service checks have an check_interval =
>>> 600 seconds.
>>>
>>> The Process Info says that just 75% of the whole checks where checked
>>> within a 5 minute intervall.
>>>
>>> During my examine of nagios and system I found out that max 255
>>> procesess owned by nagios with service checks etc. Is there a limit of
>>> maximum procs?
>>> or:
>>> How can I optimize Nagios to check all of the Services within 5
>>> minutes? Any ideas?
>>>
>>> Thanks for hopefully a much of answers.
>>>
>>> Hendrik
>>
>>
>>
>>
>>
>>
> 



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
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