Timeout: Apache + PHP-FPM + Proxy + SetHandler

Sehe da gerade irgendwie den Wald vor läuter Bäumen nicht bzw. finde die richtige Option nicht.

Vorgeschichte: Serverausfall durch Fehler-Loop. Anfrage an Apache kam rein, der gab es an FPM weiter. Das selbst konnte nix mit anfangen, weil nicht vorhanden, zurück an den Apache -> Errordokument aufrufen, was aber wieder einen 503 lieferte, weil das durch den Proxy nicht erreichbar war. Das doofe nur, das dauerte "unendlich"! Und dummerweise hatte ich lauter Spam-Bots auf dem System, die nur fehlerhafte Dokumente aufriefen und der Apache sagte dann irgendwann... Nö, bin noch immer ausgelastet, da "laufen noch 800 simultane Zugriffe", ich mache dann mal dicht.

So, mein Problem nun nur, welcher verfluchte Timeout ist denn für diese Konstellation zuständig?

Die PHP-Ini hat einen normalen Timeout von 30 Sekunden, so wie üblich.
FPM hat pro Pool einen Timeout von 60 Sekunden. Dieses, so wie ich das verstanden habe, überschreibt den Timeout von der PHP.ini
Dann hat FPM einen Connection-Timeout von 120 Sekunden.
Der Proxy selbst hat keinen Timeout, da nicht vorhanden ????
Der Apache hat selbst einen von 200 Sekunden

Also irgendwas kann da nicht stimmen und leider ist FPM + Proxy + Apache sehr schlecht dokumentiert.

Was ich schon mal weiß, die beiden Timeouts vom FPM konnten nicht greifen, da durch den Loop immer ein neuer Request eröffnet wurde. Also das waren nur wenige Sekunden jeweils. Der Proxy eigentlich dito, denn auch der bekam immer eine neue Anfrage.

Bleibt eigentlich nur der Apache übrig. Aber warum brach der dann nicht ab? Oder funktioniert dieser Timeout beim Apache gar nicht in Verbindung mit FPM+Proxy? Wenn ja, welcher ist es dann?

Irgendwie habe ich gefühlt 20 verschiedene Optionen und keine ist so klar dokumentiert, dass man auch weiß, was genau die eigentlich tut oder für was die ist.

Jetzt bringt Du mich aber echt ins wanken. Du nutzt keinen Proxy? Du nutzt aber doch FPM, oder? Wie hast Du das denn an den Apache gebunden?

Der Ablauf ist doch eigentlich:

Apache -> Proxy -> FPM (bei PHP-Dokumenten)

und

Apache -> fertig, bei statischen Dingen

Es gibt nur zwei verschiedene Arten, den Proxy einzubinden, die alte Version und die neue. Die alte ist mit "ProxyPassMatch" und die neue, von Apache seit 3 Jahren empfohlene ist "SetHandler". Für ProxyPassMatch gibt es einen Timeout extra, für SetHandler aber nicht.

Zugriffe muss ich nun abschätzen. Also in echt ca. 3 Bots pro Sekunde. Requests an Apache und FPM so an die reell 10-20 pro Sekunde. Durch den Loop eher an die 200 pro Sekunde. Sollte aber kein Problem sein, denn gleicher User, gleicher Pool, wäre da nicht der Loop gewesen und der Pool belegt. Ebenso eben der entsprechende Worker vom Apache. Da waren dann alle mit 800 Slots voll.

Logs: Sagen nix aus, also zumindest PHP5 und PHP-FPM-Log. Da steht nix drinnen. Auffallend nur, dass deren Logeinträge eben auch gut eine Stunde später erst kamen. Im Apache error.log stand nur. Scoreboard is full. Ja, war es auch, alle Slots belegt.

Jetzt aktuell tuckert der Apache, obwohl die Bots noch immer drauf sind, mit durchschnittlich 2 aktiven Slots rum (Loop-Fehler ist beseitigt).

