XF2.0 FcgidMaxRequestsPerProcess ?

shining

Bekanntes Mitglied
Lizenzinhaber
Registriert
31. Aug. 2018
Beiträge
202
Punkte
83
XF Version
  1. 2.0.5
PHP-Version
7.2
Ich versuche mal hier, eine Lösung für ein Problem zu finden.

Seit ca 2-3 Wochen kommt es in regelmäßigen Zeitabständen (mal stündlich mehrmals, mal alle paar Stunden) zu Fehlern beim Seitenladen/aufbau...

Screenshot 2018-09-10 14.38.20.jpg

> (32)Broken pipe: mod_fcgid: ap_pass_brigade failed in handle_request_ipc function, referer: Example Domain

Ich sage gleich mal dazu: Ich habe von Servereinstellungen etc eigentlich null Ahnung :angelic: (Ja, lacht nur *gg Aber bislang konnte ich für alles selbst die Lösung finden)

Auf der Suche nach der Fehlermeldung bin ich hier gelandet:
Websites are slow and a warning appears in logs: mod_fcgid: ap_pass_brigade failed

Habe "FcgidMaxRequestsPerProcess 500" auch in Plesk in den Apache-Einstellungen eingetragen und der Server neu gestartet. Jedoch taucht der Fehler immer noch auf.

Screenshot 2018-09-10 14.42.50.jpg

Nun meine doofen Fragen :D
Ist der Wert 500 für xenforo vllt zu klein?

Oder kann es vllt hiermit zusammen hängen?
Fixed - Infinite HTTP requests : running AJAX job.php

Den Fix, der dort am Ende genannt wird, habe ich nämlich auch vor ca 2-3 Wochen eingetragen...

Bin aktuell ziemlich ratlos und das nervt mich total, weil das Forum vorher super schnell lief und alle User sehr zufrieden waren.
Bin auch noch nicht dahinter gekommen, wann/warum das auftritt.


Verwendete PHP-Version: 7.2.9 (vielleicht lieber auf 7.1. runter setzen?? )

Infos zum Server (Es liegt nichts auf dem Server außer das Forum und Matomo für die Statistik):
CPU Intel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz (4 core(s))
Version Plesk Onyx v17.8.11_build1708180301.19 os_CentOS 7
OS CentOS Linux 7.5.1804 (Core)

Datenbank-Server
Server: Localhost via UNIX socket
Server-Typ: MariaDB
Server-Version: 5.5.60-MariaDB - MariaDB Server
Protokoll-Version: 10
Benutzer: xxx@localhost
Server-Zeichensatz: UTF-8 Unicode (utf8)

Services
CPU-Auslastung durch Apache 0.1% (von 400%, 4 Kern(e))
CPU-Auslastung durch nginx 0% (von 400%, 4 Kern(e))
CPU-Auslastung durch Mailserver 0% (von 400%, 4 Kern(e))
CPU-Auslastung durch MySQL 0.1% (von 400%, 4 Kern(e))
CPU-Auslastung durch Plesk 0% (von 400%, 4 Kern(e)) 3.47
Speicherauslast. durch Apache 1.5% verwendet (94.4 MB von 6.00 GB) (?)
Speicherauslast. durch nginx 0.1% verwendet (5.17 MB von 6.00 GB) (?)
Speicherauslast. durch Mailserver 0.2% verwendet (10.9 MB von 6.00 GB) 1.01 (?)
Speicherauslast. durch MySQL 5.5% verwendet (336 MB von 6.00 GB) 1.01 (?)
Speicherauslastung durch Plesk 0.5% verwendet (27.7 MB von 6.00 GB) 1.04 (?)
Festplatte
Auslastung Partition "/" 2.2% verwendet (11.0 GB von 492 GB) (?)
Arbeitsspeicher
Reelle Speicherauslastung 15.6% verwendet (961 MB von 6.00 GB)
CPU
Gesamtauslastung 0.2% verwendet (von 400%, 4 Kern(e)) 1.19
Durchschnittliche Auslastung 0.03 Prozesse
Prozesse 54.03 1.05
Ausgeführte Prozesse 0
Blockierte Prozesse 0
Paging-Prozesse 0
Prozesse in Standby 52.62 1.04
Gestoppte Prozesse 0
Zombie-Prozesse 1.41 7.88
 
Hast du mal im Plesk von FastCGI auf FPM umgestellt?
 
Hm ... nö, ist das besser? *duck
Hab bislang immer nur das fastcgi genutzt... vllt verleitet mich das Wort "fast" dazu :angelic:

Danke für den Tipp.. ich werde das heute Nacht mal testen und berichten :D

PS:
Dann noch ne andere doofe Frage:
Muss dann der Passus mit dem FcgidMaxRequestsPerProcess 500 wieder raus?
 
Du hättest auch erst mal schauen können wie deine ScriptExecutionTime steht. Weil in der Fehlermeldung heißt es ja auch das die Laufzeit eines Scriptes die voreingestellte Zeit überschritten hat.

Mal als Beispiel wie es bei mir aussieht..

Screenshot 2018-09-10 17.32.03.png

