PHP FPM Fehler diagnostizieren: Verbindung, Queue und Laufzeit

Beim betroffenen Aufruf beginnen

Ein Fehlerstatus im Browser nennt zunächst die Sicht des äußeren Webservers. Er sagt nicht, ob PHP abgestürzt ist, ein Socket fehlt oder eine Anwendung zu lange auf eine Datenbank wartet. Beginnen Sie deshalb mit einem konkreten Aufruf. Notieren Sie die URL, Uhrzeit mit Zeitzone, Antwortstatus und Dauer. Klären Sie, ob alle Seiten oder nur eine Funktion betroffen sind. Ein langsamer Export kann anders zu behandeln sein als eine ausgefallene Startseite. Prüfen Sie auch, ob angemeldete Benutzer anders betroffen sind als anonyme Besucher. Diese Unterscheidung zeigt häufig, ob ein Cache den funktionierenden Pfad übernimmt und der Fehler nur im dynamischen Ablauf sichtbar wird.

Erfassen Sie den Anfrageweg, bevor Sie Dienste neu starten. Unter Plesk kann FPM durch unterschiedliche Webserver angesprochen werden. Der passende Logeintrag hängt von diesem Weg ab. Ein Apache Fehlertext gehört nicht zwangsläufig zu einer direkt durch nginx bedienten Anfrage. Gleichen Sie Host und Pfad ab und suchen Sie den Fehler im engen Zeitfenster. Wenn ein Neustart sofort nötig ist, sichern Sie vorher die wichtigsten Beobachtungen, soweit der Zustand es erlaubt. Ein verschwundener Fehler nach dem Neustart belegt eine Entlastung, aber noch keine Ursache. Die Notiz über den ursprünglichen Zustand bleibt für die spätere Analyse wichtig und sollte nicht durch eine Erfolgsmeldung ersetzt werden.

Verbindung und Ausführung unterscheiden

FPM nimmt Anfragen über einen Socket oder eine TCP Verbindung entgegen. Ist dieses Ziel nicht erreichbar, kommt die Anfrage noch nicht im Anwendungscode an. Prüfen Sie daher zuerst, ob der richtige Dienst läuft, der erwartete Endpunkt existiert und der Webserver auf ihn zugreifen darf. Nach einem Wechsel der PHP Version kann ein alter Socketpfad in einer abweichenden Konfiguration stehen. Ebenso können Rechte oder eine Sicherheitsregel den Zugriff verhindern. Die PHP Dokumentation zur FPM Konfiguration beschreibt die Einstellungen für den Listener und dessen Zugriff. Ein solcher Verbindungsfehler wird nicht durch mehr Speicher für ein WordPress Plugin gelöst.

Kommt die Anfrage im Pool an, interessieren Laufzeit und Auslastung. Ein Prozess kann viel rechnen, auf eine Datenbank warten, eine externe API ansprechen oder durch langsamen Speicher blockiert sein. Von außen kann all das ähnlich aussehen. Vergleichen Sie deshalb eine einfache dynamische Funktion mit dem betroffenen schweren Ablauf. Statische Dateien sind dafür nur begrenzt geeignet, weil sie PHP oft nicht berühren. Prüfen Sie außerdem, ob ein einzelner Fehler immer reproduzierbar ist oder ob die Dauer nur bei hoher Last steigt. Die erste Beobachtung spricht eher für einen bestimmten Codepfad; die zweite lenkt den Blick zusätzlich auf gemeinsam genutzte Ressourcen und die Warteschlange.

Poolstatus mit Zeitbezug auswerten

Die FPM Statusseite kann unter anderem aktive Prozesse, freie Prozesse und die Warteschlange sichtbar machen. Sie muss geschützt bleiben, weil sie Betriebsinformationen und je nach Ansicht Anfragepfade offenlegt. Ein nur intern erreichbarer Statusendpunkt ist für die Diagnose sinnvoll; eine frei öffentliche Seite ist dafür nicht nötig. Sammeln Sie mehrere Beobachtungen über den relevanten Zeitraum. Ein einzelner Wert direkt nach einem Neustart beschreibt nicht die Störung davor. Notieren Sie außerdem den Startzeitpunkt des Pools, damit kumulative Zähler nicht mit Messwerten aus einer früheren Laufzeit verglichen werden. Erst der Verlauf zeigt, ob ein Engpass wiederholt entsteht oder nur kurz auftritt.

Wenn die Zahl aktiver Prozesse die Grenze erreicht, müssen Sie die Arbeit dieser Prozesse verstehen. Ein hoher Wert von pm.max_children schafft nicht automatisch mehr nutzbare Leistung. Zusätzliche Prozesse brauchen Speicher und können eine bereits belastete Datenbank weiter unter Druck setzen. Prüfen Sie den Verbrauch typischer und schwerer Anfragen sowie die übrigen Dienste auf dem Host. Ein Pool muss in das gesamte Ressourcenbudget passen. Bei mehreren Websites zählt zudem die Summe ihrer gleichzeitigen Belastung. Deshalb ist eine Empfehlung aus einer fremden Umgebung höchstens ein Anlass für eine eigene Messung. Die geeignete Grenze ergibt sich aus dem tatsächlichen Ablauf und den verfügbaren Ressourcen, nicht aus einer beliebten Zahl.

