Resending as the mail server rejected this message. James
On 16 February 2015 at 16:09, James Nedila <[email protected]> wrote: > Hi Michael, > > > We are now in the process of moving to Icinga2 for the many performance >>> improvements, and have noticed that this table is getting updated with >>> every hostcheck/servicecheck. >>> >> >> *check tables are merely useless, disable them afteral. >> > > We use these tables quite heavily, and it is not reasonable to just > disable them. > They hold a lot of the historical data, which is more valuable to us than > just current state data. > > > >> >> >>> >>> I don't see a way to turn this off in Icinga2. >>> Will this be added to Icinga2 anytime soon? >>> >> >> I don't see any valid readon to do so. Database operations have gotten >> even better considering i2. >> >>> >>> Or is there another way to achieve the same effect? >>> >> >>> I've tried revoking the update privilege on that table, but Icinga2 >>> realizes there is a DB error, and it performs the whole DB reconnection >>> routine in response - which is not ideal. >>> >> >> What' s your point/issue? >> > > > My point is the DB is getting hit with with an extra customvariablestatus > update on every check result. > When we identify what the choke points are in the whole monitoring system, > it's always the DB when we scale up. > > Anything we can do to drop queries to the DB is a plus... especially when > we start loading up thousands of hosts and more service checks. > > We do not use customvariablestatus, as the custom variables are set at > server start time and we really don't care if they're updated after that. > > (A separate question I have is why Icinga is hitting the DB with a > BEGIN/COMMIT every second...) > > Thanks, > James > >
_______________________________________________ icinga-users mailing list [email protected] https://lists.icinga.org/mailman/listinfo/icinga-users
