Cronjob Bug in Magento 2.2.x führt zu hoher CPU-Auslastung

In den zurückliegenden Monaten ist aus dem Einsatz der Magento Versionen 2.2.0, 2.2.1 und 2.2.2 immer wieder von verwandten Fehlerbildern berichtet worden: CPU und RAM auf dem Server werden durch eine schnell wachsende Zahl von Cronjobs stark, bisweilen voll ausgelastet. Offenbar hat Magento in vielen Fällen Probleme mit dem Löschen von abgeschlossenen Jobs und blockiert damit zunehmend Systemressourcen. Wir erklären, was da schiefläuft und was man dagegen tun kann.

Worin besteht das Cronjob-Problem in Magento 2.2.x?

In letzter Zeit gibt es immer wieder Bug-Reports zu Problemen mit Cronjobs in Magento 2.2.0, 2.2.1 und 2.2.2. Die Betroffenen klagen über massive Auslastung des Prozessors durch MySQL, während der Arbeitsspeicher gleichzeitig durch zahlreiche PHP-Prozesse blockiert wird. Der Blick auf die Speicherbelegung und in die Crontab zeigt dabei: Derart beschäftigt und ausgebremst werden die Server durch eine große und schnell wachsende Zahl von eigentlich bereits bearbeiteten Cronjobs, die fälschlicherweise nicht als abgeschlossen markiert und daher nicht gelöscht werden, weshalb sie sich immer weiter anhäufen. Auf GitHub findet sich die womöglich umfassendste Sammlung von entsprechenden Bug-Reports. Für diesen immer wieder auftretenden Fehler mit – gerade im Live-Betrieb – sehr unangenehmen Nebenwirkungen gibt es zwar noch keinen Patch, dafür aber immerhin einen wirksamen Workaround.

Was lässt sich dagegen tun?

Was also lässt sich unternehmen, wenn Magento 2.2.x sinnlos Cronjobs anhäuft? Eine echte Lösung des Problems kann nur durch ein Patch oder Update für Magento geliefert werden, denn ganz offensichtlich wurzelt dieses Problem tiefer und lässt sich nicht durch eine Einstellung hier und da beheben. Aber auf Magento Stack Exchange ist ein sehr pragmatischer Workaround für die Cronjob-Flut in Magento geliefert worden.

Um festzustellen, ob sich in der eigenen Crontab in der beschriebenen Weise veraltete Cronjobs ansammeln, genügt eine einfache Abfrage:

select count(*) from cron_schedule;

Schnelle Abhilfe für den Augenblick schafft dann das einmalige Löschen aller veralteten Einträge aus der Crontab:

delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 day);

Das entlastet den Server umgehend. Aber danach wäre es natürlich nur eine Frage der Zeit, bis das Problem wieder auftritt und das System erneut ausbremst. Daher sollte ein Cronjob eingerichtet werden, der dafür sorgt, dass die sich ansammelnden Altlasten von Zeit zu Zeit immer wieder aus der Crontab entfernt werden:

* */8 * * * <path_to_mysql_binary_dir>/mysql -u<sql_user> -p'<sql_user_pass>' <database_name> -e "delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 day)";

Im durch Sternchen („*“) markierten Bereich kann festgelegt werden, in welcher Frequenz der Job ausgeführt werden soll. Erfahrungsgemäß genügt hier eine Ausführung in 24 Stunden völlig. Zudem müssen die entsprechenden Daten für die in spitzen Klammern stehenden Platzhalter eingetragen werden. Da für <sql_user_pass> das SQL-Passwort eingetragen wird, ist dieses Vorgehen auf einem Shared Server ausdrücklich keine geeignete Lösung, da sonst auch jeder andere Nutzer Zugriff auf die Datenbank erhalten könnte.