ndoutils 1.4b7 vs 1.4b9

[Michael Friedrich]

Hi,

Carl Friend wrote:
>> Well I've sent a patch a few months ago to nagios-devel but iirc it's
>> only in CVS, not within a new beta release. An Icinga user pointed me to
>> that problem.
>>
>> http://markmail.org/message/jsolx6j6jl74aqpj
>> https://dev.icinga.org/issues/219
>>      
>     I caught one of those (the errant declaration) but missed the
> botched int vs. long problem.  Since I located the patch, I'll give
> things another go this evening if I get time.  Thanks!
>    

The int vs long problem is normally handled by the compiler, I just 
changed the way queries are being prepared and handled due to the fact 
that I wanted IDOUtils to support Postgresql and Oracle too in 
combination with Icinga Core and the new Icinga Web.
So this is a minor flaw, and not causing segfaults on NDOUtils - I just 
provided that patch too in order to resolve all issues. Sadly this did 
not reach the community yet, but it can be easily patched yourself - as 
you just did ;-)

>     I looked at the lists and didn't see the indices and constraints
> alluded to here.  Can you point them out, please.

Hmmm well we had several discussions on nagios-devel and some off-list 
too. And especially while developing on the Nagios fork, Icinga.

Basically it came up with the duplicated row issue on the servicechecks 
table which happened to affect systemcommands and timedevents too. It 
was a major bug in Icinga IDOUtils back in November 2009, which has been 
evaluated and fixed - also providing upgrade scripts for preventing data 
loss of existing installations. Postgresql and Oracle were not affected 
since their unique constraints are fulfilled within the WHERE clauses too.
Was quite an easy way to resolve that, but the discussion about NDOUtils 
having that bug too on the nagios-devel lists died silently in a 
proposed RFC and nothing happened since then.

http://www.mail-archive.com/nagios-users@lists.sourceforge.net/msg29949.html
http://markmail.org/message/uhpzyksg4dieiulh#query:[Nagios-devel]%20[RFC]%20-%20NDOUtils%20duplicate%20lines%20problem+page:1+mid:qnt2titl2px3cck2+state:results
http://markmail.org/message/kz56ajbcthumdx7r?q=[Nagios-devel]+NODutils:+Duplicate+lines+in+servicechecks+table+for+each+service+check&page=1&refer=lxmgqlihzdy4jbg2
http://markmail.org/message/lxmgqlihzdy4jbg2

The proposed way to fix that can be found in the Icinga Dev Tracker:

https://dev.icinga.org/issues/173
https://dev.icinga.org/issues/181
https://dev.icinga.org/issues/195
https://dev.icinga.org/issues/209

Considering the newly introduced BINARY select of rows within the 
objects table - as we discussed about case sensitive WHERE conditions - 
it comes to another performance issue. The binary comparison of two 
values might work in smaller environments and without the need of 
hitting quite high performance on queries. Since MySQL does not set the 
case sensitive collation to columns by default, the binary comparison 
was just a workaround to compare that bit by bit. The real solution 
would have been in changing the collation (thanks to William Preston, 
the binary selects are gone in IDOUtils 1.0.2)

The discussion is quite pro binary, but after my report, nothing else 
happened.

http://markmail.org/message/hga5hsaeo4pcl6fi?q=[Nagios-devel]+Case-insensitive+objects+in+NDOutils

You can follow the resolution here: https://dev.icinga.org/issues/361


> changes I applied to the database with the 1.4b9 update.  However,
> 1.4b9 *does* provide some additional indices that dramatically speed
> up certain maintenance operations, so I don't want to lose those.
>    

1.4b9 does not provide all of them in the mods file, some are still 
missing (https://dev.icinga.org/issues/228 and GIT repository). And the 
schema proposes MyISAM as DB engine, which is rather bad if you have 
some other cleaning scripts running (like Nagios XI proposes an external 
php cronjob cleaner next to the normal one - which is just lol). MyISAM 
enforces full table locks and if a DELETE interferes with an INSERT - 
holy shit, that will be fun for *domod and the core.
That's one of the reasons why Icinga IDOUtils insist on InnoDB as DB 
engine because the housekeeping has been extended into its own thread, 
not interfering with the normal INSERT/UPDATE procedure. InnoDB slows 
down an INSERT a bit, but the overall benefit of only having a row lock 
and cleaning old historical data parallel to getting new data is just 
wonderful. We had some reports that IDO2DB in comparison with NDO2DB 
runs ~30% faster...
But this patch is rather big and unified for Icinga IDOUtils, developed 
initially by Hendrik, tested by the team and finally reworked by myself 
catching up with the community in 1.0.1 - check the blog entries on 
www.icinga.org :)

There are some other bugfixes, and some feature rich enhancements, but 
regarding the more or less dead development and even more the behavior 
of Nagios Enterprises and its president cannot convince me to backport 
those patches onto the actual NDOUtils code. Sadly to say for the 
community, but well.


Anyways, if you consider patching those things yourself, consider Icinga 
with IDOUtils as an alternative too.

Kind regards,
Michael

PS: Sorry for mentioning Icinga and fork and so on. Since it catches up 
with the topic, I think it's worth to talk about that a bit with the 
Nagios community too.

-- 
DI (FH) Michael Friedrich
michael.friedrich at univie.ac.at
Tel: +43 1 4277 14359

Vienna University Computer Center
Universitaetsstrasse 7 A-1010 Vienna, Austria


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null