[RFC] Data from file to sqlite3

Yann Jouanin yann.jouanin.list at intelunix.fr
Tue Jan 27 09:52:02 CET 2009


I agree about the modular backend would be the best solution.

I also agree about the fact mysql server could decrease performance, this was the reason I thought using sqlite could be a best idea.
Things is that the way Nagios reads status (reading everything even when you apply a filter) drive it really slow (as an example I have more than 7000 services on a server and need more than 10seconds to get the page).

I may help you to create the modular backend if you want (and if this have a chance to be commited of course!)

Yann Jouanin

http://www.yannj.fr

-----Message d'origine-----
De : Thomas Guyot-Sionnest [mailto:dermoth at aei.ca] 
Envoyé : mardi 27 janvier 2009 09:36
À : Nagios Developers List
Objet : Re: [Nagios-devel] [RFC] Data from file to sqlite3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20/01/09 08:37 AM, Christoph Maser wrote:
> Am Dienstag, den 20.01.2009, 10:41 +0100 schrieb Yann Jouanin:
>> Hello everyone,
>>
>>
>>
>> I am thinking about the way data are stored (status…) and how it
>> impacts performances.
>>
>> As an example, when there is a large number of services or hosts, CGIs
>> become really slow cause it read the whole files. One of my idea to
>> fix this problem would be to use a sqlite3 database instead of flat
>> files.
>>
>>
>>
>> What are your feelings about that (performances, licence…)
> 
> Yann if i understood things right, the future plan is to get rid of the
> current CGIs and dump all information via ndoutils in a (MySQL)-database
> which will be then used by a yet to be wrtitten PHP frontend.

I like the idea of allowing a MySQL backend, but IMHO the it's overkill
for most systems and will cause more troubles than what it's trying to
solve. More importantly, badly tuned MySQL servers will be one more
performance bottleneck.

IMHO the backend should be modular. Nagios's architecture make it easy
to create multiple selectable data backends and I think the PHP web
interface should be as flexible.

I was thinking about it though and I CDB could be a nice match for a
faster data backend. For those who don't know CDB, it is a read-only
ultra-fast database written by D. J. Bernstein
(http://cr.yp.to/cdb.html). Given the way status.dat is written a
read-only replacement makes a good fit and PHP has native support for
reading these databases trough dba_open.

I could try coding it for the development branch if there's any chances
a working implementation gets accepted for a future release. On the php
side though I don't have much coding experience, so while I can most
likely get CDP working I'm not sure how to design a modular backend.

- --
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJfsdw6dZ+Kt5BchYRAiLcAJ4g18ogwl6a3qu/hg9GlrggL9DZMACeLgWK
fcpWRMzZv/D3nSfdRIyUzrg=
=hCOR
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel


More information about the Developers mailing list