novel idea
sean finney
seanius at debian.org
Mon May 9 06:16:31 CEST 2005
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>
More information about the Developers
mailing list