Ich habe zufällige 500 Internal Server -Fehler auf meinen PHP / MySQL-basierten Websites auf verschiedenen freigegebenen Hosts. Ich verwende PHP 5.2.17 über CGI / FastCGI auf einem gemeinsam genutzten Linux-Server. Wenn ich in die Protokolle schaue, sehe ich Folgendes:
Weiß jemand, wie man das löst?
Dieses Problem ist im Allgemeinen nicht nur Host-spezifisch, sondern hängt auch von den Entwicklern ab, abhängig von der Konfiguration. Einige Hosts sind jedoch mit FastCGI ziemlich streng und schränken Ihre Möglichkeiten ein. Es ist in der Regel einfacher, ohne FastCGI zu laufen und nur mod_php zu verwenden, es sei denn, Sie müssen FastCGI in Ihrer Anwendung verwenden.
Wir müssten Ihren fcgi-Wrapper (was ist in /dev/shm/blackmou-php.fcgi) oder .htaccess für FastCGI-Spawning, um Sie besser zu unterstützen, ohne zu wissen, welche Dateien und der Code, der auf diesen Dateien das Problem ist tritt mit auf. Verwenden Ihre Hosts auch Apache, LightHttpd oder Nginx (oder eine Kombination)? An diesem Punkt empfehle ich dringend, PHP 5.3.9 +
zu aktualisierenDa dies durch eine Reihe von Problemen verursacht werden kann, verhindert FastCGI effektiv, dass Ihre Site / Skripte von einem Denial of Service oder einem Absturz aufgrund von Speicherlecks usw. angegriffen werden. (ZB: Versuch, 80.000 Verbindungen zu handhaben, indem einfach die Anzahl der Anfragen verworfen und begrenzt wird oder indem man in einer Endlosschleife steckenbleibt, indem man den Prozess zeitlich begrenzt und beendet).
Dieser Fehler wird im Allgemeinen durch ein idle_timeout (30 Sekunden standardmäßig) oder ein Maximum für untergeordnete Prozesse verursacht. Es kann auch dadurch verursacht werden, dass jemand ein lang laufendes Skript startet und den Browser / die Verbindung vor Abschluss des Skripts schließt.
FastCGI startet seinen Prozesswrapper, führt einen Befehl aus und beendet das Zeitlimit vor dem Abschluss des Prozesses. Die Verbindung wird von Peer als zurückgesetzt angesehen.
Ein weiteres Beispiel ist, dass max. Kinder (maxProcesses) erreicht werden (ZB: viele Websites zeigen 2 oder 4 als Beispiel, wenn Sie in Wirklichkeit 20 oder 50 benötigen, abhängig vom durchschnittlichen Verkehr) Wenn alle untergeordneten Elemente derzeit aktiv sind und eine zusätzliche Anforderung / Verbindung besteht, sind die untergeordneten Elemente auf maxProcesses beschränkt, für die FastCGI die aktiven untergeordneten Elemente nicht freigeben soll. Daher muss das untergeordnete Element zuerst den Prozess beenden und einen neuen untergeordneten Prozess starten Anfrage, abhängig von Ihren Konfigurationen.
Hier finden Sie weitere Informationen zu den Einstellungen:
Wrapper Beispiel
%Vor%AKTUALISIEREN
Um dies hinzuzufügen, kann dies auch durch php memory limit
verursacht werdenWenn das Problem dadurch nicht gelöst wird, aktualisieren Sie Ihre php.ini, um memory_limit
zu erhöhenfür alle, die mehr Informationen suchen:
In meinem Fall gab es ein Code-Problem. Bei einer eingehenden http-Anfrage wurde innerhalb des Codes ein Aufruf einer internen URL vorgenommen, wodurch eine Deadlock-Situation entstand.
Dies führte zu hängen PHP-Prozesse und brachte den Server herunter. Wir benutzten file_get_contents ('URL') oder cURL () in unserer Callback-Funktion. Wir haben es dann durch eine einfache Drupal-Funktion ersetzt, die uns die Werte aus der DB lieferte.
Das NewRelic-Tool hat mir geholfen, die Funktion zu identifizieren, die viel Zeit zum Antworten benötigt hat.
Eine andere Möglichkeit, dies zu erkennen, wäre gewesen, einen drupal_watchdog auf unserer Callback-Funktion auszuführen und die Protokolle zu überprüfen, wenn der Server abgestürzt ist.
hoffe das hilft.