Nagios 2.0 performance

[Ben]

I'm in a similar boat. Nagios 2 is a vast improvement over the list 
traversals of 1.x, but it's still pretty bad, even when keeping files on a 
ram disk. 

>From my profiling, it appears almost all time is spent reading the status. 
Like you say, it seems like this should be able to be cached. I was hoping 
that's what the database option would do, but it seems nagios doesn't 
exactly use a database to its full potential.... instead, it just mimics 
the same behavior as when using flatfiles.

When I ever get some time (haha), I was planning on looking into the
codebase more and trying to decide if I should impliment a scheme with
shared memory (so that would stay persistant between cgi runs), or a more
intelligent usage of the database.... say, maybe, using materialized
views. If anybody else has any suggestions on which path to take, I'm all 
ears....

On Wed, 8 Sep 2004, Robert Drake wrote:

> I've got a nagios 2.0 server with 3329 hosts and 4360 services being
> monitored.  For the most part, the monitoring runs ok (other than using
> alot of memory which is my own fault for not doing distributed
> monitoring yet)
> 
> But my users are complaining about web page loading speeds so I started
> doing some digging to try to figure out why.  
> 
> From what I understand, the webpage just reads the status.log file each
> time it loads right?  If this is the case, can you make a new option
> that caches the current status in a running nagios daemon, then the
> webpage cgi's would just query the daemon for current status.  
> 
> Another option that I thought about doing myself was to run a cronjob
> every 5 minutes to grab the current webpage and save it to "status.html"
> then point all my users to status.html.  That would make things go
> faster, but it means everyone shows up as the same user (maybe wouldn't
> be a problem, I dunno)
> 
> The other thing I wonder about is the new status.log format.  It's more
> extensible because everything is plaintext and you can add more lines,
> but since each status entry takes about 20 lines instead of one, it
> seems like the parsing time would be longer per entry (so that might be
> slowing down the webpages)
> 
> I'm sure some of the other changes we're doing soon will speed things up
> a bit (distributed polling, adding more memory, etc).  Just wondering if
> other people have similar problems and if it's something that needs a
> fix.
> 
> Thanks,
> Robert
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> 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
> 




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
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