web 2.0

oom-killer vs. mysqld

Online Solution Int - Webentwicklung

Bereits bei temporären Lasten und knappen Arbeitsspeicher-Ressourcen wird oom-killer aktiv.
Per cronjob können ghosts oder abgelaufene Prozesse beseitigt werden. Wer sichergestellt hat, dass Webserver-Dienste wie apache2 und mysql optimal konfiguriert sind (nicht Standardkonfiguration des Systems, sondern Anpassung für CPU-Cores und verfügbarer Zwischenspeicher), bleibt davon nicht verschont, wenn beispielsweise Indizierungsdienste oder Aufräum-Prozesse kurzfristig für Engpässe sorgen. Trotz des ausgereiften Scoring-Verfahrens, wonach der oom-killer sein Opfer wählt, kommt es hier zu unerwünschtem Verhalten.

Zuerst versucht sich das System, durch Nutzung des Swap-Bereichs Zeit zu erkaufen. Sämtliche Dienste stört das nicht weiter und sie laufen weiter als wären sie im RAM.

In dem Fall ist der oom-killer unumgänglich und fängt erfahrungsgemäß an, mysqld oder apache2 Prozesse zu beenden. apache2 children erholen sich sehr schnell und führen i.d.R. nicht zu Ausfällen. Jedoch ist das Beenden von mysqld meist mit negativen Konsequenzen verbunden und beeinträchtigt die übrigen Webdienste.
Um mit dem oom-killer zu vereinbaren, dass mysqld aktiv bleiben muss, reicht diese Anweisung aus.

pgrep mysqld | while read PID; do echo -1000 > /proc/$PID/oom_score_adj; done

Ebenso bietet es sich an, auch SSH auf diese Weise zu “schützen”.

pgrep sshd | while read PID; do echo -1000 > /proc/$PID/oom_score_adj; done

apache2 sollte nicht verschont werden.

Die Quelle des Problems wird dadurch nicht beseitigt und ohne individuelle Konfiguration der Dienste für die gegebene CPU/RAM-Ausstattung ist diese Vorgehensweise nicht empfehlenswert.

Leave a Reply