PHP FPM max children reached

[Lago]

Hallo zusammen,

seit 3-4-5 Tagen wird unter „Tools“ oft diese Warnmeldung angezeigt: - „PHP FPM max children reached“. Und Backend (Admin) sowie Frontend sind richtig langsam. Und zwar gleich in 4 verschiedenen Shops, die bei dem Hoster in absolut verschiedenen Accounts liegen. Sprich alles unterschiedliche Betreiber. Ich habe mit dem Hoster kommuniziert und die können nicht wirklich sagen an was das liegen kann. Logs haben keine einheitliche Struktur. Bei einem Shop laufen die PHP Dateien in dieser Zeit und bei anderem andere. Weiß jemand evtl. an was es liegen kann?

Mit besten Grüßen
Lago

[raymond-de]

Merkwürdig. Unterschiedliche Accounts bedeutet dass die Webseiten auf unterschiedlichen Hosting-Verträgen, also im Idealfall unterschiedliche Hardware, auf dem selben Hoster läuft?

Vielleicht noch ein paar Infos vom Hoster: welcher Hoster und welches Paket, welche PHP Version? Vielleicht hast du mittlerweile mehr Traffic und das Hosting-Paket ist zu klein.

Wenn du am Shop nichts geändert hast (Versionsupgrade, Plugin Installation oder Upgrade) kann es ja nur am Hoster liegen und er muss es finden. Wenn dieser Shopware zertifiziert ist, können die auch mehr dazu sagen bzw. Wollen mehr dazu sagen.

Das sagt ChatGPT dazu:

Bei Shopware 6 und der Meldung „PHP-FPM max children reached“ handelt es sich um ein typisches Server-Ressourcenproblem: Es sind mehr gleichzeitige PHP-Anfragen aktiv als PHP-FPM verarbeiten kann. Das führt zu langen Ladezeiten, Timeouts oder 502-Fehlern.

Hier sind konkrete Schritte zur Behebung, abgestimmt auf Shopware 6:

⸻

1. PHP-FPM konfigurieren (zentraler Punkt)

Öffne die Datei für deinen PHP-Pool, z. B.:

/etc/php/8.x/fpm/pool.d/www.conf

Oder:

/etc/php/8.x/fpm/pool.d/shopware.conf

Wichtige Parameter:

pm = dynamic
pm.max_children = 50 ; ← Anzahl gleichzeitiger PHP-Prozesse
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500 ; zur Speicherfreigabe nach X Requests

Faustregel für pm.max_children:

(freier RAM für PHP) / (RAM je PHP-Prozess)
Beispiel: 4 GB frei / 80 MB je Prozess ≈ 50 max_children

Anschließend:

sudo systemctl restart php8.x-fpm

⸻

2. Shopware 6 Performance optimieren

a) HTTP Caching aktivieren

Shopware 6 nutzt Symfony Cache und HTTP-Cache via Reverse Proxy (z. B. Varnish oder Symfony Proxy):
• Stelle sicher, dass Shopware HTTP-Cache aktiviert ist:
config/packages/shopware.yaml:

shopware:
http_cache:
enabled: true

Oder über das Admin-Panel (unter Einstellungen > System > Caches & Indizes).

b) Symfony Profiler deaktivieren

In der Produktion sollte der Symfony-Debug-Modus komplett aus sein:

APP_ENV=prod
APP_DEBUG=0

c) Plugins & Themes
• Deaktiviere unnötige Plugins.
• Überprüfe Drittanbieter-Plugins auf Performance-Probleme.
• Kompiliere das Theme vollständig.

d) Assets & Caching

bin/console theme:compile
bin/console cache:clear
bin/console cache:warmup

⸻

3. OPcache aktivieren (wichtig!)

In der php.ini:

opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.validate_timestamps=1

⸻

4. Lastanalyse & Monitoring
   • top, htop, iotop, dstat → Live-Auslastung checken
   • Shopware Profiler (lokal oder Staging)
   • Blackfire, New Relic, Datadog → für tiefere Analyse

