Ich führe PHP-FPM aus und habe ein Problem während Zeiten extrem hoher Last, die dazu führen, dass PHP-Prozesse für immer hängen bleiben. Ich habe ein GDB-Backtrace eines laufenden Prozesses, der festgefahren war, und habe dies (irrelevante Frames entfernt):
%Vor%Was ich also sehen kann, ist, dass ich versuche, mich mit MySQL zu verbinden, und dann stürzt PHP ab und fragt den Socket ab. Es ist möglich, dass MySQL die Verbindung abbrach oder ablehnte (die Datenbank war zu 100% CPU-Last).
Allerdings habe ich mysql.connect_timeout auf 60 gesetzt, also würde ich erwarten, dass die Verbindung nicht so lange dauert (es war über 20 Minuten). default_socket_timeout wird ebenfalls auf 300 Sekunden gesetzt.
Und ich werde alle Vorschläge für ein Upgrade auf mysqli vorwegnehmen, indem ich sage, dass ich das versucht habe (wir verwenden eine DBAL), und hatte dasselbe Problem wie mysqli die gleichen Verbindungsfunktionen unter der Haube verwendet / p>
Ich verwende PHP 5.5.19 unter Ubuntu und benutze den mysqlnd-Treiber.
Irgendeine Idee, was dazu führen könnte, dass PHP keine Zeitüberschreitung hat?
Ich denke, Sie treffen auf das, was ich die "Dead Usability Band" nenne. Was das bedeutet ist, dass du zwischen deiner Aktion, die komplett fehlschlägt (wo sie eine Auszeit nehmen würde), stecken und trotzdem nicht funktionieren wirst. Also ist die Kette der Dinge das
SHOW PROCESSLIST; ausführen.
Ich verstehe, dass Sie nicht SQL senden, aber ich denke, dass die gleichen Prinzipien ins Spiel kommen. Manchmal können Sie sehen, dass dies in einer entfernten Datenbank mit MySQL Workbench passiert (wo eine Abfrage ausgeführt wird, aber keine Ergebnisse liefert). So wartet Workbench auf eine Antwort, die praktisch nie passieren wird.
Also, wie das zu beheben? In der Praxis kann man nicht auf der Programmier-Ebene von PHP. Die PHP-API stellt nicht genügend der zugrunde liegenden Aufrufe bereit, damit Sie erkennen können, dass Sie in einem toten Band stecken geblieben sind, und die Verbindung beenden. Und das Schreiben eines Skripts, das nach toten Bändern sucht, läuft immer Gefahr, ansonsten gute Prozesse zu beenden. Ihre beste Wette (so sehr ich es hasse es zu sagen) ist es, MySQL zu stärken und sicherzustellen, dass es genug Ressourcen hat, um nicht 100% zu erreichen. Wenn Sie einen Server mit PHP / Apache teilen, ist das ein Rezept für solche Dinge. Ich habe bemerkt, dass dies selten auf unserem größeren und besseren System geschieht, da wir MySQL in eine eigene Instanz verschoben haben. Überprüfen Sie auch mysqltuner . Es kann sich Ihre MySQL-Instanz ansehen und Konfigurationseinstellungen vorschlagen, um die Leistung zu verbessern.
Ein paar Dinge zu überprüfen:
Ich habe auch ähnliche back strace-Informationen in meinen php-fpm-Programmen gefunden Es sollte durch die folgenden Fehlerbehebungen behoben worden sein: Ссылка , Ссылка
Die Ursache war auf einen Fehler in den PHP-Tools zurückzuführen: php_openssl_sockop_read.
php-fpm hat den 'feof'-Zustand einer solchen Verbindung nicht erkannt, und der' poll'-syscall benutzte immer noch eine solche fd (sie wurde von mysql server geschlossen), schließlich klemmte die Clientseite (php-fpm) fest (bei der Umfrage) für immer.
Sie sollten die neueste Version von PHP verwenden oder PHP mit solchen Bugfixes neu aufbauen (bugs.php.net/bug.php?id=41631, ich denke es reicht)