Nagios 2.0 performance

[Peter McAlpine]

On Sat, Sep 11, 2004 at 09:37:32AM -0500, Marc Powell wrote:
> > -----Original Message-----
> > From: Peter McAlpine <peter at aoeu.ca>
> 
> > I've been reading this thread and appreciate all the tips everyone has
> > to offer, but the time it takes the cgi's to load is obviously due to
> > parsing the log file for each execution... unfortunately:
> > *Parsing the log file each time status.cgi runs is just plain silly*
> 
> I would hardly use the word obviously. What evidence do you have to back
> this assertion? What do you mean by 'parsing'? The status file on my
> system is just over 900k and clearly delimited, hardly a challenging
> file to 'parse'. If you think that nagios is parsing nagios.log each
> time you should do some more research. I'm not a coder but I do have
> years of experience with Nagios and tend to lean toward the list
> traversals (which is really the parsing) as a big performance hit as has
> been discussed here recently and in the past. There have been very
> significant performance improvements in that regard in 2.0.

You are correct, I should have included parsing the configs in my
assertion. I simply am trying to make the point that the cgi's are going 
over the exact same data 95% of the time. Configs, host/service status 
that hasn't changed since the last cgi execution... in most cases the
status.cgi output will not change much in the span of 90 seconds,
IMHO.

> > Status should be stored within nagios, and the cgi's should query
> > nagios (not the log file) for status.
> 
> And how would you recommend this inter-process communication happen? I'm
> sure any reasonable suggestion would be duly considered. You might also
> want to present evidence to back your conclusion that this really is the
> issue and why your solution would be better.

Since you asked...
I was thinking along the same lines as the shared memory suggestion
made in another post. I figure the bulk of the cgi code could be moved
into the nagios process, and simply have the cgi's query some
port or socket for this status.

> > OR
> > Status should be stored in a database.
> 
> Nagios <= 1.2 can store status data in a database and the CGI's can read
> it from there (I believe even Netsaint could). As a user with a fairly
> large installation (2674 services on 1645 hosts), I can tell you that
> there is little difference between nagios loading status data from a
> flat file versus a database (pgsql in my case). In fact, flat file seems
> to be just a smidge quicker in my installation (I use both methods). I'm
> presuming that you haven't even tested your theory given that you didn't
> know Nagios could do this already.

Yes, I knew that Nagios <= 1.2 can store the status in a database.
However 1 minute you say, "Nagios <= 1.2 supports databases" and the next 
you say, "Nagios 2.0+ cgi's are much faster"... I've used both, and
find the cgi generation times to be unsatisfactory regardless of which
one I use.

Storing status in a database has the potential to be _much_ faster
than storing it in a flat file. If you receive results suggesting
otherwise it is due to nagios' code, not the database's. Ethan may be 
a great coder, but I can guarentee that mysql coders have put much 
more thought into "How can we access stored data quickly?".

> 
> > If supporting multiple databases is a problem:
> > -Say "too bad, only foosql is supported" (mysql runs on MsWindows btw)
> > -Use something like ODBC to make the database more portable.
> 
> The path has already been chosen. Nagios and the CGI's will use flat
> files for data storage. That appears to work best for Ethan and the
> program after all is written by him, for him and we just benefit from
> it. Users are free to use the event broker daemon in 2.0 to store copies
> of the data in whatever storage mechanism they prefer but the Nagios
> will always use flat files.

This is not an argument, and it concerns me when I hear this sort of
comment: "We have decided now deal with it".

-Peter 
> 
> --
> Marc
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://www.monitoring-lists.org/archive/users/attachments/20040911/331f987e/attachment.sig>