⸻

5. Langfristig: Skalieren

Wenn Last dauerhaft hoch ist:
• Upgrade auf größeren Server
• Redis für Cache & Session Handling
• Reverse Proxy (Varnish oder nginx FastCGI-Cache)
• Horizontale Skalierung mit Load Balancer

⸻

[Anotherone]

Bei den meisten Hostings wirst Du die Parameter nicht anpassen können, es sei denn, es ist ein VPS- oder Rootserver. Der Fehler kann eigentlich primär von zu vielen Aufrufen oder zu lange dauernden Aufrufen kommen. Beides deutet auf zu schwache Hardware hin oder massive Besucherzahlen, wobei das natürlich auch Bots sein können. Facebook ist mir da teils negativ aufgefallen. Kurios ist halt, das es bei 4 verschiedenen Hostings gleichzeitig auftritt, schon ein merkwürdiger „Zufall“.

[Lago]

Hallo zusammen, vielen Dank für Eure Antworten! Das ist genau so wie Anotherone schreibt. Es handelt sich um solche Hosting Accounts wo man PHP-technisch nichts anpassen kann. Gehostet wird bei All Inkl. Die haben auch wegen zu vielen Aufrufen gemeint und aus diesem Grund haben bei jedem Shop jeweils eine php-fpm_slow.log Datei erstellt. Ich habe diese Dateien schon mehrmals geprüft, aber da gibt’s keine Auffälligkeiten. Es werden nur die laufende Cronjobs dokumentiert. Eins habe ich vergessen zu schreiben. Ein von 4 genannten Shops ist eigentlich nicht mal Shop sondern wird nur für eigene Web Presentation genutzt. Insgesamt sind lediglich 21 Seiten. Mehr nicht. Und selbst da kommt diese Fehlermeldung. Gestern als ich mit All Inkl kommuniziert habe war plötzlich über längere Zeit in allen 4 Systemen wieder alles auf grün. Und irgendwann später wieder Warnmeldungen „PHP FPM max children reached“ aufgetaucht. Und ich kann da keinen Muster erkennen. Alles verschiedene Verträge und verschiedene Pakete: von klein bis groß. Bei einem steht was in der Warteschlange bei anderem nicht usw., aber trotzdem alle haben diese Fehlermeldung…

Mit besten Grüßen
Lago

[raymond-de]

Kommt darauf an wie wichtig dir die Webseiten sind, ggf. auf eine größeren Tarif bei All-Inkl oder zu einen Shopware zertifizieren Hoster wie z.B. TimmeHosting wechseln.

[Lago]

TimmeHosting kenne ich ziemlich gut. Betreue dort auch einen Shop. Aber von All Inkl einfach so weg gehen will ich nicht. Bei All Inkl bin ich schon seit 2008 und sind wirklich gut. Allein schon was Support angeht. Da kannst Du am Wochenende oder auch Nachts was schreiben und ziemlich bald kommt eine Antwort. Auch die Leistung ist überzeugend.

Das mit diesem Problem stimmt einfach was nicht. Bei meinen Webauftritt übrigens habe ich das heute Mittag doch hinbekommen. Habe gleichzeitig mehrere Sachen ausprobiert und dann war Fehlermeldung plötzlich weg. Auch jetzt ist die Fehlermeldung weg. Alles einwandfrei. Ich denke Auslöser könnte die Löschung von inaktiven Produkten sein. Es waren ca. 2000 Artikel, die ich als Migrationstest mal importiert habe. Ich probiere einfach weiter.

[Anotherone]

Das könnte schon passen, fällt dann in die Kategorie „lang dauernde Aufrufe“.

[Lago]

Aber was komisch ist, danach habe das gleiche in meinem eigenen Shop mit gleichen Produkten gemacht. Sprich alle Artikel komplett gelöscht und Cache aufgefrischt. Hat leider nichts gebracht. Deshalb habe die DB wieder zurückgesetzt und jetzt tue alle unnötige Plugins deaktivieren und aus dem Adminbereich entfernen. Schadet so oder so nicht.

