Download Speed from PROD vServer ist sehr langsam

    Hallo zusammen,


    seit Tagen treibt mich ein Thema um, dass ich nicht in den Griff bekomme.


    Ich habe zwei Server bei netcup. PROD: VPS 1000 G10 12M, TEST: VPS 1000 G9 12M. Beide sind ähnlich aufgesetzt, eine docker-compose Umgebung für den Betrieb von ein paar wenig genutzten privaten Dienste, wie Mailu E-Mail Server, Nextcloud, eine kleine Weppage, MariaDB, phpMyAdmin. Alles läuft stabil und ich habe mich seit Wochen nicht mehr groß drum gekümmert.

    PROD-Server für den realen Betrieb. TEST-Server fürs testen und ausprobieren und Übernahme dann auf PROD-Server.


    Die Tage ist mir aber aufgefallen, dass der Download vom PROD-Server zu meinem Home-Environment (ISP Unitymedia/Vodafone, 250Mbit/s Download, 12 Mbit/s Upload) sehr langsam ist, ca 300KB/s.

    Dies aber nur vom PROD-Server! Alle anderen Download-Speeds (vom TEST-Server, Linux Image von Ubuntuusers.de, etc.) sind ok und ich kann bis max. ca. 25MB/s runterladen.

    Dies kann ich auf verschiedenen Clients (Fedora Desktop, iPhone, Tablet, Notebook) in meiner HOME-Umgebung reproduzieren. Wechsele ich zu einem WLAN Hotspot über iPhone (Telekom.de 5G) ist auch der Download vom PROD-Server sofort ok, ca. 5MB/s. Download vom Büro-Laptop über Nextcloud vom PROD-Server ist auch maximal.


    Download-Speed prüfe ich gegen den PROD-Server mit scp, FileZilla und Daten aus der Nextcloud, bei allen ist der Download-Speed ca. 300KB/s für den PROD-Server, aber nur im HOME-Environment und nur beim PROD-Server!


    Ich habe auch schon alles abgeschaltet und es auf mein Desktop-Rechner mit Fedora zu isolieren. PROD-Server und ISP Router habe ich auch rebootet.

    Ich habe mal mit yabs auf dem PROD-Server geprüft:


    Aus meiner laienhaften Sicht, sieht dies ok aus, so dass ich erstmal auf einen weiteren Test im Rettungssystem verzichtet habe.


    Mit mtr habe ich dann weiter auf meinen Fedora Client gegenüber dem PROD-Server geprüft.


    Hier bin ich zu sehr Laie um dies zu interpretieren. Mich wundern aber die Verluste bei _gateway. Und (waiting for reply) hat keine Ausgabe.


    Scheinbar verstehen sie die beiden IPs nicht, vom PROD-Server zum ISP und nur für den Download!


    Für jede Hilfe bin ich dankbar.


    Toto12

    Was nutzt du primär für deine Downloads? IPv4 oder IPv6?

    Stehen die Server in unterschiedlichen Rechenzentren?


    Welche Festplatten-Treiber sind im SCP für die Server jeweils eingestellt?

    Wahrscheinlich hat Unitymedia/Vodafone mal wieder ein kleines Problem, was mich als langjährigen Unitymedia-Kunden nicht weiter überraschen würde, obwohl es seit der Übernahme durch Vodafone gefühlt deutlich besser/stabiler geworden ist. Was ist _gateway? Eine Besonderheit deiner Umgebung? Bei mir steht da die interne IP meines Routers (192.168.0.1), danach kommt dann gleich der ip-081-210. Bei dir scheint also noch was dazwischen zu sein.

    IP

    PROD-Server und TEST-Server sind beide auf IPv4 im SCP | Netzwerk eingestellt.


    Festplatten-Treiber

    PROD-Server steht im SCP | Medien | Festplatte | Treiber auf VIRTIO und TEST-Server auf SCSI, also unterschiedlich. Warum dies so ist weiß ich nicht. Ich habe da nichts absichtlich geändert.


    Danke fürs kümmern.

    Quote from tab

    ...Was ist _gateway? Eine Besonderheit deiner Umgebung? ...

    Da bin ich zu wenig Experte, um dies genau zu sagen. Keine Ahnung woher dies kommt und was dies ist. Ich habe dies heute auch zum ersten Mal gesehen. Es kommt aber auch bei mtr auf den TEST-Server und der lädt ja performant zu meinem HOME-Environment.


    Ich habe seit Jahr und Tage eine Pi.Hole auf einen Raspi laufen. Dahin stelle ich dann in meinen Clients die Ethernet/Internet Verbindung für IP4 DNS manuell ein. Ich hatte den Raspi aber auch schon komplett ausgeschaltet und die DNS Einträge wieder auf Automatisch gestellt, also DNS Bezug über Unitymedia/Vodafone. Den PROD-Server hatte ich vor ca. einem halben Jahr aufgesetzt und damals habe ich mich über den flotten Download gefreut. Es hat also mal funktioniert. Für die DNS über den Raspi habe ich auch etwas in der Unitymedia ConnectBox eingestellt. Was genau muss ich mal in meinen Unterlagen suchen. Ggf. deaktiviere ich dies dann auch mal. Seltsam ist es aber, dass der Download vom älteren netcup TEST-Server performant läuft.


    Ein weiterer Unterschied ist, dass ich auf dem PROD-Server ein fail2ban laufen habe, auf dem TEST-Server aber nicht. Die Services schalte ich beim TEST-Server nur ein, wenn ich sie brauche. Den fail2ban hatte ich auf dem PROD-Server auch schon deaktiviert. Gleiches Ergebnis, langsamer Download, Upload ok.

    Vielleicht hängt es auch mit den unter "netcup Status" angedrohten Netzwerk-Wartungsarbeiten heute Abend zusammen. Macht man ja nicht zum Spass, irgendwas wird im Argen sein.

    Ich würde das trotzdem mal im Rescue System testen ob dort ebenfalls der Effekt (langsamer Up- und Downloadspeed) Auftritt.


    Habe bei einer meiner Failover IP´s seit ca. einer Woche ein ähnliches Problem. Ebenfalls aus dem Netz von Vodafone zu Netcup.

    Das Verrückte daran ist das es wirklich nur eine einzige meiner Failover IP´s betrifft. Auch wenn ich die IP Adresse einem anderen meiner Server zuweise ist der Download bei nur ca. 100 KB/s. Bei allen anderen Failover IP´s ist die Geschwindigkeit absolut normal.

    Habe wegen diesem Problem bereits seit dem 23.01. ein Ticket bei Netcup offen, jedoch konnte der Support das Problem noch nicht finden.

    Eventuell helfen ja die Netzwerk-Wartungsarbeiten die Netcup heute Nacht durchführen will. Netzwerk-Wartungsarbeiten-am-26-01-2023

    Quote from Toto12

    PROD-Server und TEST-Server sind beide auf IPv4 im SCP | Netzwerk eingestellt.

    Dort kann man nicht einstellen, welches Adressfamilie benutzt wird. Haben die Server je eine IPv4 und Ipv6 Adresse?

    Das musst du bei den Servern selbst gucken. Ebenfalls welche Records sind im DNS hinterlegt.


    Macht es im Client einen Unterschied, ob du mit sftp -4 oder mit sftp -6 herunterlädst?

    Die Geschwindigkeiten zwischen Server und Client kannst du auch mit iperf3 testen.

    Quote from H6G

    Dort kann man nicht einstellen, welches Adressfamilie benutzt wird. Haben die Server je eine IPv4 und Ipv6 Adresse?

    Das musst du bei den Servern selbst gucken. Ebenfalls welche Records sind im DNS hinterlegt.


    Macht es im Client einen Unterschied, ob du mit sftp -4 oder mit sftp -6 herunterlädst?

    Die Geschwindigkeiten zwischen Server und Client kannst du auch mit iperf3 testen.


    Alle DNS Einträge zeigen auf die IPv4. Ebenso die rDNS im SCP | Netzwerk. Für IPv6 habe ich nichts für beide Server eingetragen.

    sftp -4 -P myPort myUser@TESTdomain.de:myBigFile .

    Download by 25MB/s


    sftp -4 -P myPort myUser@PRODdomain.de:myBigFile .

    Download by 300KB/s


    sftp -6 -P myPort myUser@TESTdomain.de:myBigFile .

    sftp -6 -P myPort myUser@PRODdomain.de:myBigFile .

    zeigt

    ssh: Could not resolve hostname XXXXdomain.de: Name or service not known


    Wechsele ich von ISP/Ethernet auf iPhone Hotspot/WLAN habe ich bei beiden einen Download von 2MB/s.


    Download im aktivierten Rettungssystem ebenfalls beim PROD-Server bei 300KB/s zum Fedora Client.

    Noch etwas: Beim Login auf dem PROD-Server erscheint eine Meldung

    There is 1 zombie process



    Mit Google Recherche:

    ps axo stat,ppid,pid,comm | grep -w defunct

    sehe ich folgenden Prozess:

    Z 1431 3292 rsyslogd <defunct>



    Ist dies etwas worüber ich mir Sorgen machen muss?


    Als OS habe ich Ubuntu 20.04.5 LTS auf dem PROD-Server. Auf dem TEST-Server Debian GNU/Linux 10 (buster)

    Alles aktuell mit apt update/upgrade.

    Quote from Toto12

    Ja gerade nochmals rebootet und der Zombie Prozess rsyslogd ist wieder da.

    Guck mal im Journal, ob irgendwelche Fehler auftauchen journalctl -xe und journalctl -k - ist natürlich ungünstig, dass da der Prozess aussteigt, der fürs Logging verantwortlich ist.


    Normalerweise ist ein Zombie Prozess kein Problem, wurde halt vergessen einzusammeln. Sollte aber nicht 2x so kurz nacheinander auftreten.

    Was läuft so auf der Kiste?


    Schick mal den Output von ps -aux

    "_gateway" ist einfach nur der Name, mit dem dein lokaler DNS Server deinen Router per reverse DNS auflöst.


    95% Paketverluste zum Gateway sind aber definitiv nicht gut. Was passiert, wenn du direkt deinen Router mit mtr ansprichst? Was passiert bei anderen Zielen (z.B. Google)? Was passiert bei IPv6 Zielen?


    Quote from Toto12

    Ja gerade nochmals rebootet und der Zombie Prozess rsyslogd ist wieder da.

    Wie gesagt, nicht gut. Da es bei Ubuntu standardmäßig nicht passiert, dass der rsyslogd als Zombie endet, muss es wohl deine Konfiguration sein. Das wird vermutlich mit dem Bandbreitenproblem nichts zu tun haben, aber lösen solltest du es trotzdem.

    Quote from frank_m

    95% Paketverluste zum Gateway sind aber definitiv nicht gut. Was passiert, wenn du direkt deinen Router mit mtr ansprichst?

    Eigentlich nicht Aufgabe vom Router auf ICMP Echo Pakete ständig zu reagieren.

    Der Ping vom 2.2 ms zum Router ist aber schon etwas hoch.

    WLAN? Oder Draht mit Switchen dazwischen?


    Schonmal die Switche und den Router für 30s vom Strom genommen und neugestartet?

    Journal habe ich mal laienhaft durchgeschaut, ca. 1.500 Zeilen. Keine roten Zeilen.


    Betriebssystem mäßig habe ich da nicht großes installiert: docker, docker-compose, fail2ban, vim. Meine Installation habe ich komplett in Docker realisiert.

    Diese erst auf dem TEST-Server und dann auf dem PROD-Server eingespielt.

    Ab und zu mal ein apt update/upgrade.


    fail2ban habe mal deaktiviert, bringt aber das gleiche Ergebnis. Download zum HOME-Environment bei 300KB/s. Seltsam ist ja, dass der Download zu anderen IP performant ist, z.B. wenn ich z. B. über den Hotspot gehe. In meiner HOME-Umgebung sind die Downloads zu anderen Server auch performant. Nur die eine Verbindung Download PROD-Server zum HOME-Environment ist langsam, egal ob im normalen oder im Rettungssystem. ps-aux.txt im Anhang.

    Quote from Toto12

    Journal habe ich mal laienhaft durchgeschaut, ca. 1.500 Zeilen. Keine roten Zeilen.

    Kein Wunder. rsyslogd verabschiedet sich ja auch. Wie soll er da noch was loggen? Oder nutzt du systemd?


    Wie gesagt, deine Download Probleme vermute ich eher im Heimnetz. Mach die mtr Tests, die ich oben beschrieben habe.