Das kann natürlich sein. Ich habe gerade mal in den Changelog von Frosh Tools geschaut und das Feature wurde wirklich erst mit der Version 2.6.2 hinzugefügt (24.03.)
Aktuell ist es auch noch kein großes Problem, da wir bisher keine großen Performance Probleme festgestellt haben.
Es wundert mich nur etwas, da wie gesagt gerade in der Testumgebung ohne Traffic das Problem auch auftritt.
Wir werden es mal weiter beobachten.
Was für Theme nutzt Ihr?
Und wegen Frosch Tools. Wenn ich Plugin deaktiviere dann Shop Status ist wieder grün.
Das ist aber „normal“. Frosh Tools nutzt das ganze, um auf „Probleme“ hinzuweisen.
Der Shop-Status ist dann nicht wieder grün, der Shop-Status existiert dann nicht mehr. Das ist ein Feature von Frosh Tools.
Nach welcher Logik wird das “PHP FPM max children reached” in den Frosh Tools angezeigt?
Werden da nur die letzten Stunden berücksichtigt bzw. wann verscheindet die Warnung wieder?
Wenn die Variable gesetzt ist, soviel ich weiß. Nach dem Neustart von PHP sollte es zurückgesetzt sein.
Hi zusammen,
ich hänge mich hier jetzt mal mit rein, weil wir genau die gleiche Situation haben. All-inkl als Hosting und quasi immer die Meldung in den Frosh Tools „PHP FPM max children reached“ und der Shop hat halt eine Warnung.
Auch bei uns wurde von all inkl. eine Logdatei angelegt, php-fpm_slow.log und in dieser stehen alle php Jobs, die länger als 10 Sekunden laufen. Und wenn ich die Datei prüfe, stehen dort ausschließlich die beiden Cronjobs run-scheduledtasks.php und messenger-consume.php.
Diese sehen so aus:
<?php
exec("/usr/bin/php83 ../bin/console messenger:consume failed async low_priority --time-limit=55 --memory-limit=512M 2>&1", $out, $result);
echo "Returncode: " .$result ."<br>";
echo "Ausgabe des Scripts: " ."<br>";
echo "<pre>"; print_r($out);
?>
<?php
exec("/usr/bin/php83 ../bin/console scheduled-task:run --time-limit=55 --memory-limit=512M 2>&1", $out, $result);
echo "Returncode: " .$result ."<br>";
echo "Ausgabe des Scripts: " ."<br>";
echo "<pre>"; print_r($out);
?>
Und bisher liegen die 2 Skripte direkt im public Ordner.
Die Cronjobs sind eingerichtet und laufen alle 2 Minuten. Als Ergebnis bekomme ich dann:
Returncode: 0
Ausgabe des Scripts:
Array ( [0] => Scheduled task runner stopped due to time limit of 300s reached )
Returncode: 0
Ausgabe des Scripts:
Array ( [0] =>
[1] => [OK] Consuming messages from transports „failed, async, low_priority“.
[2] =>
[3] => // The worker will automatically exit once it has exceeded 512M of memory, been [4] => // running for 300s or received a stop signal via the messenger:stop-workers [5] => // command.
[6] =>
[7] => // Quit the worker with CONTROL-C.
[8] =>
[9] => // Re-run the command with a -vv option to see logs about consumed messages. [10] => )
Ich hatte vorher in meinen Skripten ein Limit von 300s drin, das alle 10 Minuten lief, jetzt nur noch 55s, das alle 2 Minuten läuft. Trotzdem werden hier weiterhin die 300s angezeigt. Muss ich bei einer Änderung der Skripte etwas neu starten, damit das greift?
Um das Ganze sicherer zu machen, habe ich jetzt unterhalb von public einen neuen Ordner angelegt, in den ich die 2 php Skripte verschoben habe. Zusätzlich dort noch ne .htaccess und .htpasswd erstellt und im all inkl Backend dann die Userdaten bei den Cronjobs hinterlegt. Leider laufen jetzt die Skripte nicht mehr, ich bekomme eine Fehlermeldung wie folgt:
Returncode: 1
Ausgabe des Scripts:
Array
(
[0] =>
Could not open input file: ../bin/console
)
Was mache ich hier falsch? Wie muss ich das Ganze einrichten, damit es sicher ist und die 2 Dateien hinter einem htaccess liegen?
Du verstehst PHP nicht, das ist dein Problem – wie viele anderen auch. Und das ist nicht böse gemeint.
FPM max children sagt aus, dass die maximale Anzahl an parallel laufenden Prozessen erreicht wurde. Das hat nichts damit zu tun, ob ein Prozess an das Memory-Limit oder Max-Execution-Time-Limit gestoßen ist, was deine Fokussierung auf die Slow Logs nahelegt.
Wenn dein max children bspw. auf 10 gesetzt ist und du kontinuierlich zwei Cronjobs laufen hast, dann sind schon einmal zwei Prozesse belegt. Wenn du die Administration aufrufst – nicht 100% sicher ob die parallel oder in Reihe abgearbeitet wird – da kommen eventuell 5 bis 10 parallel zustande, je nach Seite der Administration. Dann hast du noch 2 Bots in der Storefront und einen Besucher. Schon bist du bei 15 möglichen von 10 vorhandenen Prozessen, was die Warnung triggert.
Anstatt parallel arbeitet PHP die Prozesse dann einfach nacheinander ab, was zu einer Verzögerung ggf. von wenigen ms führt.
Nicht alles was in Frosh Tools genannt wird ist in jedem Hosting sinnvoll, noch ein Problem.
Und zu deinem Cronjob. failed als erste Priorität zu setzen, die vermutlich wieder fehlschlagen und den Prozess die komplette Zeit über blockieren werden… sehr fraglich, ob das sinnvoll ist. Ich würde das ans Ende oder in einen separaten Cronjonb packen.
Vielen Dank für die Erläuterung, @Max_Shop
Heißt also, du würdest empfehlen, den messenger-consume Job nochmal aufzuteilen, so dass im 1. Job “nur” noch async und low-priority drin sind und einen neuen Job anzulegen mit failed, korrekt so? Der scheduled-task Job bleibt unverändert bestehen.
Und was ist mit dem Problem, dass es in einem Unterordner nicht funktioniert, wenn ich ich dort htaccess drüberlege? Dann bekomme ich immer den Could not open input file: ../bin/console Fehler?
So, bei mir läuft das Ganze jetzt problemlos mit all-inkl.. Ich habe die beiden Skripte alle 2 Minuten am laufen und die Skripte liegen in einem neuen Unterordner, der per htaccess geschützt ist. So sollte es dann auch sauber sein….
Wichtig dabei ist folgendes:
Wir hatten ursprünglich mal die Skripte eingerichtet, so dass sie alle 10 Minuten liefen mit einer max Zeit von 300s. Dann ist aufgefallen, dass jede Änderung an den Skripten nicht greift bzw. auch die Einrichtung der htaccess für die bestehenden Skripte ging nicht. Es kam dann zu einem Fehler “could not open file…”.
Das liegt daran, dass jede Änderung erst greift, wenn PHP neu gestartet wird. Das passiert aber nicht, wenn man “nur” einen Hostingtarif hat und keinen eigenen Server. Dadurch hat man selbst auch keine Möglichkeit, PHP neu zu starten, um die anderen Kunden auf dem Server nicht zu beeinflussen.
Im Endeffekt haben wir die Skripte dann umbenannt und alles eingerichtet. Das läuft dann perfekt und sauber, so wie es sein soll.
Hallo ChriMaLuxe,
Danke für die Info! Klingt gut! Und was macht bei Dir jetzt PHP FPM max?
Mit besten Grüßen
Lago
Hi @Lago ,
ich habe mit all-inkl. gesprochen und die haben den Wert von standardmäßig 15 mal auf 30 erhöht bei mir. Mehr ist nicht drin (wegen dem limitierten RAM). Allerdings wird mir nach wie vor die Warnung angezeigt, weil auch das erst greifen wird, wenn PHP neu gestartet wird.
Von daher warte ich jetzt einfach mal ab, bis es wieder eine Wartung gibt, denn danach starten sie die Server ja durch und alles sollte erst mal wieder passen und dann “grün” sein.
Aber selbst wenn es danach wieder orange wird, ist es mir dann egal, weil ich 30 Prozesse als Limit habe und im Log keine Langläufer sehe. Und selbst wenn es dann mal kurzzeitig mehr sind, sind das wohl normalerweise Prozesse, die ruck zuck erledigt sind und deshalb kein wirkliches Problem im Shop besteht.
Hmm… Bei mir wollten die gar nichts machen. Trotz, dass ich denen drei Kunden gebracht habe. 
Schreib bitte nochmal sobald die Wartung durch ist. Ist einfach interessant wie es dann bei Dir aussieht.
Jetzt allgemeine Frage an alle wegen o.g. Cronjobs. Wir sind inzwischen auf 6.7… umgestigegen. Gibt’s da irgendwelche Änderungen bei diesen Cronjobs?
Mit besten Grüßen
Lago
Heute kam eine neue Version vom Frosh Tool raus, der Wert hier ist jetzt “nur” noch als Info hinterlegt mit der entsprechenden Anzahl, aber nicht mehr als Warnung.
So bleibt der Shop auch “grün”, wenn der Wert mal überschritten wurde.
Danke für die Info! Habe gerade ausprobiert. Stimmt, jetzt ist grün.