Da habe ich ich aber vor 10 min. noch was „entdeckt“. Unter „Tools > geplante Aufgaben“ waren gleich 18 Aufgaben auf die genau die gleiche Zeit geplant: 14:47 Uhr. Laut All Inkl liegt die FPM-Grenze bei max. 15 Prozesse pro Account. Sprich sobald diese Grenze erreich wird können keine weiteren Prozesse mehr gestartet werden. Ich teste mal weiter.

[raymond-de]

Inaktive Produkte nehmen doch keine Prozesse in Anspruch. Und dann auch nur so wenig. Klingt alles sehr komisch.

Welchen Tarif? Gibts keinen der mehr FPM-Prozesse unterstützt?

[Lago]

Das hat mich eben auch gewundert. 1800 inaktive Artikel könnten die Ursache sein??? Aber in diesem Shopsystem ist es tatsächlich so. Ich habe gerade nochmal nachgeschaut. Alles auf Grün!

Bei All Inkl habe Business Tarif.

[Lago]

Was mir noch Gedanken macht sind zwei Cronjobs, die aktuell jede Minute laufen:

run-scheduledtasks.php
messenger-consume.php

Und ich meine, die arbeiten nicht alles ab. das wäre z.B. aktuelle Meldung bei run-scheduledtasks.php

/////////////////////////////////////////////////
Returncode: 0
Ausgabe des Scripts:

Array
(
[0] => Scheduled task runner stopped due to time limit of 55s reached
)
/////////////////////////////////////////////////

[Lago]

Hallo zusammen,

heute konnte ich was entdecken. Laut Logs waren gestern ca. 15.000 Aufrufe und ca. 10.000 davon über meine IP Adresse… Ich mache da aber nichts oder nur ganz minimal. Wie kann das sein? Ich nutze Firefox. Vielleicht produziert da eben Firefox diese Aufrufe? Oder kommen diese evtl. über „ungeschützte“ Cronjobs???

Mit besten Grüßen
Lago

[nvdennis]

Ich vermute mal du warst im SW6 Admin eingeloggt? Dann dürfte das normal sein. Schau mal während du im Admin bist in den Browser Developer Tools im Tab Network. Da siehst du dann die Aufrufe alle paar Sekunden.

Auch die Meldung deines Scripts mit dem Erreichen des 55 Sekunden Limits ist aus meiner Sicht normal und keine Fehlermeldung. Das heißt nur, es hat in den eingestellten 55 Sekunden das getan, was es soll und muss dann neu gestartet werden. Das tut dein Cronjob ja alle 60 Sekunden.

Was wird denn in „Tools“ unter „Scheduled tasks overdue“ und im Tab „Warteschlange“ ausgegeben?

[Lago]

Das ist eben das. Ich bin im Admin nur 1-2 mal am Tag drin. Und jeweils höchstens 10 Minuten. Muss nur schnell Migration von Lagerbeständen durchführen. Aufrufe aber laufen ununterbrochen von (grob eingegeben) 10:00 Uhr bis 16:00 Uhr und dann am Abend von 21:00 Uhr bis 23:00 Uhr.

In der Warteschlange sind überhaupt keine große Bewegungen. Meistens alles komplett auf 0. Auch jetzt ist so.

Ich habe jetzt folgendes gemacht. Tab mit dem Shop (Frontend) aus dem Firefox komplett entfernt und Cache von Firefox komplett geleert. Werde dann heute Abend ab 21:00 Uhr nachschauen wie es sich entwickelt und morgen Logs für heute runterladen und nochmal gründlich prüfen.

[Tobi78]

Bitte prüf mal in welchen Worker dein Shop nutzt.

Am einfachsten siehst du das, wenn FroshTools installiert sind: Tab „System-Status“ - wenn der Admin Worker aktiv ist, gibts da ne Meldung. Der Shop sollte in jedem Fall im CLI Worker Modus laufen.

