WEB-Interface performance

Andreas Ericsson ae at op5.se
Sat Oct 8 10:08:16 CEST 2005


Marcel Mitsuto Fucatu Sugano wrote:
> Hello again,
> 
> On Thu, 2005-10-06 at 11:16 +0100, Rob Moss wrote:
> 
>>Yeah, there are some CFLAGS you could be using to optmise your build..
>>I am assuming that you have a recent version of GCC, and that your P4
>>HT cpu is shown as having two logical CPU's
>>
>>Try rebuilding with the following command:
>>
>>cd  nagios-2.0b4
>>CC=gcc CFLAGS="-mtune=i686 -O3 -pipe -march=i686 -funroll-loops
>>-ffast-math" \
>>    ./configure --prefix=/usr/local/nagios ...... [rest of nagios
>>configure commands]
> 
> 
> I've tried this with no luck, having an error message displaying that
> -ffast-math wasn't a recognized flag, with gcc-3.3.5. This was the
> second try to handle the cgi's performance. The first thing we tryied,
> was setting up a tmpfs mountpoint at /opt/nagios/var/tmpfs, and pointed
> nagios to write the status file there, but again with some errors that
> was a little weird, the cgi begins to ending prematurely (apache
> errorlog), and displaying "500 internal server error". This happened to
> 10% of the check_http running to test it :), and the response time
> didn't get too much of a performace improvement as well.
> 
> I don't think this could be Virtual Machine OS's fault, so the problem
> might be with the status.cgi reading the tmpfs, but i can't tell for
> sure, as we tried this setup yesterday. Is there anyone here who made
> it? (status.dat been written in a tmpfs mountpoint?)
> 
>>The main problem is that you have thousands of hosts, and thousands of
>>services to read in every time you run status.cgi.   No matter how
>>efficient the program is, reading in and displaying that much data is
>>going to take a while, and running the same program 15 times
>>simultaneously is going to affect your performance as you see here.
>>How many lines is the status.dat file?  I only have a few hundred
>>hosts and services, and the file is 23,000 lines or so, half a meg on
>>disk.. I would imagine yours is closer to about 50mb and closer to a
>>million lines.
>>Some alternatives might be updating the Nagios sidebar so that it
>>doesn't display ALL hosts by default, maybe just a smaller hostgroup..
>>(although i suspect the status.cgi needs to read in the whole file) Or
>>replacing the standard nagios CGI's with something that is more geared
>>towards handling hundreds of thousands of hosts/services... 
> 
> 
> I agree with you, and i've been reading the nagios-devel list, and saw
> that the CGI is a problem to a lot of people who need to maintain some
> BIG nagios configuration, over 10k services. I also watch that there is
> a patch to improve the performance of the CGIs, but I couldn't find it
> anywhere.
> 

Browse the list archives. Search for "binary cgi" and stuff like that. I 
haven't tested it myself, but according to the author of the patch he 
noticed a performance increase of factor 30. I had objections to the 
patch because the code was definitely non-trivial and included quite a 
bit of black pointer magic. In short, I didn't like it because it would 
be hard to maintain and wouldn't work too well in certain circumstances.

>>Or perhaps you could have a separate display server, a webserver
>>running the cgi's which reads in the nagios status.dat file over the
>>network from the nagios server, and does all the processing away from
>>the nagios collector.. This would move processing off of the nagios
>>collector.. You could use rsync to keep the two files in sync, keep a
>>duplicate on the display server on a local disk (or a tmpfs memory
>>based filesystem for extra speed)...
> 
> 
> We are studying the mysql backend, but my first shot was the tmpfs, and
> the recompilation with those flags you mentioned. Hope that exists
> something easier than setup a mysql backend, 

nagios-db with postgresql is most likely the fastest option available 
today. We're planning on writing a new gui that will, hopefully, be more 
complete than the current nagios-db one and which will also use a 
database backend.

I'll let the list know when there's something to download.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
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