--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
hi andreas,
On Sun, May 08, 2005 at 08:12:59PM -0700, [email protected]=
forge.net wrote:
> From: Andreas Ericsson
> Subject: Re: [Nagios-devel] novel idea for performance optimization
> Good idea, except that ld linker voodoo (symbol resolution et al)=20
> induces the same or more overhead on systems with copy-on-write fork=20
> (linux, bsd, solaris) and reasonably quick context-switching (linux,=20
> bsd). So the suffering people are those running Nagios on HP and Cygwin.=
=20
> 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=20
> 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=
=20
> 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). =20
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?
--rwEMma7ioTxnRzrJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCfuQfynjLPm522B0RAsDeAJ9Q1+frDx/NbeCKcCELdwUscGqroQCfYEZ7
7lmFVa4q6z+/ez3Xp6//6t4=
=cUPs
-----END PGP SIGNATURE-----
--rwEMma7ioTxnRzrJ--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]