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.friedr...@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@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