Plesk Apache Fehler

    Hallo Miteinander,


    gefüht seit dem letzten Update auf die aktuelle Plesk Version werfen alle Webseiten nach ewiger Ladezeit den Fehler "504 Gateway Time-out" aus.


    In den nginx Logs finde ich dann folgenden Error:

    [error] 9121#0: *276287 upstream timed out (110: Connection timed out) while reading response header from upstream, client: ...


    Der Apache2 Webserver ist active, in den Logs finde ich dann wiederholt folgendes:

    child process 29790 still did not exit, sending a SIGKILL


    Sobald ich dann den Apache Dienst neu starte, sind wieder alle webseiten online.


    Langsam bin ich mit meinem Latein am Ende, hat jemand von euch eine Idee?


    VG

    Fisi

    So ein Problem hatte ich mit der Plesk-Version Obsidian 18.0.52 vor einigen Monaten auf meinem RS 8000 G9.5 auch.


    Um das Problem zu analysieren hatte ich dann Plesk auf einen deutlich kleineren Dedicated Server aus der Serverbörse bei einem Mitbewerber in einem LXC installiert und den Traffic dann auch auf Diesen umgestellt.

    Da dieses Setup dann auch noch nach mehreren Wochen ohne Probleme lief, habe ich den LXC mit dessen aktuellem Setup dann noch mal auf den RS 8000 G9.5 installiert, womit dann auch die Probleme wieder anfingen.


    Dann habe ich mir mal beide Systeme genauer angeschaut und habe festgestellt, dass bei dem RS 8000 G9.5 laut dem Linux-Befehl SAR das IOWAIT so zwischen 0,05 bis ca. 10 % lag und auf dem Dedicated Server maximal bei 0,01 % lag.

    Der Server bei Netcup wurde dann auch mal auf einem anderen Hostsystem umgezogen, was dann aber gerade mal ca. eine Woche das Problem beseitigt hatte.


    Um dieses Problem noch weiter zu erforschen, habe ich mir dann bei dem Mitbewerber mit dem großen h einen Claud Server angemietet und auf dem dann den LXC mit dem aktuellen Setup installiert bzw. verschoben und auch den Traffic auf diesen umgestellt.

    Auch dort hatte ich durchgehend nur ein IOWAIT von ca. 0,01 % in der Spitze.


    Nun läuft seit einigen Monaten dieses Setup auf einen Cloud Server beim Mitbewerber mit dem großen h und den Server mit der Produktbezeichnung RS 8000 G9.5 hatte ich dann auch schon vor einigen Monaten gekündigt.


    Von daher würde ich mir an deiner Stelle mal das IOWAIT auf dem Server genauer anschauen. Denn das war bei mir das Problem, das es zu solchen Problemen kam.

    Hi Andreas,


    danke für deine ausführliche Antwort! Die IO Werte sind zu den Ausfällen wirklich auffällig, ich werde mich an den Support wenden.

    Grundsätzlich laufen die Server echt stabil, ich hatte noch nie solche Probleme.


    Ich halte euch auf dem Laufenden.


    VG

    Fisi

    Zitat von fisi

    Das war so ziemlich das erste was ich gemacht habe.

    PHP-FPM läuft entweder statisch, dynamisch oder ondemand. Das Gateway-Problem tritt meiner Beobachtung nach gerne einmal bei dynamisch auf. Ein Wechsel auf ondemand kann helfen, oder aber die Anpassung der Prozesse, die gestartet werden.

    Solche mysteriösen PHP-FPM-Probleme habe ich in einer VM unter Proxmox (Homeserver) auch immer wieder, allerdings mit Nginx statt Apache und ohne Plesk. Komischerweise immer nur in dieser VM, die ausschließlich für Nextcloud verwendet wird. Auf anderen Systemen mit deutlich mehr Requests hatte ich das noch nie und ich konnte die Ursache bisher nicht finden. Seit Juli/August experimentiere ich mit den Einstellungen wie von eripek erwähnt. Dass das Problem bei mir nur alle paar Wochen auftritt, macht die Analyse nicht gerade leichter...

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    So sporadische Fehler sind echt Bescheiden. Ich hab 5 identisch konfigurierte Systeme und nur bei dem einen tritt seit neuem der Fehler auf. Nach dem Hinweis mit der IO Performance habe ich das Monitoring kontrolliert, fast immer zur vollen Stunde schießen die Werte durch die Decke. Auf meinem System sind aber keine auffälligen Crons. Die Werte meines Monitorings decken sich auch fast mit dem SCP. Bisher wollte der Support meinen RS auf keinen neuen Host verschieben, mal schauen was da noch kommt.

    Zitat von KB19

    Solche mysteriösen PHP-FPM-Probleme habe ich in einer VM unter Proxmox (Homeserver) auch immer wieder, allerdings mit Nginx statt Apache und ohne Plesk. Komischerweise immer nur in dieser VM, die ausschließlich für Nextcloud verwendet wird. Auf anderen Systemen mit deutlich mehr Requests hatte ich das noch nie und ich konnte die Ursache bisher nicht finden. Seit Juli/August experimentiere ich mit den Einstellungen wie von eripek erwähnt. Dass das Problem bei mir nur alle paar Wochen auftritt, macht die Analyse nicht gerade leichter...

    Manchmal ist die Analyse weniger gefragt, als ein Watchdog.

    Zitat von KB19

    Solche mysteriösen PHP-FPM-Probleme habe ich in einer VM unter Proxmox (Homeserver) auch immer wieder, allerdings mit Nginx statt Apache und ohne Plesk. Komischerweise immer nur in dieser VM, die ausschließlich für Nextcloud verwendet wird.

    Produktiv Nextcloud einer Firma, PHP FPM unter Apache2 (deb.sury.org PHP Repo):


    Code
    pm = dynamic
pm.max_children = 172
pm.start_servers = 43
pm.min_spare_servers = 43
pm.max_spare_servers = 129

    Im LXC Container laufend mit 8 GiB RAM und 4 Kernen - keinerlei Probleme.

    Zitat von H6G

    Produktiv Nextcloud einer Firma, PHP FPM unter Apache2 (deb.sury.org PHP Repo):

    Ich habe (fast) die gleichen Einstellungen wie in der VM auch für eine weitere Nextcloud auf einem netcup RS, dort gibt es keine Probleme.


    Das Sury-Repo verwende ebenfalls, mit welcher PHP-Version betreibst Du die Nextcloud?

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)