Hohe Auslastung des Systems täglich zwischen ca. 3 und 8 Uhr

Hallo,

Ich habe im Forum schon nach einer Lösung gesucht, bin aber leider nicht fündig geworden.
Wir nutzen UCS mit Zarafa als Mailserver. In letzter Zeit können morgens keine Mails empfangen oder verschickt werden und unser postqueue gerne mal voll.
Das Problem haben wir seit einem Update (inklusive Zarafa Update auf 7.2) am 12.03. Seit dem haben wir jede Nacht/Morgen eine sehr hohe Auslastung unseres Systems. Auch ein Einloggen über die Konsole läuft sehr träge (wenn überhaupt). Meist beruhigt sich das System und ab 8 Uhr sind alle Dienste wieder verfügbar, zu häufig war aber auch ein Neustart notwendig um das System wieder nutzen zu können.

Die Top Prozesse sind dann in der Regel immer python und mysql.
Wir haben anfangs vermutet, dass die Zarafa Datenbank über Nacht umgebaut wird und die Last mit der Zeit nachlässt (so sah es jedenfalls anfangs aus), aber leider ist das wohl doch nicht der Fall.

Weiß jemand ob dieses Verhalten gewollt ist und was man ggf. dagegen machen kann?
Wenn noch weitere Infos hilfreich wären, bitte sagen in welche log ich schauen soll. Ich fühle mich in der Linux Welt noch nicht so ganz zu Hause und der Kollege der das System am besten kennt ist im Urlaub.

Wir nutzen UCS-Version 4.1-1 errata137 (Vahr) / UMC-Version 8.0.28-13.917.201603221221 mit Zarafa 7.2.1-51838

Gruß
TCT

Moin,

unsere Kunden mit Zarafa auf UCS haben solche Probleme nicht. Gewollt ist es bestimmt nicht.

Schauen Sie doch mal nach, welches Python-Script genau diese Probleme verursacht. Das würde Anhaltspunkte geben.

Gruß,
mosu

Sonntag war das System fast nicht ansprechbar. Zwischen 1 und 15 Uhr eine extrem hohe Auslastung. Ich habe dann über die Konsole (univention-management-console war nicht ansprechbar) einen reboot Befehl abgesetzt und das System lief 1:30h später immer noch. Danach habe ich einen Kaltstart gemacht und das System verhielt sich danach erst mal wieder wie gewünscht.
Montagmorgen konnten dann wieder keine Mails verschickt werden, da das System wieder nicht in einer angemessenen Zeit reagiert. Also wieder reboot, diesmal ging der Befehl wenigstens.
Heute war das System am Morgen zwar sehr träge lief dann aber nach einer Zeit wieder normal.

Ich habe jetzt die letzten Tage mal genauer nachgesehen. Ich hoffe das hilft um das Problem einzukreisen.

Wir sind für jede Hilfe dankbar.

Gruß
TCT

Moin,

den einzelnen Prozesse, die in den Top-Screenshots zu sehen sind, ist gemein, dass sie alle schlecht darauf reagieren, wenn sie keine genügende I/O-Bandbreite zur Verfügung haben. zarafa-search ist z.B. auch zu sehen.

Was Sie in dem Moment untersuchen sollten, in dem die hohe Last existiert:

[ul][li]Swappt die Maschine gerade? (»free«, »vmstat«, …)[/li]
[li]Welche Prozesse erzeugen wie viel I/O-Last? Dazu das Tool »iotop« nutzen, das per default nicht installiert ist und unbedingt vorher installiert werden sollte.[/li][/ul]

Was Sie jetzt im Vorfeld untersuchen sollten:

[ul][li]Wie hoch ist der I/O-Durchsatz, den Ihr System generell momentan schafft? Dazu Tools wie »iozone« oder »bonnie« nutzen.[/li]
[li]Wie verhält sich das System, wenn Sie bewusst I/O-Last erzeugen? Ist’s dann genau so schlimm?[/li][/ul]

Meine Vermutung ist, dass der Zarafa-Suchdienst in der Nacht eine Neuindizierung durchführt und das Verhalten dadurch anstößt. Jetzt kommt das große aber: aber wenn der Server so schlecht darauf reagiert, dann passt die Hardwaredimensionierung nicht zur Aufgabe. Ganz schlimm reagiert Linux vor allem, wenn es swappen muss; u.a. ziemlich genau so, wie Sie es beschreiben: keine Reaktion, auch nach langer Zeit nicht, dauerhaft Festplattenaktivität. In dem Fall wäre ganz klar zu wenig Hauptspeicher vorhanden.

Gruß,
mosu

“sysstat” kann ganz hervorragend Statistiken sammeln, u.a. auch über IO-Last. Wenn Sie es über Nacht laufen lassen, bekommen sie vielleicht heraus was das Problem verursacht.

Grüße
Daniel Tröder

Wir haben jetzt anfang der Woche eine virtuelle Maschine, die auf dem gleichen Server lief, auf ein anderes System ausgelagert. Seit dem hatten wir keine Problme mehr und die Systemauslastung sieht jetzt wieder gut aus.
Auch wenn ich es nicht für möglich gehalten habe scheint, wie hier vermutet, die Hardwaredimensionierung nicht mehr zur Aufgabe zu passen.

Vielen Dank für die Hilfe, dass die Hardwaredimensionierung nicht zur Aufgabe passen würde hätte ich, nachdem das System ein Jahr lang problemlos lief, nie in Betracht gezogen. Aber vielleicht hatt sich ja irgendwo anders etwas verändert und das Verhalten dann bei der UCS VM ausgelöst.

Gruß
TCT