habe gestern auf die 17.06. aktualisiert. Heute ist mir nun anhand der Grafik im Commander aufgefallen, dass die CPU-Last in regelmässigen Abständen immer wieder ohne ersichtlichen Grunde Lastspitzen erreicht.
Leider ist die Grafik wenig hilfreich, weil die Achsen keinerlei Beschriftung tragen, d.h. ich weiß überhaupt nicht, wie hoch die Last war und wann die Last so hoch war. Hilfreich wäre hier eine etwas detailliertere Darstellung. Die PRTG-Netzwerk-Monitoring-Lösung hat das beispielsweise so gelöst, dass die Grafiken sich unterteilen in letzte Std, letzten 2 Tage, letzten 30 Tage und man dann bei Klick auf eine der Grafiken eine Detailansicht bekommt, woher die Auslastung stammt. So etwas könnte ich mir in der Pascom auch gut vorstellen.
Was will mir diese Grafik sagen ?
BTW: Pascom Classic mit 5 Benutzern auf einer Mini-Appliance, die sollte eigentlich vor sich hin dümpeln
diese Sägezahn last hängt mit den cronjobs zusammen und hat sich in Version X eingeschlichen. Hier wird noch analysiert warum genau, jedoch hatte ich noch auf keiner Anlage diesbezüglich Probleme feststellen können (weder MIni Appliance noch Callcenteranwendungen).
Bezüglich der Skala kann ich zumindest behilflich sein, es werden die letzten 24h angezeigt, also links vor 24h, Mitte vor 12h usw.
richtige Probleme hatte ich bisher auch nicht. Auffällig war halt bisher nur ein Fall, wo plötzlich mehrere Telefone ohne Funktion waren (verteilt über die gesamte Netzwerk-Infrastruktur). Dazu habe ich eine Uhrzeit gehabt und hier hätte die CPU-Auslastung eine erste Anlaufstelle sein können.
verstehe aber die CPU Last ist hierfür seltenst verantwortlich. Wenn die CPU zu sehr ausgelastet ist, merkt es der XMPP Server meist als erstes, wenn also in der Zeit leute mit dem Client beispielsweise telefonieren konnten, lag es vermutlich nicht an der cpu. Ich vermute mal im Asterisk Log wird man zu dieser Zeit sehen können, das die Peers unreachable waren, ich vermute hier eher das Problem am Netzwerk selbst, den Diensten der pascom selbst (sehr unwarhscheinlich ) oder der virtualisierungsumgebung, weniger an den zu knappen resourcen der VM oder physikalischen Maschine. Außer der CPU erholen sich Resourcne Probleme selten von selbst ohne manuellen Neustart.
Ich hoffe natürlich das der Ausfall ein Einzelfall war und sich nicht häuft.
?
) oder der virtualisierungsumgebung, weniger an den zu knappen resourcen der VM oder physikalischen Maschine. Außer der CPU erholen sich Resourcne Probleme selten von selbst ohne manuellen Neustart.