PID Connections Threads Async connections
total accepting busy idle writing keep-alive closing
1443 2 yes 1 24 0 1 1
1463 0 yes 0 25 0 0 0
1473 1 yes 0 25 0 1 0
Sum 3 1 74 0 2 1

Und FPM langweilt sich auch:

process manager dynamic
start time 08/Apr/2018:21:17:16 +0200
start since 64458
accepted conn 15189
listen queue 0
max listen queue 0
listen queue len 0
idle processes 6
active processes 1
total processes 7
max active processes 6
max children reached 0
slow requests 0

Daher die Frage nach dem Timeout, da hätte doch irgendeiner abbrechen müssen / sollen. Kann ja nicht sein, dass ein kleiner Schleifenfehler den ganzen Apache in die Knie zwingt.

Ach ja, die Werte, auch wenn sie das Forum verdammt beschissen anzeigt, unformatiert, sind der ganze Server. Der Ausfall, also die Bots, die sind nur auf einer Domäne.

Hust, ich habe wenig RAM :knueppel: Ich bin halt sparsam. Du weißt, dass man den wiederverwenden kann und nicht entsorgen muss? :yes:

Nee, das war nicht das Problem. RAM waren oder sind jetzt zwar nur 300MB frei, dafür sind 6 GB einfach nur Cache, also nicht in echter Nutzung. Server-Load war auch normal, also bei 0,04.

Der Fehler war schon das Scoreboard. Weil die Prozesse nicht fertig wurden hat der Apache quasi alle Sekunde 1-2 neue Slots gefüllt. Dann waren alle 800 weg. Aber die gefüllten Slots liefen eben in einer Endlosschleife. Da half gar nichts außer ein: service apache2 restart. Dann war alles wieder normal und es füllte sich wieder. 30-60 Min später -> Apache wieder "full".

Ach so, PHP7 macht das nun ohne... Wusste ich nicht

Ok Alex, danke für den Anruf. Habe mich geirrt. Ubuntu ist da in der Tat anders als Debian. Dein FastCgiExternalServer gehört zum Modul mod_fastcgi, das gibt es bei Debian schlicht nicht. Dort gibt es nur mod_fcgi und das ruft so auf:

alt:

ProxyPass unix:/var/run/php5-fpm-domain.com.sock|fcgi://127.0.0.1:9000/var/www/vhosts/http://domain.com/public_html

neu:

SetHandler proxy:unix:/var/run/php5-fpm-domain.de.sock|fcgi://domain.de

Ja nee, also eine Config brauche ich nicht. Hilft mir hier ja nicht weiter, ich suche ja einen Timeout. Auch bei Deiner Funktionsweise muss es ja einen oder mehrere geben.

Du machst wohl was in der Art hier:

<IfModule mod_fastcgi.c>
    SetHandler php7-fcgi .php
    Action php7-fcgi /php7-fcgi virtual
    Alias /php7-fcgi /usr/lib/cgi-bin/php7-fcgi
    FastCgiExternalServer /usr/lib/cgi-bin/php7-fcgi -socket /var/run/php/php7.0-fpm.sock -pass-header Authorization
</IfModule>

Ich mit:

<IfModule mod_proxy_fcgi.c>
        <Proxy "unix:/var/run/php5-fpm-domain.de.sock|fcgi://domain.de">
                ProxySet disablereuse=off
        </Proxy>


        ProxyErrorOverride On


        <FilesMatch ".+\.php$">
                SetHandler proxy:unix:/var/run/php5-fpm-domain.de.sock|fcgi://domain.de
        </FilesMatch>
</IfModule>

Und Debian ist wohl nicht der einzige, der das Modul entfernt hat:

https://beispiel.rocks/www.howtoforge…rnativen.10414/

Das mal so zu den Unterschieden zwischen mod_proxy_fcgi (Debian-Default) und mod_fastcgi (Ubuntu, bei Debian nicht da)

Übersetzung: "Auf der anderen Seite ist mod_fastcgi notorisch schwierig einzurichten und ein Speicher Schwein"

https://beispiel.rocks/serverfault.com/questions/78...mod-proxy-fcgi