Compariing performances.

[Alessandro Ren]

    The ndoutils were not running on Fedora and I catch a bug that has 
already been fixed in 1.3.1.
    Yes, it is NDOUTILS and yes, it is resource hungry this fella.
    I've already patched nagios my self to write log status change 
information directly to mysql, but the broker is more complete, as it 
imports all the configurations into the DB.
    As Nagios 3 will have its interface problably based on the database, 
it would be nice to try and boost performance on the broker, as it will 
be integrated into nagios 3.0.
    Thanks Andreas, and indeed it is Friday. :)

    []s.
   

Andreas Ericsson wrote:
> 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).
>

-- 
__________________________________________________
*Alessandro Ren*
	/*OpServices*/
/*Luciana de Abreu, 471 - Sala 403*/
/*Porto Alegre, RS - CEP 90570-060*/

*(*   phone 55(51)3061-3588
*4*    fax 55(51)3061-3588
	*Q*   mobile 55(51)8151-8212
*:*   email alessandro.ren at opservices.com.br 
<mailto:%22alessandro.ren at opservices.com.br%22>

__________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20060324/8d2c0580/attachment.html>