Service check latency rises when service notification event occurs frequently

[Andreas Ericsson]

On 10/18/2011 04:19 AM, Yu Watanabe wrote:
> Hi all!
> 
> We are doing some performance test with nagios 3.3.1 in following
> environement.
> 
> Server 1
> 
> RHEL 5.5 64 bit
> 1CPU Xeon E3-1220 3.10 GHz
> Memory    8GB
> Disk      450GB (Raid 1)
> 
> Server 2
> 
> RHEL 5.5 64 bit
> 2CPU Xeon E5630 2.53 GHz
> Memory    8GB
> Disk      300GB (Raid 5)
> 
> 3011 hosts
> 6173 services (3011 ping check)
> 
> Also putting some loads on the background,
> 
> 1. 347 syslog msg per sec
> 2. 1 passvie service check per sec for notification event to two contact group
> 3. 30 ms of network traffic latency
> 4. cacti polling
> 
> I have realized that Server 1 has service check latency for average 80 second but
> server 2 has average below 10 second.
> 

Server 2 has Raid 5 (superior to Raid 1) and an extra CPU. I'm not very
surprised that it performs better than server 1. What happens if you
put spool directories and objects.cache and status.sav on ramdisk?

> Does notification process naturally effect the service check scheduling?
> 

Not by much, no.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
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