Nagios-devel digest, Vol 1 #807 - 8 msgs

sean finney seanius at seanius.net
Wed May 11 03:44:01 CEST 2005


hey andreas,

On Tue, May 10, 2005 at 10:29:16AM +0200, Andreas Ericsson wrote:
> In some cases they are. Pure multithreading would do well not to meddle 
> with in-house plugins, since that leaves no means of protection for the 
> core in case the plugin misbehaves (which it's bound to do sooner or later).

yeah, i'd be wary of segfaulting plugins in that case too.  

> Number of CPU's doesn't matter. It's the number of active processes 
> that's important. Most of nagios' time is lost idling between two chunks 
> of checks because it doesn't parallellize well enough (one chunk needs 
> to finish completely before the next can begin). A great improvement 
> would be to add checks to the queue in serial but letting them run as 
> they become available.

agreed...

> Nopes, it won't. The forked children just hang around and wait for the 
> popen call to finish (pclose and fgets both block), which means they 
> don't claim a CPU and thus aren't eligible for activation in the kernel 
> scheduling loop.

it's true that when the process is in a select/poll/wait or other sleeping
state it won't take up time, but there's still the initial startup cost
of fork/exec'ing the process in the first place.  

> check_icmp doesn't. I wrote it to increase the abysmal performance of 

yeah, i was referring to check_ping, which does.

> Ah, the lure of intellectual masturbation. ;)
> I'm looking forward to seeing the code and the benchmarks.

you know, i almost used that phrase myself, but then figured
i might offend someone's sensibilities and/or risk having
google forever associate the word to me :)

anyway, here's the goods:

http://www.seanius.net/tmp/dltest.tgz

given my recent hijinks, a quick sanity check over my code is probably
in order (in fact i think there is some kind of race in there, maybe).
after that, "make test" will get you the numbers.  

i found that the overall "real" time was not significantly impacted,
but there does seem to be a modest improvement in user/sys time--and
even more so if you run the test on a slower/busier machine.


	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20050510/65314a43/attachment.sig>


More information about the Developers mailing list