Der Slowlog führt zum wartenden Code

Ein Slowlog kann bei langsamen Anfragen Hinweise auf den gerade ausgeführten Teil des Codes liefern. Aktivieren Sie ihn mit einem passenden Schwellwert und begrenztem Umfang für den betroffenen Pool. Die FPM Konfiguration nennt die entsprechenden Einstellungen. Achten Sie auf ein geschütztes Logziel und auf ausreichend Platz. Für die Auswertung interessiert, ob immer derselbe Teil auftaucht: eine Datenbankabfrage, der Zugriff auf einen entfernten Dienst oder eine eigene Schleife. Ein Stackausschnitt ist eine Momentaufnahme und sollte mit dem Fehlerzeitraum zusammen gelesen werden. Er zeigt einen Ansatzpunkt, beweist aber noch nicht, dass jede Zeile darin selbst die Ursache ist.

Verknüpfen Sie den Slowlog mit dem Zugriffslog. Wenn viele langsame Anfragen denselben Export aufrufen, prüfen Sie dessen Nutzung und die erwartete Datenmenge. Wird dagegen eine normale Inhaltsseite langsam, kann eine neue Erweiterung oder eine externe Abfrage im allgemeinen Seitenaufbau beteiligt sein. Fragen Sie, welche Arbeit pro Aufruf wirklich nötig ist und welche Ergebnisse wiederverwendet werden dürfen. Eine Verbesserung am Ablauf kann nachhaltiger sein als eine höhere Zeitgrenze. Dabei ist die Korrektheit wichtig: Ein Cache für personalisierte Daten braucht eine passende Grenze. Die Betriebsprüfung des Caches erklärt, wie solche Grenzen geprüft werden.

Timeouts als Kette lesen

Eine Anfrage kann an mehreren Stellen eine Zeitgrenze erreichen. Der äußere Proxy wartet auf den Backenddienst, der Webserver wartet auf FPM, PHP hat eigene Grenzen und ein externer Dienst kann ebenfalls abbrechen. Der zuerst erreichte Grenzwert bestimmt oft den sichtbaren Fehler. Wenn Sie nur die äußere Grenze erhöhen, bleibt ein innerer Abbruch möglich. Umgekehrt kann ein sehr langer äußerer Timeout Verbindungen und Prozesse länger binden, obwohl der Nutzer schon aufgegeben hat. Zeichnen Sie deshalb den Weg mit den tatsächlichen Einstellungen auf. Die Analyse von 502 und 503 ergänzt die Betrachtung um Antwortstatus und Verfügbarkeit der beteiligten Dienste.

Behandeln Sie einen dauerhaft langen Import möglichst als eigenen Arbeitsablauf. Er muss nicht in derselben Anfrage enden, in der ein Benutzer den Startknopf drückt. Je nach Anwendung kann ein geplanter Job oder eine kontrollierte Warteschlange den Vorgang übernehmen. Für Betreiber ist dabei wichtig, dass Start, Fortschritt, Fehler und Ergebnis nachvollziehbar bleiben. Der Webserver muss dann nicht minutenlang auf dieselbe Verbindung warten. Das ist eine Architekturentscheidung der Anwendung und keine Einstellung, die ein Hoster blind einschalten kann. Klären Sie den Bedarf mit dem zuständigen Entwickler und halten Sie fest, welche Last durch den geplanten Ablauf auf Datenbank und Speicher entsteht.

Speicher und Abbrüche richtig einordnen

Wenn ein Prozess unerwartet endet, prüfen Sie sowohl das FPM Log als auch die Systemereignisse. Ein durch den Kernel wegen Speicherdruck beendeter Prozess hinterlässt andere Hinweise als ein normaler PHP Fehler. Die Grenze memory_limit beschreibt nicht das gesamte Budget des Hosts. Mehrere gleichzeitig laufende Prozesse können zusammen deutlich mehr Platz beanspruchen, und andere Dienste benötigen ebenfalls Speicher. Ein steigendes PHP Limit kann deshalb eine Störung verschärfen. Beginnen Sie mit der betroffenen Funktion, ihrem Datenumfang und dem tatsächlichen Verlauf. Falls Sie keinen Zugriff auf die Systemlogs haben, liefern Sie dem Anbieter den präzisen Zeitraum und bitten um die passende Prüfung statt um eine pauschale Erhöhung.

