Ich hoste mehrere (~30) verschiedene Sites auf einem Server mit Apache2+FastCGI+Suexec+PHP5. Die Sites haben unterschiedliche Auslastungen und unterschiedliche Ausführungszeiten ihrer Skripte (einige verarbeiten Anfragen in 5-7 Sekunden, andere in <1 Sekunde).
Manchmal, wenn eine einzelne Site eine sehr hohe Auslastung erfährt (alle PHP-Instanzen dieser Site werden erstellt und verwendet), bleibt der gesamte Apache-Server hängen. Apache (Worker MPM) erstellt neue Prozesse bis zur Obergrenze. Es sieht so aus, als würde es beginnen, ALLE neuen Anfragen für JEDE Site in die Warteschlange zu stellen, nicht nur für die Site, die eine hohe Auslastung hat und schnell die Prozessgrenzen erreicht... ein Neustart von Apache löst das Problem...
Konfiguration: FastCgiConfig -singleThreshold 1 -multiThreshold 10 -listen-queue-depth 30 -maxProcesses 80 -maxClassProcesses 12 -idle-timeout 30 -pass-header HTTP_AUTHORIZATION -pass-header If-Modified-Since -pass-header If-None-Match
(Früher war der Standardwert -listen-queue-depth = 100, aber das hat nichts geändert …)
Irgendwelche Vorschläge?
Noch eine Frage: Wie wird diese Abhörwarteschlange implementiert? Ist es eine Warteschlange für den gesamten Apache oder eine eindeutige Warteschlange für jede definierte PHP-Anwendung (Suexec-Site)?
Ich würde gerne so etwas erreichen: Wenn eine Site stark ausgelastet ist und ihre Warteschlange voll ist, weist der Server die nächste Anfrage zurück, aber nur für diese eine Site. Andere Sites sollten ordnungsgemäß funktionieren ...
Antwort1
Apache 2.4 bietet ein neues Fastcgi-Proxymodul (mod_proxy_fcgi), das Anfragen an php-fpm weiterleiten kann. Wenn Sie mod_proxy als Vermittler verwenden, haben Sie Zugriff auf alle mod_proxy-Optionen, einschließlich Warteschlangen- und Erschöpfungsparameter, getrennt vom Hauptserver.
Ich würde Ihnen raten, es auf einem Testserver mit dem Apache 2.4 Event MPM und PHP-FPM einzurichten; Sie können jeden PHP-Pool auch für verschiedene Anwendungen optimieren.
Antwort2
Haben Sie stattdessen mod_fcgid ausprobiert? Damit lässt sich eine hohe Belastung Ihres Servers viel besser bewältigen.
Antwort3
Wenn FastCGI die PHP-Skripte als Benutzerprozess hochfährt, sollten die Definitionen von /etc/security/limits.conf (insbesondere nproc) vom Betriebssystem erzwungen werden.
z. B.: Apache versucht, den Prozess als dieser Benutzer zu starten, und das Betriebssystem beendet den Prozess, da das Prozesslimit überschritten wurde.
Dies ist allerdings eine Art Behelfslösung. Wenn die Maschine ansonsten im Leerlauf ist, werden Sie weiterhin Verbindungen trennen.
warum verzweigen Sie Ihren größeren Client nicht einfach auf eine dedizierte Maschine? oder starten Sie einen sekundären Apache, der auf einem hohen Port lauscht, mit einem festgelegten Footprint/Laufzeitkontingent? Sie könnten mod_proxy verwenden, um die Anfragen transparent weiterzuleiten.
allerdings bin ich mit FastCGI nicht so vertraut, also könnte es sein, dass dort bereits ein Quotensystem verfügbar ist; ein schnelles Durchlesen der Dokumentation hat allerdings nichts ergeben.
Antwort4
Sie können sich hier eine Reihe von Web-Tutorials ansehen: http://blog.stuartherbert.com/php/category/the-web-platform/
Ich persönlich finde diese sehr aufschlussreich! Und dieses Tutorial ist wahrscheinlich genauso hilfreich: http://blog.stuartherbert.com/php/2008/10/07/can-you-secure-a-shared-server-with-php-fastcgi/
Ich würde ehrlich gesagt empfehlen, die Site mit dem hohen Datenverkehr auf einen eigenen Computer zu verschieben, wenn sie so viele Ressourcen verbraucht.