RETRY: CPU Question

[Ewan Leith]

Am I reading that correctly that your services.cfg and serviceextinfo.cfg
are 1.6MB and 2MB respectively? That's an awful lot of text.
 
The cgis parse the extinfo file on every load, and possibly the services
file too, which will cause massive slowdown with files that size.
 
nagios2 will including caching of all config files, along with various other
bits and pieces that might help. until then I think you need to look at
making much more use of the template system to reduce the amount of info in
your config files, or maybe try using mysql to store the information.
 
Ewan

-----Original Message-----
From: Fred Albrecht [mailto:Fred.Albrecht at za.tiscali.com]
Sent: 07 April 2003 09:04
To: nagios-users at lists.sourceforge.net
Subject: [Nagios-users] RETRY: CPU Question



Hi 

Not having received a reply on my previous question, I'll try again. :)
(Please tell me where I can ask this question, if this is the wrong place to
ask.)

My cgi's take about 30 seconds from clicking on their links to displaying
something on my screen.  I'm running a P4, 512M Red Hat 7.2 (uname shows
Linux 2.4.20).  System idles at 80% CPU free most of the time, until I hit a
cgi which drops the idle down to 0%, until the cgi finishes (as mentioned
earlier, 25-30seconds later) and the system goes back to 80% idle.  No swap
is being used.

I've done the following optimizations: 

Placed my critical files on ramdisk.  They are: 

-rwxr-xr-x    1 nagios   nagios        755 Apr  4 15:43 contactgroups.cfg 
-rwxr-xr-x    1 nagios   nagios       2822 Apr  4 15:43 contacts.cfg 
-rwxr-xr-x    1 nagios   nagios      14999 Apr  7 09:43 hostextinfo.cfg 
-rwxr-xr-x    1 nagios   nagios       1565 Apr  4 15:43 hostgroups.cfg 
-rwxr-xr-x    1 nagios   nagios      26585 Apr  4 15:43 hosts.cfg 
-rwxr-xr-x    1 nagios   nagios        536 Apr  4 15:43 hosts-uses.cfg 
drwxr-xr-x    2 nagios   nagios      12288 Apr  3 16:23 lost+found 
-rwxr-xr-x    1 nagios   nagios       3092 Apr  4 15:43 misccommands.cfg 
-rwxr-xr-x    1 nagios   nagios    1987817 Apr  4 15:43 serviceextinfo.cfg 
-rwxr-xr-x    1 nagios   nagios    1696675 Apr  4 15:43 services.cfg 
-rwxr-xr-x    1 nagios   nagios       3941 Apr  4 15:43 services-uses.cfg 
-rw-r--r--    1 nagios   nagiocmd   759981 Apr  7 09:50 status.log 
-rw-rw-r--    1 nagios   nagios     209360 Apr  7 09:43 status.sav 
-rwxr-xr-x    1 nagios   nagios       1112 Apr  4 15:43 timeperiods.cfg 

retention_update_interval=15 

aggregate_status_updates=15 

My nagios stats are as follows: 

Check Execution Time: 0 / 7 / 0.052 sec 
Check Latency: 0 / 14 / 0.605 sec 
# Active Checks: 3404 
# Passive Checks: 334 
I've done everything that I could implement in the "Tuning Nagios For
Maximum Performance" section. 
At one stage I even nfs mounted the nagios directory to another machine from
which I let my clients access the cgi's.  Sharing CPU this way worked fine,
meaning that whenever the web interface becomes too slow, I'll just add
another server in my nagios farm.  The only drawback is that the clients
can't write to the nagios.cmd file accross the nfs mount.  Would have been a
nice feature if it did work.  Which raises the next question.  Nagios is a
distributed NMS system, how about making it a distributed client interface
system, if you follow what I mean?  How can I get this done?

Is there anything else I can do to get the response time of the cgi's
better?  Is this a hardware or software issue? 

Any suggestions will be highly appreciated. 

Thanx 

fred 



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
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