novel idea

[sean finney]

hi andreas,

On Sun, May 08, 2005 at 08:12:59PM -0700, nagios-devel-request at lists.sourceforge.net wrote:
> From: Andreas Ericsson <ae at op5.se>
> Subject: Re: [Nagios-devel] novel idea for performance optimization

> Good idea, except that ld linker voodoo (symbol resolution et al) 
> induces the same or more overhead on systems with copy-on-write fork 
> (linux, bsd, solaris) and reasonably quick context-switching (linux, 
> bsd). So the suffering people are those running Nagios on HP and Cygwin. 
> Not a great many, I presume.

no, i think you're not understanding what i'm suggesting.  let me
try and be more clear.  let's use check_tcp as an example.  when
compiling check_tcp, in addition to the standalone binary, a shared
object something like libnagios-check_tcp.so would be created.
this shared object would have the symbol "main" renamed "check_tcp"

when nagios starts up, the first time it goes to execute check_tcp (or
even earlier, when it first reads about the check_commands), it looks
for such a library via dlopen().  if successful, it fetches the address
of the check_tcp function via dlsym().  from that point forward, there
is ZERO overhead, because there's no fork/exec, nor is there any symbol
resolution, it's just calling a function.  make sense?

this could further be enhanced by adding multi-threading capabilities
to such a scheme (you could have a seperate thread for each
check_command, or perhaps some other scheme).  but what's best is
that it would involve minimal changes to the pre-existing plugins,
and wouldn't require any significant re-designing of the nagios
architecture.

> This is moot. All operating systems worth their salt caches frequently 
> accessed programs so the code is already in memory anyway.

systems cache frequently accessed pages in memory, but there's still
unavoidable overhead in creating a new process, as well as the
context switching between the various processes.

> They would also have to add some code that splits arguments the way they 
> are supposed to, including some other additional stuff.

isn't that already done?  hmm... looking in the nagios code, it looks like
all the plugins are called with popen[1].  so that means *two* fork/execs
(one for /bin/sh, one for the command /bin/sh executes).  

anyway, this wouldn't be very hard to do, just split the arguments on
whitespace and call check_tcp() with what ought to have been passed to
exec.


	sean

[1] any reason it's being done this way and not with fork/exec/dup?
-------------- 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/20050509/605c25bf/attachment.sig>