Re: [Nagios-devel] Passive check reception in nagios-1.2 does not
Posted: Fri Apr 23, 2004 8:36 am
Don't know how much this helps you, but have you tried using decimals?
I've used 0.5s in a few settings. Can't say from my own experience that
it'll work where you need it to, but it's an option.
(Notably, I've only use 0.5s and 0.3s. Maybe 0.000001 will work
)
On Fri, 2004-04-23 at 18:01 +0200, Bj=F8rnar Bj=F8rgum Larsen wrote:
> Hello,
>=20
> there seems to be no way of getting nagios-1.2 to process passive service=
checks faster than once per second. In our tests, setting=20
> command_check_interval=3D-1
> produces far worse results than setting=20
> command_check_interval=3D1s
>=20
> Problem:
> If the above is generally true, given an average command length put into =
the external command file of 120 characters, and a FIFO length of 4096 char=
acters, it's impossible for nagios-1.2 to handle more than 35 passive check=
s a second. We want our passive-only nagios-1.2 hosts to process at least 1=
00 checks a second, and we don't see any other reasons why a nagios host do=
ing nothing but receiving and forwarding checks can't do that.
>=20
> Possible hack:=20
> Patching the nagios-1.2 source to use microseconds since epoch instead of=
seconds since epoch when scheduling checks (if doing so for external comma=
nds, everything else has to tag along, I think). Accompanied by a 'm' for m=
illiseconds option, we can specify e.g command_check_interval=3D100m to get=
nagios to check its external command file 10 times every second. We need t=
o modify the sources to use gettimeofday() instead of time(), a redefinitio=
n of the TIMED_EVENT struct, and dividing/multiplying things the other plac=
es TIMED_EVENT is used. Do you think this is a sound way of handling this? =
If anyone's done this already (or anything else that significantly speeds =
up the checks of external commands), could you mail the patches to the list=
, please?=20
>=20
> According to rumour, nagios-2.0 keeps the FIFO empty. How's this done in =
2.0? Has anyone performance tested nagios-2.0 external command handling? An=
y chance of a backport to 1.2, Ethan?
>=20
>=20
> Test description:
> Locally on the Nagios server, simply echo'ing 5000 lines of real nsca dat=
a to the external command file, one "echo $some_check_result > nagios.cmd" =
per check, as fast as possible, and measuring how long it takes.
>=20
> If nagios is checking "as often as possible" (command_check_interval=3D-1=
) the results are varying a lot, best values are 15 checks / second. Worst =
results took so long I couldn't be bothered waiting. If checking once per s=
econd, we get results very close to the theoretical maximum of approx. 33 c=
hecks per second given FIFO length of 4096, since our average # characters =
per check put into the FIFO is 123.=20
>=20
> One problem with command_check_interval=3D-1 seems to be that nagios won'=
t re-read the FIFO until it has finished processing all checks from the pre=
vious read. Note that we used (and reused) the same couple-of-days old data=
for these tests. Since I'm not sure exactly how nagios-1.2 computes when t=
o schedule the next command-file-read with command_check_interval=3D-1, I d=
on't know wether this invalidates this part of the test results.
>=20
> We tested on a compaq dl360 P3 1133MHz, 256MB memory, running on Debian G=
NU/linux-2.4.25, and nagios-1.2. If need be, we'll use better hardware in p=
roduction, but both load and memory use were low during these tests, so the=
hardware should not matter for the test results. We have no web server run=
ning on the nagios host we were testing.
>=20
>=20
> Thank you in advance for all input, and have a good week-end!
>=20
> Bj=F8rnar
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Nagios-devel mailing list
> [email protected]
> https://l
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
I've used 0.5s in a few settings. Can't say from my own experience that
it'll work where you need it to, but it's an option.
(Notably, I've only use 0.5s and 0.3s. Maybe 0.000001 will work
)On Fri, 2004-04-23 at 18:01 +0200, Bj=F8rnar Bj=F8rgum Larsen wrote:
> Hello,
>=20
> there seems to be no way of getting nagios-1.2 to process passive service=
checks faster than once per second. In our tests, setting=20
> command_check_interval=3D-1
> produces far worse results than setting=20
> command_check_interval=3D1s
>=20
> Problem:
> If the above is generally true, given an average command length put into =
the external command file of 120 characters, and a FIFO length of 4096 char=
acters, it's impossible for nagios-1.2 to handle more than 35 passive check=
s a second. We want our passive-only nagios-1.2 hosts to process at least 1=
00 checks a second, and we don't see any other reasons why a nagios host do=
ing nothing but receiving and forwarding checks can't do that.
>=20
> Possible hack:=20
> Patching the nagios-1.2 source to use microseconds since epoch instead of=
seconds since epoch when scheduling checks (if doing so for external comma=
nds, everything else has to tag along, I think). Accompanied by a 'm' for m=
illiseconds option, we can specify e.g command_check_interval=3D100m to get=
nagios to check its external command file 10 times every second. We need t=
o modify the sources to use gettimeofday() instead of time(), a redefinitio=
n of the TIMED_EVENT struct, and dividing/multiplying things the other plac=
es TIMED_EVENT is used. Do you think this is a sound way of handling this? =
If anyone's done this already (or anything else that significantly speeds =
up the checks of external commands), could you mail the patches to the list=
, please?=20
>=20
> According to rumour, nagios-2.0 keeps the FIFO empty. How's this done in =
2.0? Has anyone performance tested nagios-2.0 external command handling? An=
y chance of a backport to 1.2, Ethan?
>=20
>=20
> Test description:
> Locally on the Nagios server, simply echo'ing 5000 lines of real nsca dat=
a to the external command file, one "echo $some_check_result > nagios.cmd" =
per check, as fast as possible, and measuring how long it takes.
>=20
> If nagios is checking "as often as possible" (command_check_interval=3D-1=
) the results are varying a lot, best values are 15 checks / second. Worst =
results took so long I couldn't be bothered waiting. If checking once per s=
econd, we get results very close to the theoretical maximum of approx. 33 c=
hecks per second given FIFO length of 4096, since our average # characters =
per check put into the FIFO is 123.=20
>=20
> One problem with command_check_interval=3D-1 seems to be that nagios won'=
t re-read the FIFO until it has finished processing all checks from the pre=
vious read. Note that we used (and reused) the same couple-of-days old data=
for these tests. Since I'm not sure exactly how nagios-1.2 computes when t=
o schedule the next command-file-read with command_check_interval=3D-1, I d=
on't know wether this invalidates this part of the test results.
>=20
> We tested on a compaq dl360 P3 1133MHz, 256MB memory, running on Debian G=
NU/linux-2.4.25, and nagios-1.2. If need be, we'll use better hardware in p=
roduction, but both load and memory use were low during these tests, so the=
hardware should not matter for the test results. We have no web server run=
ning on the nagios host we were testing.
>=20
>=20
> Thank you in advance for all input, and have a good week-end!
>=20
>
Bj=F8rnar>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Nagios-devel mailing list
> [email protected]
> https://l
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]