<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.6.2">
</HEAD>
<BODY>
Hello again,<BR>
<!--+GtkHTML:<DATA class="ClueFlow" key="orig" value="0">--><BR>
On Thu, 2005-10-06 at 11:16 +0100, Rob Moss wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
    <!--+GtkHTML:<DATA class="ClueFlow" key="orig" value="1">--><FONT COLOR="#000000">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</FONT><BR>
    <!--+GtkHTML:<DATA class="ClueFlow" key="orig" value="1">--><BR>
    <!--+GtkHTML:<DATA class="ClueFlow" key="orig" value="1">--><FONT COLOR="#000000">Try rebuilding with the following command:</FONT><BR>
    <!--+GtkHTML:<DATA class="ClueFlow" key="orig" value="1">--><BR>
    <!--+GtkHTML:<DATA class="ClueFlow" key="orig" value="1">--><FONT COLOR="#000000">cd  nagios-2.0b4</FONT><BR>
    <!--+GtkHTML:<DATA class="ClueFlow" key="orig" value="1">--><FONT COLOR="#000000">CC=gcc CFLAGS="-mtune=i686 -O3 -pipe -march=i686 -funroll-loops -ffast-math" \</FONT><BR>
    <!--+GtkHTML:<DATA class="ClueFlow" key="orig" value="1">--><FONT COLOR="#000000">    ./configure --prefix=/usr/local/nagios ...... [rest of nagios configure commands]</FONT><BR>
</BLOCKQUOTE>
<BR>
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.<BR>
<BR>
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?)<BR>
<BLOCKQUOTE TYPE=CITE>
    <!--+GtkHTML:<DATA class="ClueFlow" key="orig" value="1">--><BR>
    <!--+GtkHTML:<DATA class="ClueFlow" key="orig" value="1">--><FONT COLOR="#000000">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.</FONT><BR>
    <!--+GtkHTML:<DATA class="ClueFlow" key="orig" value="1">--><FONT COLOR="#000000">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... </FONT><BR>
</BLOCKQUOTE>
<BR>
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.<BR>
<BLOCKQUOTE TYPE=CITE>
    <!--+GtkHTML:<DATA class="ClueFlow" key="orig" value="1">--><BR>
    <!--+GtkHTML:<DATA class="ClueFlow" key="orig" value="1">--><FONT COLOR="#000000">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)...</FONT><BR>
</BLOCKQUOTE>
<BR>
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, <BR>
<!--+GtkHTML:<DATA class="ClueFlow" key="signature_name" value="uid:1123262566..1183..12@slackbox">--><!--+GtkHTML:<DATA class="ClueFlow" key="signature" value="1">--><TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<!--+GtkHTML:<DATA class="ClueFlow" clear="orig">-->-- <BR>
Marcel Mitsuto Fucatu Sugano <<A HREF="mailto:msugano@uolinc.com">msugano@uolinc.com</A>><BR>
Universo Online S.A.
</TD>
</TR>
</TABLE>
</BODY>
</HTML>