Sollten immer 2 der Standard-Cron laufen?

8

Meine Frage lautet: Sollten mehrere Magento-Cron: run -vvv- Prozesse immer ausgeführt werden und MySql ständig treffen.

Ich richte Magento 2.2.1 über Google Cloud ein und habe die 3 Standard-Cron-Jobs, die durch die 1-Klick-Installation von Magento bei Google vorinstalliert wurden.

*/1 * * * * /opt/bitnami/php/bin/php /opt/bitnami/apps/magento/htdocs/bin/magento cron:run -vvv 2>&1

*/1 * * * * /opt/bitnami/php/bin/php /opt/bitnami/apps/magento/htdocs/update/cron.php 2>&1

*/1 * * * * /opt/bitnami/php/bin/php /opt/bitnami/apps/magento/htdocs/bin/magento setup:cron:run -vvv 2>&1

Wenn man sich top -c ansieht, laufen immer 2 php.bin-Prozesse, die MySql ständig treffen und dazu führen, dass es ständig etwa 50% - 70% CPU verbraucht. Hier ist eine Momentaufnahme davon, wie es normalerweise aussieht.

 PID USER      PR  NI    VIRT    RES    SHR  S   %CPU   %MEM 
19327 mysql     20   0 3872884 332876  19172 S  60.8  3.4 332:42.45 /opt/bitnami/mysql/bin/mysqld.bin --defaults-file=/opt/bitnami/mysql/my.cnf --basedir=/opt/bitnami+
26458 bitnami   20   0  679516 476444  64492 S  24.6  4.9   0:24.85 /opt/bitnami/php/bin/php.bin /opt/bitnami/apps/magento/htdocs/bin/magento cron:run -vvv
26415 bitnami   20   0  677532 475672  64588 R  23.6  4.9   1:36.11 /opt/bitnami/php/bin/php.bin /opt/bitnami/apps/magento/htdocs/bin/magento cron:run -vvv

Ich habe auch die Cron so geändert, dass sie alle 5 Minuten ausgeführt werden, anstatt die Standardeinstellung jede Minute, aber das Verhalten bleibt gleich.

Meine letzte Änderung war das Wechseln aller 7 Minuten und 8 Minuten mit dem 2-Cron-Job: Führen Sie Jobs im Abstand von 3 und 4 Minuten aus, und damit wird jeweils nur 1 Cron-Job mit 30% - 40% CPU von MySQL ausgeführt.

Meine Website hat derzeit auch keinen Datenverkehr, da ich sie noch nicht gestartet habe. Ist dieses Verhalten bei Magento normal, da auf der Website nichts los ist? Ich lasse es 12 Stunden lang sitzen, ohne etwas zu tun, und wenn ich nach oben schaue, läuft der Cron immer noch und hämmert MySQL.

UPDATE: Es ist jetzt klar, dass das Problem nur der erste cron: run-Prozess ist, der Probleme verursacht. Ich habe das 2. und 3. Element auf jede Minute zurückgesetzt und das erste bei 8 Minuten belassen, und es gibt jeweils nur einen laufenden Cron: Run-Prozess. Aus dem Kommentar unten geht hervor, dass es sich um ein Problem mit Bitnami Magento-Installationen handeln könnte. Dies ist jedoch meine erste Erfahrung mit Magento. Daher weiß ich nicht, ob dies erwartet wird (ich hoffe wirklich, dass dies nicht der Fall ist).

magento2 database cron magento-2.2.1 Codesmaller
quelle
Ich habe ähnliche Probleme mit einer Bitnami-Installation. Bis jetzt kann ich nicht herausfinden, warum, aber wenn ich mir die CPU-Auslastung im Dashboard von GCE ansehe, kann ich sehen, dass sie vor fast 30 Tagen bei einigen Prozent der CPU begann. Jetzt habe ich das Maximum herausgeholt und 4 x RAM und 4 x Anzahl vCPUs hinzugefügt, um den Server am Leben zu erhalten. Anstelle von oben habe ich verwendet htop. Damit sehe ich, dass ich mehr als zehn Zeilen mit habe magento cron:run -vvv. Einige sind seit einigen Minuten live. Ich werde versuchen herauszufinden, warum der Cron nicht wie erwartet läuft.
user5198077
Ich habe das gleiche Verhalten, als ich den Cron alle 1 Minute auf den Standard gesetzt hatte. Ich habe es so geändert, dass es alle 7 und 8 Minuten ausgeführt wird, wie ich in meiner Frage beschrieben habe, und es erzeugt nur einen Prozess, aber es scheint immer noch viel zu viel zu tun. Klingt vielleicht nach einem Bitnami Magento Problem.
Codesmaller
Ja, der Wechsel zu alle 7 Minuten hat meinen Server glücklich gemacht. Ging von 300% + CPU-Auslastung und 8 GB RAM auf 40% (für einen von MySQL bezahlt) und 1,7 GB RAM. Wird untersuchen, wie ich die vollständige Protokollierung von Cron aktivieren kann.
user5198077
Außerdem ist -vvv die maximale ausführliche Protokollierung, sodass arg aus crontab entfernt werden kann.
Codesmaller
Ich habe mir das Disk Operations (I / O) -Diagramm angesehen. Wenn der Server "funktioniert", sind die Lesevorgänge nahe Null, während die Schreibvorgänge ziemlich hoch sind. Wenn der Server ausfällt (oder nicht mehr reagiert), passieren die Lesevorgänge die Schreibvorgänge. Vergleicht man meine nicht so gesunde 2.2.0 Magento Bitnami-Installation mit einer anderen BItnami-Installation (ich denke immer noch auf 2.1.6 oder 2.1.8), so ist das Lesen / Schreiben auf einem sehr niedrigen Niveau, weniger als 2, während für die nicht so- gesund (aber jetzt funktioniert) die Lesevorgänge sind unter 2, aber Schreibvorgänge gehen oft über 1000 hinaus! : O
user5198077