Auch Dateideskriptoren gehören zum Ressourcenbild. Netzwerkverbindungen, Dateien und Pipes benötigen solche Handles. Ein Fehler mit zu vielen offenen Dateien ist daher nicht automatisch ein Problem der PHP Speichergrenze. Unterscheiden Sie eine Prozessgrenze vom systemweiten Engpass. Unser Ratgeber zu Linux Open Files erklärt die Messung beider Ebenen. Für FPM kann außerdem eine ungewöhnlich hohe Zahl wartender Verbindungen wichtig sein. Prüfen Sie, ob ein Prozess Verbindungen zuverlässig schließt und ob ein externer Dienst langsam reagiert. Ein Neustart kann die Handles freigeben und das sichtbare Problem zunächst beseitigen, ohne das Verhalten des Codes dauerhaft zu verändern.

Ein Eingriff braucht eine konkrete Hypothese

Wählen Sie aus den Beobachtungen die nächste kleine Prüfung. Eine nicht erreichbare Listeneradresse verlangt eine Prüfung von Konfiguration und Rechten. Eine lange Queue mit vielen langsamen Datenbankaufrufen verlangt eine Prüfung dieses Datenpfads. Ein einzelner wiederholbarer Fehler nach einer Codeänderung kann in einer getrennten Vorschau gegen den vorherigen Stand getestet werden. Legen Sie vor dem Eingriff fest, welches Ergebnis die Hypothese stützen oder widerlegen würde. So wird die Diagnose schneller, obwohl weniger gleichzeitig verändert wird. Dokumentieren Sie auch ein negatives Ergebnis. Wenn eine Prüfung eine vermutete Ursache ausschließt, ist das ein wertvoller Schritt und kein verlorener Versuch.

Vermeiden Sie globale Neustarts als Routineantwort auf eine einzelne Domain. Auf gemeinsam genutzten Hosts beeinflussen sie andere Websites und löschen wichtige Verlaufsdaten. Falls eine Entlastung dringend nötig ist, begrenzen Sie den Eingriff auf den passenden Pool, soweit die Umgebung das erlaubt. Sichern Sie zuvor die aktuelle Belegung und die entscheidenden Logs. Prüfen Sie nach dem Eingriff den betroffenen Ablauf sowie eine normale Vergleichsfunktion. Ein wieder erreichbarer Dienst ist ein erster Erfolg. Die Störung bleibt dennoch zur Ursachenanalyse offen, wenn der Auslöser nicht erklärt wurde. Diese Unterscheidung sollte auch in der Kommunikation mit dem Team und dem Anbieter klar bleiben.

Mit brauchbaren Belegen an den Anbieter geben

Eine gute Meldung enthält Domain, Abo, PHP Version, Handler, Zeitpunkt und den betroffenen Ablauf. Fügen Sie den sichtbaren Status sowie wenige passende Logzeilen hinzu. Beschreiben Sie, ob andere Funktionen betroffen sind und was kurz vor dem Fehler geändert wurde. Bei Queueproblemen sind mehrere Statuswerte mit Zeitstempel hilfreich. Geben Sie aber keine vollständige Konfiguration oder vertrauliche Parameter ungekürzt weiter. Der Anbieter kann mit diesen Angaben den Dienst und die Ressourcen des Hosts prüfen. Entwickler können denselben Zeitraum im Anwendungscode untersuchen. Die klare Aufteilung macht sichtbar, welche Ebene bereits geprüft ist und wo noch eine Aussage benötigt wird.

Nach der Korrektur folgt eine Beobachtung unter vergleichbarer Nutzung. Ein leichter Aufruf am Morgen ist kein Ersatz für den schweren Ablauf, der am Abend scheiterte. Führen Sie den vereinbarten Test kontrolliert aus und beobachten Sie Antwort, Queue und Fehlerlog. Prüfen Sie auch, ob der Eingriff neue Nebenwirkungen hatte, etwa mehr Speicherverbrauch oder längere Wartezeiten in einer anderen Funktion. Der Status wird dann präzise: Verbindung korrigiert, Kernablauf geprüft, Lastgrenze noch offen. Eine tragfähige FPM Diagnose verbindet den Fehler mit einem konkreten Weg und einer passenden Messung. Das Ergebnis ist eine begründete Änderung mit überprüfbarer Wirkung statt einer Sammlung immer höherer Limits.

Für wiederkehrende Fälle lohnt ein kurzes Runbook mit genau den Messpunkten, die in Ihrer Umgebung zugänglich sind. Es nennt den richtigen Pool, die Logquelle, den geschützten Statusweg und die zuständige Person. Prüfen Sie das Runbook gelegentlich an einer harmlosen Anfrage. Wenn ein dokumentierter Pfad nach einem Update nicht mehr stimmt, sollte dies in einem ruhigen Moment auffallen. So bleibt die Anleitung praktisch nutzbar, wenn unter Zeitdruck mehrere Menschen an derselben Störung arbeiten. Das Runbook für Vorfälle hilft, Beobachtung, Entlastung und dauerhafte Korrektur in getrennten Schritten festzuhalten.