bei mir dauert das aktivieren von Änderungen extrem lange (aktuelle Version ist CEE 2.0.0p8). Von Ursprünglich 4 - 10 Sekunden sind wir jetzt zwischen 70 und 90 Sekunden (in CEE 2.0.0.p6).
Hier ein “schnelles” reload
–
Time needed [cmc_all_hosts]: 72.86 sec
Time needed [cmc_groups]: 0.00 sec
Time needed [cmc_groups]: 0.00 sec
Time needed [cmc_groups]: 0.00 sec
Time needed [cmc_stringlist]: 0.00 sec
Time needed [cmc_contactlists]: 0.00 sec
–
Der Server hat aktuell 24 vCPUs und 56GB RAM. Die Auslastung ist nicht außergewöhnlich hoch (CPU/RAM). Bei einem cmk –R sieht man, dass ab und zu ein Kern für kurze Zeit auf 100% geht. Woran kann das liegen? Wo kann ich nachsehen?
Hallo,
bitte Details zum Betriebssystem und zur Hardware bitte.
Was wurde in letzter Zeit geändert.
Wieviele Sites laufen auf dem System oder läuft alles in einer Site?
Gruß
Hallo,
den Debug-Tip hast du ja schon bekommen.
Schau auf dem ESX Host mittels Vsphere mal an ob sie Überwachung Probleme mit der CPU Last oder den Platten meldet.
Wurden neue VMs in Betrieb genommen?
Gruß
Das sehe ich bei einem Kunden auch (und auch schon mit checkmk 1.6 und cmc).
Die Entwickler haben da noch keinen guten Ansatz. Evtl hat es etwas mit der Parallelisierung der Konfigurationserstellung zu tun. Diese lässt sich in den global Settings einstellen (“Parallelize core config creation”).
Hallo,
dann solltest du feedback anschreiben.
Ggf. hat München ja Interesse sich wenn möglich mal aufzuschalten.
Deine DNS Auflösung ist schnell und stabil?
Gruß
Ralf
Ich habe nicht so breite Erfahrung mit Checkmk, aber ich kenne mein Linux und vSphere. Kann es also sein, dass einfach die Festplatten nicht hinterher kommen? Treten ähnliche Probleme vielleicht auf anderen Systemen im gleichen Datastore auf? Oder kannst du das ausschließen?
Haben wir auch, 5x multisite.
Sehen zusätzlich dass checkmk-agents auf virtuellen maschinen aller Typen sporadisch hängen bleiben, darauf schieb ich das (pidof ‘tr’) ist ein Indiz dafür.
Werden aktuell nach 45 Minuten mittels local check abgeschossen.
Via feedback berichtet, jedoch “kein feedback :-)”
Dann scheints ja offensichtlich was anderes zu sein. Die Hosts bei dehnen er “hängt” haben auch nix gemein oder? Also solche Sachen wie “keine IP” DNS Lookup notwendig oder ähnliches?
Hast du eventuell Satelliten im Einsatz? Wenn ja, kann die lange dauernde Aktivierung auch durch die Synchronisation einer grossen Datei im local Verzeichnis verursacht werden.
Das sollte keine Auswirkung haben bei einem “cmk -R” auf der Command Line. Im Web mit mehreren Instanzen ok dann siehst das ja bei den einzelnen Instanzen.
Wir haben seit einiger Zeit 6 Rules in der Konfig welche Services auf SQL Servern deaktivieren. Diese Rules haben mehrere 100 Einträge. Kann es daran liegen? Ein “do not apply” bei einer Regel habe ich schon bei einem Server probiert und hat keine Änderung gebracht. Wird eventuell trotzdem die Regel ausgewertet?
(Ich kann nicht sagen ob wir diese Rules nicht bereits vor dem Problem mit der langen Laufzeit hatten)
Dann scheints ja offensichtlich was anderes zu sein. Die Hosts bei dehnen er “hängt” haben auch nix gemein oder? Also solche Sachen wie “keine IP” DNS Lookup notwendig oder ähnliches?
Nein leider nicht. Es sind immer unterschiedliche hosts.