Compariing performances.

[Andreas Ericsson]

Alessandro Ren wrote:
> 
>    I've recently installed the broker in my nagios running in Fedora 
> Core 3 after having solved that null pointer bug

(Assuming you mean NULL pointer bug (nul is the end of a string, i.e. 
'\0', NULL is (void *)0 on any sane system) What bug is this? I haven't 
heard of it, and given the amount of modules (well, three, but I think 
that qualifies as "many" given the recentness of the broker interface).

> and I'd like to share 
> some performance information with the list to see if my server is 
> running as expected and exchange some code change idea to boost 
> performance.
>    Attached there are five graphs with informations from the system and 
> nagios it self.
>    My HW is a P4 2.8Mhz, Sata 80GB and 1GB of memory. This Nagios has 
> 2500 services beeing monitored, besides nagios is running with perfparse 
> and storing the data directly in the mysql database,


I assume you mean through NDO-utils here, since Nagios 2 can't store 
data directly to any database and 1.x doesn't have broker support. We've 
also experienced huge performance issues with ndo-utils. We're 
investigating further. Perhaps we'll be writing our own utility for 
storing to database (using loadfiles for history and UPDATE's for 
current state).

> we have also Nisca 
> collecting network statistics and it has already 20 milion records in 
> its database.
>    I'm worrying a little about the HW requirements for bigger setups 
> with the broker and what could we do to boost performance.


The main problem is that ndoutils does an asprintf(3) for each event 
that comes in (asprintf is very slow, but very convenient). Reading the 
glibc sources, this means that there's at least two malloc()'s and one 
free() for each event that carries a string (i.e. baaaad for performance).


>    I've changed the perfparse code a little so it does not save all the 
> performance data in on table, but it divides per host, each host has its 
> own table where all the performance data for all services are stored 
> there, so the tables are much smaller than one big table, I wonder if 
> this could not be done with the broker, for long term storage, some 
> tables can get very large.


I think the solution is to rotate the data to disk every once in a while 
and have a file-parser to use with data older than whatever the rotation 
interval is.


>    Just sharing some though with the list to exchange some ideas.
> 

Good man, that fella! (sorry, I'm a bit tipsy today, it being friday and 
all).

-- 
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 xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642