WEB-Interface performance

Marcel Mitsuto Fucatu Sugano msugano at uolinc.com
Thu Oct 6 16:45:11 CEST 2005


Hi list, Rob, Moshe, Rafael...

Thank you all for your time and leading help! ;)

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 will try this right now, but, as you stated below, the status.dat file
is around 13MB of size and over 500k lines, and I agree with you that
recompiling shouldn't improve the performance in a way we could see the
status.cgi computing faster. But I will recompile anyway, just for the
minimum improve I can get on performance.
> 
> 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... 
We are doing that way, people who are watching the service problems page
just browse the page with the critical alerts, and sorted by duration of
the alarm. Again I think that the status.cgi will read all the file,
because response time isn't lower than loading all problems in one page.
> 
> 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)...
That is a good idea. I also wondered if it would be possible to setup
syslog-ng and send only the information I want to another server, which
displays only the critical problems, this way the status.dat should be
smaller. Well, there should exists lots of solutions to this kind of
problem, and we will be trying something like this soon.
> 
> Hope this helps
> rob.

Again, thank you, it helped.
-- 
Marcel Mitsuto Fucatu Sugano <msugano at uolinc.com>
Universo Online S.A.


-------------------------------------------------------
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