Hier gibts ein paar Infos dazu:

Shopware 6 - Tutorials und FAQ - Message Queue und Scheduled Tasks

[Lago]

Hallo Tobi78, Danke für Deine Nachricht!
Admin Worker ist bei mir abgeschaltet. Da nutze ich Plugin von Acris: - Shopware 6 Admin Worker deaktivieren

Und statt dessen laufen 4 Cronjobs:
run-scheduledtasks.php (jede Minute)
messenger-consume.php (jede Minute)
cache-clear.php (1 x in 24 Std.)
cache-warm-up.php (1 x in 24 Std.)

Das wäre dann CLI Worker Modus.

Ich tippe irgendwie jetzt wirklich auf Firefox. Es gibt doch genug Meldungen wie gerne Firefox Daten sammelt. Ich lasse weiterhin Tab mit meinem Shop nicht aktiv und prüfe morgen die Logs von heute. Bin gespannt. Wenn das stimmt dann sollen in diesem Log mindestens 50% weniger Einträge mit meiner IP Adresse drin sein. Bei anderen Shops habe ich Tabs weiter aktiv gelassen und werde morgen auch Logs von diesen Shops prüfen was da läuft.

Aber so oder so. Das ist eine echt einmalige Geschichte… Seit mehreren Jahren habe ich sowas nicht gehabt.

[Lago]

Fast vergessen, aktueller Status = alles bestens:

[patricks1]

Hallo Lago,
darf ich fragen welche Shopware Version ihr verwendet? Bei uns tritt das Problem mit „PHP FPM max children reached“ ebenfalls seit kurzem auf. Und ebenfalls in zwei unabhängigen Shops. Wir haben bisher zwar keine Probleme mit der Performance festgestellt und auch keine übermäßigen Zugriffe aber komisch ist es dennoch. Der eine Shop ist auch nur eine Testumgebung, wo überhaupt kein Traffic drauf ist der irgendwelche Prozesse belegen könnte.
Bei uns ist das Problem erst mit der Shopware Version 6.6.10.3 aufgetreten.

[Max_Shop]

@patricks1

Bei uns tritt das Problem mit „PHP FPM max children reached“ ebenfalls seit kurzem auf.

Kann es sein, das Frosh Tools diese Auswertung einfach erst kürzlich hinzugefügt hat und das Problem „schon immer“ bestand?

Ich habe nur Einblick bei kleineren Shopware Installationen. Da ist der Wert häufig durch den Hoster auf 10 oder 20 limitiert.

Und dies zu erreichen, wenn ich die Administration öffne mit unzähligen Requests (nicht sicher, ob die nacheinander oder parallel erfolgen). Dazu noch der Cronjob und ein Bot und wir sind schon am Limit.

Bin mir nicht sicher, ob hier nicht vielleicht zu viel Aufmerksamkeit dem Wert geschenkt wird. Es sagt ja nichts aus, wie viele ms oder sec. die Wartezeit war. Unter umständen setzt eine Erhöhung des Wertes den ganzen Server unter Stress und das gesamte System ist nachher viel langsamer als zuvor.

[Lago]

Hallo zusammen,

bei uns war auch erst seit Version 6.6.10.3.

Bei einem Shop habe ich jetzt endlich im Griff. Ursache wie es aussieht war kostenloses Theme „Free Liberty Responsive Theme“. Ich habe vor 2 Tagen auf Shopware Standard Theme umgestellt und jetzt ist alles in Ordnung. Auch Zugriffe von meiner IP Adresse haben sich von 10.000 auf nicht mal 1.000 reduziert! Und wie schon geschrieben habe diese Zgriffe kamen nur von dem Tab mit dme Shop Frontend. Im Andminbereich bin nur ein paar Minuten drin.

Bei anderen Shops bin noch dran. Theme „Free Liberty Responsive Theme“ wurde inzwischen aktualisiert und ich teste ob das jetzt bessere Ergebnisse bringt.

Mit besten Grüßen
Lago