Nagios 2.0 performance
Ben
bench at silentmedia.com
Wed Sep 8 21:58:17 CEST 2004
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
More information about the Users
mailing list