number of checks to 200, while increasing it to 1,000,000 caused it to
execute more than 200, which would seem backwards if 0 basically means
"do as many as you possibly can" (based on CPU).
This would indicate that max_concurrent_checks=3D0 is limiting it to
some number rather than using all the CPU possible, which sounds like
a bug.
On Wed, Apr 14, 2010 at 2:40 PM, Max wrote:
> Your server can only run so many checks at once, so setting it to 0
> only says 'cap parallel check limits by what the CPU can do.'
>
> On our dual quad-core CPU hosts with 8 GB RAM we get about 350 checks
> running in parallel max at any given instant after restart; 90-92% of
> our checks take less than 1 second to complete (most are SNMP-based).
>
> We do attempt to have as many checks run as possible by setting
> max_concurrent to 0 and by tweaking the next check time for all checks
> to be the same second so that Nagios does attempt to run as many
> processes as it possibly can at once.
>
> Were you actually seeing your system start up 10,000 processes at once
> with max_concurrent_checks set to 10,000? =A0That would be perfectly
> reasonably if this were an Erlang-based system
> that number of processes at a given timel at the OS level, what kind
> of system are you running on? =A0Impressive.
>
> - Max
>
> On Wed, Apr 14, 2010 at 4:03 PM, Cary Petterborg
> wrote:
>> We have been experimenting with 3.2.1 before deploying it in our product=
ion environment. When we first started up Nagios 3.2.1 with max_concurrent_=
checks=3D0 (which the documentation says should put no limit on the number =
of concurrent checks), we only got about 200 checks completed per minute. S=
ince we have 37,600 services, this led to quite a high latency.
>>
>> It attempting to increase the number of checks I decided to play with ma=
x_concurrent_checks to see what would result. I went from 0 to 1000, then t=
o 10,0000, then to 100,000 then to 1,000,000(+) for the value. It increased=
the number of checks per minute with each larger number, until I got to 1,=
000,000, where it no longer made any difference.
>>
>> So, my conclusion is that max_concurrent_checks=3D0 is not working prope=
rly. Can anyone else verify that this is the case?
>>
>>
>>
>> Cary Petterborg
>> ICS Monitoring
>> The Church of Jesus Christ of Latter-day Saints
>> Office Phone: 801-240-8267
>> Cell Phone: =A0801-792-4854
>> Email: =[email protected]
>> Google Talk: carypetterborg
>>
>>
>> =A0NOTICE: This email message is for the sole use of the intended recipi=
ent(s) and may contain confidential and privileged information. Any unautho=
rized review, use, disclosure or distribution is prohibited. If you are not=
the intended recipient, please contact the sender by reply email and destr=
oy all copies of the original message.
>>
>>
>>
>> ------------------------------------------------------------------------=
------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Nagios-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/lis ... gios-devel
>>
>
> -------------------------------------------------------------------------=
-----
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Nagios-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/lis ... gios-devel
>
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]