status.cgi very high cpu usage

Marc Powell marc at ena.com
Tue Feb 19 20:20:03 CET 2008



> -----Original Message-----
> From: nagios-users-bounces at lists.sourceforge.net [mailto:nagios-users-
> bounces at lists.sourceforge.net] On Behalf Of Justin Hitt
> Sent: Tuesday, February 19, 2008 9:15 AM
> To: Steve Kieu
> Cc: nagios-users at lists.sourceforge.net
> Subject: Re: [Nagios-users] status.cgi very high cpu usage
> 
> Steve,
> 
> On Feb 18, 2008 10:51 PM, Steve Kieu <msh.computing at gmail.com> wrote:
> > I have a problem with status.cgi taking up too much cpu so the page
is
> very
> > slow to  render. Is there any way to find out where the problem is?
> > We have about 650 services monitored. The output os nagios -s
command is
> 
> Many of the "Monitoring" reports don't work well at volume, I've been
> asking users to only use "Unhandled" reports.  You may get better
> response in Mozilla, but 'status.cgi' can kill Internet Explorer
> because of how it's loading everything in one large list.

This is a browser rendering issue, nothing to do with the nagios' speed
at reading and parsing its status file. To get the html to display
status for all 3800 of my services takes under 1.5 seconds --

$ time wget http://<redacted>/cgi-bin/status.cgi?host=all
--12:59:50--  http://<redacted>/cgi-bin/status.cgi?host=all
           => `status.cgi?host=all'
Resolving <redacted>
Connecting to <redacted>|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]

    [ <=>
] 4,540,227     23.92M/s             

12:59:51 (23.84 MB/s) - `status.cgi?host=all' saved [4540227]


real    0m1.364s
user    0m0.010s
sys     0m0.000s
$ wc -l status.cgi\?host\=all 
 128601 status.cgi?host=all

> 
> Nagios is at the point where it needs an SQL back end with a more
> modular look at how it stores site data.  Perhaps, rolling status up

Perhaps, but not for speed/performance reasons (outside of long-duration
archive reports), IMHO.

> into summary reports that are queried to create reports then go into
> host tables only when someone drills down into host information.

Isn't this already available? Status Summary, various links from
Tactical Overview, Service Problems, etc. 

> In production you'll want to be on a multi-core multi-threaded
> machine; 2 cores won't do it if you'll have more than one user in the
> system.  Until then, keep users in the "Unhandled" menus around
> "{Service,Host} Problems"

This is best from a workflow perspective but saying that you need to
have dual cores if you have more than one nagios user is a bit a dubious
statement. My own experience is that the above test used less than 3%
cpu for the duration of a 3.1Ghz Xeon cpu, even when viewed with a
browser. Granted it's not a vmware box but if vmware introduces that
significant of a performance impact, I'd abandon it without prejudice.

--
Marc

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/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





More information about the Users mailing list