Re: [Nagios-devel] Re: Nagios-devel digest, Vol 1 #807 - 8 msgs
Posted: Wed May 11, 2005 2:33 pm
--ZPt4rx8FFjLCG7dd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
hey,
On Wed, May 11, 2005 at 10:10:01AM +0200, Andreas Ericsson wrote:
> which hogs as much free cpu as possible. i and x are registers to make=20
> contextswitches really expensive. With this one running, I got the=20
> following results;
>=20
> ---% dltest/popen with 1000 kids:
> real 0m12.895s
> user 0m0.000s
> sys 0m0.010s
>=20
> dltest/dlopen with 1000 kids:
> real 0m31.265s
> user 0m0.000s
> sys 0m0.090s
>=20
> ---% This is consistent over several runs, with only minor changes to the=20
> timings. As you can see, the gain of not forking is gone at 100=20
> instances and for 1000 kids the dlopen approach offers clearly abysmal=20
> performance while the popen approach stays roughly the same.
i'm really curious as to why this is. i'm imagining this is because
waiting on a select behaves better with the scheduler?
> You would do better to abandon this and instead focus on enhancing=20
> multithreading/multiplexing support or fixing the plugins. There's lots=
=20
> of work to do there to improve nagios' performance.
well, in any case i'm convinced at this point that the gains are marginal
at best. i'd still be interested in discussing the multi-threaded
approach further though, as that does sound much more promising.
sean
--ZPt4rx8FFjLCG7dd
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)
iD8DBQFCgogeynjLPm522B0RAp9NAJ9w4KVv89brqnsRh6ayu+cA4v0FmQCfRM7l
TcdzQWNQ8eDxSIt30kOon3A=
=At3s
-----END PGP SIGNATURE-----
--ZPt4rx8FFjLCG7dd--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
hey,
On Wed, May 11, 2005 at 10:10:01AM +0200, Andreas Ericsson wrote:
> which hogs as much free cpu as possible. i and x are registers to make=20
> contextswitches really expensive. With this one running, I got the=20
> following results;
>=20
> ---% dltest/popen with 1000 kids:
> real 0m12.895s
> user 0m0.000s
> sys 0m0.010s
>=20
> dltest/dlopen with 1000 kids:
> real 0m31.265s
> user 0m0.000s
> sys 0m0.090s
>=20
> ---% This is consistent over several runs, with only minor changes to the=20
> timings. As you can see, the gain of not forking is gone at 100=20
> instances and for 1000 kids the dlopen approach offers clearly abysmal=20
> performance while the popen approach stays roughly the same.
i'm really curious as to why this is. i'm imagining this is because
waiting on a select behaves better with the scheduler?
> You would do better to abandon this and instead focus on enhancing=20
> multithreading/multiplexing support or fixing the plugins. There's lots=
=20
> of work to do there to improve nagios' performance.
well, in any case i'm convinced at this point that the gains are marginal
at best. i'd still be interested in discussing the multi-threaded
approach further though, as that does sound much more promising.
sean
--ZPt4rx8FFjLCG7dd
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)
iD8DBQFCgogeynjLPm522B0RAp9NAJ9w4KVv89brqnsRh6ayu+cA4v0FmQCfRM7l
TcdzQWNQ8eDxSIt30kOon3A=
=At3s
-----END PGP SIGNATURE-----
--ZPt4rx8FFjLCG7dd--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]