On 12.02.2014 08:26, CHRISTOPHE M.R. BURNOTTE wrote:
Thanks a lot Michael!
Creating the index solved this problem. Before the index, it took about
90 mins to dump everything in the mysql. After the index creation: 60s
for the initial config dump and another 40s for the rest of the dumping.
Still too much. In Icinga 2 DB IDO there's a different approach applied
in current snapshot builds - by pre-selecting configuration object ids
and only updating/deleting them in case. Basically a diff of db objects
with config objects which is a) good for better performance b) required
for running ido an a failover cluster scenario re-using ids. You'll
probably should give it a shot soon-ish ;-)
[Note: That method is awfully hard to implement in 1.x code. 2.x is
fresh and re-designed from scratch, "only" the db schema is compatible.]
By the way, if this info might help you: I switched to Icinga 2 years
ago and was on nagios before, since 2007 (and all nagios&icinga logs are
kept since then).
The commenthistory table is only updated by core triggered events - the
logs themselves won't affect that. If you had imported that table from
the ndoutils database backend into the current idoutils backend, there's
probably much data around.
You might tune MySQL itself as well, or look for possible bottlenecks
(mysql tuning primer script for instance).
--
DI (FH) Michael Friedrich
michael.friedr...@gmail.com || icinga open source monitoring
https://twitter.com/dnsmichi || lead core developer
dnsmi...@jabber.ccc.de || https://www.icinga.org/team
irc.freenode.net/icinga || dnsmichi
_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
