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@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: ae@op5.se