High Service Check Latency

Simone Felici s.felici at mclink.eu
Wed May 23 11:52:12 CEST 2012


So, cpuload is stable around 5.00 - 5.50. IO wait is difficult to identify.
Using top I can read an average of 0% with some peaks up to 4%. Using iotop the process kjournald is 
jumping on first position often with peaks to 10-20%, back to 0 immediatly.
Second place for nagios process. But the 1sec refresh is changing very often the situation.
Semms really interesting your doc, also I'll try some solutions. I'll use sym links to not alter any 
configuration file. Should do the trick as well. I'll let you know!

Thank you!

Simon


Il 22/05/2012 16:34, Mike Guthrie ha scritto:
> What kind of information do you have about average CPU load or I\O wait
> time?  Whether Nagios is using ndoutils or not there will be a hardware
> limit as to how many disk writes it can handle in a given period of
> time.  Even though you're only running a few active checks, it could be
> a symptom that your machine is having to wait on itself to write to disk
> for other things as well.  The doc below is written for Nagios XI, but
> of a lot of the items apply to Core as well.  I would consider exploring
> some options with a RAM disk in order to reduce disk activity.
>
> http://assets.nagios.com/downloads/nagiosxi/docs/Utilizing_A_RAM_Disk_In_NagiosXI.pdf
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null





More information about the Users mailing list