Muss leider noch mal nachhaken... FPM von Apache oder von Nginx bedient? (beim FastCGI gibts ja nur Apache zur Auswahl)
Wenn du den Apache nutzt dann den nehmen.. ;)
 
Weil in der Fehlermeldung heißt es ja auch das die Laufzeit eines Scriptes die voreingestellte Zeit überschritten hat.

Ja, das ist heute das erste Mal aufgetaucht... Sehe gerade, dass du 256M beim memory-limit hast.. ist der Wert empfohlen?
Bei unserem Server sind da aktuell nur 128M
Dafür ist die execution time höher bei uns...

Und wegen dem Nginx... das hat mein Bekannter, der die Server eigentlich "verwaltet" mal versucht zu erklären. Hängen geblieben ist bei mir nur: Nginx würde der sowieso immer ausführen blabla... FastCGI... blabla :D

Da ich jetzt bei FPM die Qual der Wahl habe (siehe Screenshot), stolper ich wieder einmal drüber.
Generell ist Nginx ja schneller/besser... soviel habe ich auch schon verstanden *gg

Screenshot 2018-09-10 17.44.13.jpg

und wo wir schon dabei sind, hier auch mal die nginx einstellungen

Screenshot 2018-09-10 17.55.06.jpg
 
Ich bin dahingehend auch nur Laie.. ;)

Bei mir gab es bei Plesk mit Apache & NGINX immer nur Probleme, daher habe ich NGINX abgeschalten. :D
 
das hat mein Bekannter, der die Server eigentlich "verwaltet"

Falls nun übrigens jemand über diesen Satz stolpert und sich fragt, warum ich den nicht einfach frage:
Ich will das auch mal selbst hinbekommen und ihm nicht immer auf den Keks gehen :D

Witzigerweise habe ich auf die Art schon Probleme lösen können, die weder er noch der Support des Hosting Anbieters hat lösen können.
Liegt vielleicht daran, das ich mich fest beiße bis ich die Lösung gefunden habe anstatt die Flinte ins Korn zu werfen und sich einfach mit "weniger" zufrieden zu geben.

Ich bin dahingehend auch nur Laie.. ;)
Lol.. bin ich ja nicht der/die einzige hier :D

Also was ich definitiv weiß und bei den zig erstellten Projekten von uns mitbekommen habe: Nginx beschleunigt eine Webseite immens... jedoch liegt da sehr oft die Krux an den Settings.
Insofern bin ich ja verwundert, das dieses Problem nun neuerdings auftritt.
Ich habe es blöderweise anfangs auf meinen PC/Internet geschoben... bis irgendwann Tage/Wochen später mir mitteilten, dass sie auch manchmal Probleme haben.
Nun ist es recht schwer für mich, die Ursache einzugrenzen.
War es ein Update bei pleks, oder das oben genannte Fix für die job.php... oder ein update für eines der genutzten add-on (hier habe ich schon überlegt ob es dass Ads-Manager sein könnte...) oder Matomo (liegt zwar auf eigener Datenbank, jedoch sind die Prozesse dort aktuell auch teils langsam)... grrrr
 
@Kirby Danke für den Hinweis. Daher sagte ich auch das ich Laie bin. ;)
 
@shining
Nö, das sollte einfach ignoriert werden. Aber besser ist immer Ordnung zu halten und zumindest auszukommentieren.
 
Also so wie der Screenshot aussieht werden da 3 Konfigurationen angeboten:

- Apache mit eigenem Management der FastCGI-Prozesse (FastCGI, eignetlich ziemlich veraltete und eher unzuverlässige Technik - sollte man die Finger von lassen)
- Apache in Kombination mit PHP-FPM
- nginx in Kombination mit PHP-FPM

nginx ist bei statischen Dateien auf Grund des Event-Loop signifikant schneller /weniger resourcenhungrig als Apache mit Prefork MPM (insbesondere wenn das dann noch mit mod_php läuft) , bei Apache mit Event MPM ist das schon bei weitem keine sooo klare Geschichte mehr.

Ich würde erst mal Apache mit FPM einstellen und mal schauen was FPM so loggt, da gibt es ja auch diverse Parameter (ondemand/static/dynamic, max prozesse, etc.)
 
Also ich habe es jetzt mal auf "FPM von Apache bedient" umgestellt...
mal schauen... bis jetzt finde ich es flotter als vorher ... manchmal ist einbildung aber auch ne bildung :D
Und nun tauchen neue Fehler auf, die sich aber nicht wirklich bemerkbar machen *lol
AH01068: Got bogus version 243
und
(22)Invalid argument: AH01075
 
Wo findest du diese Fehler? Im Log der Domain im Plesk?
 
Welche Apache-Version läuft da, ist die älter als 2.4.16?
 
Schau mal unter Tools & Einstellungen --> Serverkomponenten und dann such nach httpd ;)

Ich tippe mal auf 2.4.18
 
httpd 2.4.6-80.el7.centos.1

ist das jetzt gut oder schlecht?

Komm mir gerade bissl vor wie bei der Konfiguration meines Neuwagens... keine Ahnung wie es heißt oder ob ich das haben muss... hauptsache ich kann schnell fahren :D
 
Schon ein bisschen älter. Kannst ja mal per Terminal yum update laufen lassen.
 
Zurück
Oben