Webseiten laden langsam oder gar nicht (Connection Timeout)

    Werte Community,


    ich bin ein wenig am Verzweifeln.

    Am 1.11.2022 bin ich mit meinem Webportal auf einen Root-Server vom Typ "RS 2000 G9" als Webserver (Debian, ISPConfig3, Apache, MariaDB) umgestiegen, nachdem mein alter Server etwas zu "schwachbürstig" wurde. Eigentlich alles super, die Performance war bis vor zwei Tagen super. Nun habe ich aber wieder ein Problem, das ich bei Netcup in den letzten Jahren leider immer mal wieder feststellen musste und bis heute keine plausible Erklärung oder gar Lösung habe: In unregelmäßigen Abständen ist die Ladezeit meiner Webseite extrem langsam, oder aber sie laden gar nicht und es kommt zu einem "Connection Timeout". Im besten Fall passiert das nur alle paar Stunden einmal, oder - wie jetzt - alle paar Minuten.

    access.log und error.log zeigen keine Auffälligkeiten, keine slow_query_log Einträge, die CPU-Auslastung bewegt sich absolut im Rahmen (< 40%), die Datenbank-Connections liegen bei max. 11.
    Das Problem kann jeweils durch einen Neustart des ApacheServers behoben werden, aber eben immer nur für kurze Zeit.

    Wie eingangs bereits beschrieben, hatte ich das Problem bei Netcup schon einige Male. Oft war es nach einigen Tagen wieder verschwunden (schön, aber dennoch ohne Antwort auf die Frage "warum"), 2x lag es an irgendwelchen DNS-Problemen.

    Daher meine Fragen:

    1.) Hat jemand ähnliche Probleme.
    2.) Was kann/sollte ich noch checken?

    PS: Habe übrigens bereits gestern morgen den Netcup-Support angeschrieben, bis jetzt ohne Antwort. Für Netcup auch untypisch.

    Zitat von mrks

    Das Problem kann jeweils durch einen Neustart des ApacheServers behoben werden, aber eben immer nur für kurze Zeit.

    Aber wenn das hilft, dann ist es ein lokales Problem auf deinem System. Wie sollte sich ein Neustart des Apache Servers auf die Netcup Infrastruktur auswirken? Oder aufs Routing?

    Der Netcup Support wird dir nicht helfen können.


    Übrigens finde ich 40% CPU Auslastung auf einem virtuellen System relativ viel. Da kann es durchaus schon mal haken.

    Zitat von frank_m

    Aber wenn das hilft, dann ist es ein lokales Problem auf deinem System. Wie sollte sich ein Neustart des Apache Servers auf die Netcup Infrastruktur auswirken?


    Ja, das möchte ich auch gar nicht ausschließen. Dennoch die Frage: Gibt es "typische Fehlerquellen" bzw. Komponenten, die die Systemlast negativ beeinflussen?
    Wie gesagt: Ich habe mich primär dem MySQL-Server gewidmet und nach Slow Queries Ausschau gehalten. Die Log-Dateien lassen auch nichts auffälliges erkennen und die 40% sind ein Spitzenwert, den ich einmal kurz gesehen habe. Aktuell:


    Code
    top - 20:19:04 up  1:23,  1 user,  load average: 0.52, 0.51, 0.47
Tasks: 174 total,   1 running, 173 sleeping,   0 stopped,   0 zombie
%Cpu(s): 15.4 us,  3.6 sy,  0.0 ni, 78.9 id,  0.9 wa,  0.0 hi,  1.2 si,  0.0 st
MiB Mem :  16042.4 total,  10924.8 free,   2703.6 used,   2414.0 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.  12982.4 avail Mem


    Und die Frage, die ich mir stelle: Warum ist es immer "nur" ein temporäres Problem, das weder auftritt, wenn die meisten Besucher auf der Seite sind oder nachts, wenn ich einige leistungshungrige Cronjobs durchlaufen lasse.

    Meine erste Vermutung geht Richtung Nameserver, weil ausgelastet oder gar überlastet scheint ja nichts zu sein und es passiert auch nicht (nur) zu den Zeiten, wo viel los ist. Was hast du denn als Nameserver eingetragen? Wenn es die Standard Netcup-Nameserver (Resolver) sind, dann ändere das mal testweise auf Google und/oder Cloudflare oder sonstige öffentliche Nameserver. Die Netcup Nameserver sind bei den Images von netcup voreingestellt. Aber die funktionieren mal ganz normal und dann wieder nicht, eine Stunde später ist wieder alles normal. Das kann sich auf unterschiedliche Arten auswirken. Hat mich anfangs verrückt gemacht, seit ich andere Nameserver/Resolver verwende habe ich keine Probleme dieser Art mehr. Und es scheint ja in letzter Zeit sogar noch schlimmer geworden zu sein wie damals.

    Zitat von tab

    Meine erste Vermutung geht Richtung Nameserver [...] Die Netcup Nameserver sind bei den Images von netcup voreingestellt. Aber die funktionieren mal ganz normal und dann wieder nicht, eine Stunde später ist wieder alles normal. Das kann sich auf unterschiedliche Arten auswirken. Hat mich anfangs verrückt gemacht, seit ich andere Nameserver/Resolver verwende habe ich keine Probleme dieser Art mehr. Und es scheint ja in letzter Zeit sogar noch schlimmer geworden zu sein wie damals.

    Ja, exakt dieses Problem hatte ich vor einigen Jahren schon einmal. Schon länger her.
    Trage ich die einfach im CCP ein?

    Zitat

    nameserver 46.38.225.230

    nameserver 46.38.252.230

    nameserver 2a03:4000:8000::fce6

    Das sind die aktuellen Eintragungen in /etc/resolv.conf - also die Netcup-eigenen.


    Da explizit folgender Hinweis erscheint:


    Zitat

    # NOTE: the libc resolver may not support more than 3 nameservers.

    kann ich wohl keine Nameserver hinzufügen sondern muss die Netcup-Namerserver ersetzen. Welche Nameserver sind denn in welcher Reihenfolge sinnig?
    Google -> 8.8.8.8 und 8.8.4.4? Cloudflare?

    Habe es jetzt mal wie folgt geändert und die Kiste neu gestertet:



    schauen wir mal, ich gebe in ein paar Tagen Rückmeldung.

    Okay, melde mich jetzt schon zurück, da die Nameserver/Resolver wohl nicht das Problem waren. @frank_m hatte wohl recht, die Tatsache, dass ein Neustart von Apache das Problem temporär löst, spricht gegen ein Problem mit der Auflösung.

    Was ich feststelle: In der Apache error.log waren etliche Einträge vom Typ

    Zitat

    [Fri Feb 03 08:16:41.944716 2023] [mpm_event:error] [pid 12966:tid 140624211559552] AH03490: scoreboard is full, not at MaxRequestWorkers.Increase ServerLimit.


    Habe nun das ServerLimit und die MaxRequestWorkers erhöht, seitdem ist das Problem erstmal nicht wieder aufgetaucht. Allerdings habe ich die Änderungen erst vor ca. 45 Minuten umgesetzt. We'll see.