Antworten:

6

Stellen Sie zumindest eine vorübergehende Lösung für das Problem bereit, um zu vermeiden, dass Ihr MySQL-Server beschädigt wird. Git-Problem, das das Problem beschreibt

Zumindest ein Teil des Problems ist auf die Tabelle cron_schedule zurückzuführen. Ich würde empfehlen, ein zu machen, select count(*) from cron_schedule;und wenn das mehr als ein paar hundert zurückgibt, dann haben Sie das Problem. Für mich ergab diese Abfrage 208.046 auf einem Server, der erst seit einigen Wochen ausgeführt wird.

Wenn Sie das Problem haben, führen Sie diese Abfrage aus, um alles in dieser Tabelle mit Ausnahme der letzten Zeilen zu löschen delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour);

Führen Sie dann die Zählabfrage erneut aus und sie sollte niedriger sein. Meins ging von 208k auf 252.

Nachdem ich diese Abfrage ausgeführt habe, habe ich alle 3 Standard-Cron einmal pro Minute auf den Standard zurückgesetzt, und wie durch Zauberei werden alle 3 fast sofort ausgeführt. Soweit ich das beurteilen kann, wieder normal.

In der Github-Ausgabe schlägt ein anderer Benutzer vor, diese Abfrage zu crontab hinzuzufügen, um zu verhindern, dass die Tabelle erneut wächst. 

0 * * * * <path_to_mysql_bin_dir>/mysql <magento_db_name> -e "delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour)"

Die letzte Antwort des Magento-Teams zu diesem Problem war im September, dass sie das Problem nicht reproduzieren können, aber eine Reihe von Benutzern haben darauf hingewiesen, dass sie dasselbe erleben, einschließlich mir. Hoffentlich beheben sie das, damit dieser Hack entfernt werden kann.

BEARBEITEN: Um diesen Befehl auf der Crontab zu verwenden, müssen Sie Ihre Anmeldeinformationen auf irgendeine Weise an MySQL übergeben. Siehe meinen Kommentar unten, wenn Sie sich auf einer dedizierten VM oder einem dedizierten Server befinden und Ihren Benutzer / Pass auf crontab übertragen möchten. Andernfalls müssen Sie eine MySQL-Anmeldeinformationsdatei einrichten. Und Sie können verwenden which mysql, um den Pfad zu Ihrem MySQL-Binärverzeichnis zu finden.

Codesmaller
quelle
Ihre Antwort hat bei mir funktioniert, aber das Hinzufügen in crontab mit mysql magento-db -e "query", wobei magento-db der Datenbankname ist (in meinem Fall bitnami_magento), funktioniert es auch, wenn ein Kennwort für die Datenbank vorhanden ist? Normalerweise gebe ich die Datenbank gerne ein mysql -u somename -pund gebe dann das Passwort in einer Eingabeaufforderung ein.
user5198077
Mit Ihrer bevorzugten Suchmaschine können Sie leicht ein paar Lösungen dafür finden. Ich habe diesen Teil für die Benutzer- / Pass-Informationen weggelassen, aber ich werde ihn veröffentlichen, nachdem ich den Haftungsausschluss gegeben habe: Tun Sie dies nicht auf Shared Hosting, da er unter anderem für andere mit top -c sichtbar ist. Suchen Sie in diesem Fall nach der Verwendung einer MySQL-Anmeldeinformationsdatei, .mycnf oder ähnlichem. Dies ist, was ich habe*/15 * * * * <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 hour)";
Codesmaller