Entäuscht von der "Root" Server Leistung

    RS 8000 G9 a1 12M

    Single Core : 1026

    Multi Core : 4698


    VPS 1000 G11 12M

    Single Core : 1566

    Multi Core : 4788


    Seit dem unvorangekündigten Umzug wurde die Performance um einiges schlechter bei uns.


    Das wurde nach 22:00 ausgeschickt und 4h später um 02:00 migriert. Es wurde nicht mal die Zeit gelassen, irgendwie darauf zu reagieren:

    Zitat

    um die Stabilität Ihres Systems weiterhin kontinuierlich gewährleisten zu können, ist es dringend nötig, dass wir Ihren Server - RS 8000 G9 a1 12M auf ein anderes Wirtssystem verschieben. Wir führen dies zum Schutz Ihrer Daten und zur Gewährleistung des regulären Betriebs Ihres Servers durch. Die Migration ihres Servers startet binnen der nächsten 24 Stunden. Dabei wird Ihr Server einmalig neu gestartet.

    Wir empfehlen grundsätzlich, Snapshots zu entfernen, wenn diese nicht benötigt werden. Im Regelfall erlaubt uns dies, Ihren Server live umzuziehen, so dass kein Neustart erforderlich ist. In Ausnahmefällen ist es dennoch notwendig, dass wir einen solchen durchführen, dann informieren wir Sie selbstverständlich zuvor, so wie in diesem Fall.

    Vielleicht kann sich "[netcup] Lars S." hierzu auch äußern. Danke.

    Ich hab jetzt nen neues Phänomen beim RS 1000 G11 Ultra beobachet.
    Bei yabs sehe ich bei 4k nach einer gewissen Zeit immer nahezu exakt diese Werte.

    Code
    fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda3):
---------------------------------
Block Size | 4k            (IOPS) 
  ------   | ---            ----  
Read       | 201.71 MB/s  (50.4k) 
Write      | 202.24 MB/s  (50.5k) 
Total      | 403.95 MB/s (100.9k)

    Diese sind nicht schlecht.

    Ein reboot bringt keine Änderung.
    Schalte ich den Server aber aus, so dass ich Ihn über das SCP starten muss, bekomme ich danach oft Werte größer 100k z.B.:

    Code
    fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda3):
---------------------------------
Block Size | 4k            (IOPS) 
  ------   | ---            ---- 
Read       | 301.91 MB/s  (75.4k) 
Write      | 302.71 MB/s  (75.6k) 
Total      | 604.62 MB/s (151.1k)

    Diese nähern sich aber mit der Zeit aber wieder den 100k an.
    Ich verstehe nicht warum das passiert.
    Soll auch kein Meckern sein, ist mir nur aufgefallen und ist reproduzierbar. [netcup] Lars S.

    Ich hab genau das gleiche jetzt wieder bei einem RS 1000 G12 beobachtet.

    Wieder bei 4k die 100.9k nach einer gewissen Zeit.
    Man kanns halt beobachten, dass es immer genau auf den Wert geht.
    Startet man den Server nur neu bleibt es bei genau den 100.9k. Macht man ein Poweroff und startet ihn im SCP neu bekommt man ganz andere Werte

    Ich frage mich halt, warum nicht die ganze Zeit gedrosselt wird, damit es dort nen konstanter Wert gibt?

    Schaut man sich die folgenden IO-Werte für den RS 1000 G12 an, so kann man nicht klagen:

    Zitat von sla

    Den Support habe ich aufgegeben. Man muss jedes Mal Handstände machen um von extern die Hoster-Infra bei Problemen genaustens zu analysieren, mal abgesehen von Späßen wie dem Rettungssystem was richtig Laune macht bei Produktiven Maschinen.

    Selbst wenn man das macht gibt es nur dumme Textbausteine. Das Problem auszusitzen erscheint mir seit einem Jahr sinnvoller als meine Zeit zu verschwenden

    You summed up my experience. :D :D

    When you're asked to boot into the recovery system to test something on a production server.

    And what about when there's a network issue and instability occurs at random, rapid moments, and you're asked to test MTR on the recovery system? Hahaha.

    Imagine leaving the server offline in the recovery system until the problem registers it again? Total madness.

    I was having a packet loss issue between Netcup servers in the same datacenter.

    I logged the issue in Ubuntu's own MTR, but they wanted me to boot into recovery mode to perform the same test.

    Note that the problem occurred at random times and was always rapid.

    To give time for registration in recovery mode, I had to leave the server in recovery mode, running MTR until the problem was registered. This was on a production server. Sometimes it took more than 10 hours for the problem to occur. HAHAHA.

    Luckily, I was able to log the issue in the recovery system. The problem was that it had already been detected and logged in Ubuntu itself.

    Ich habe das Gefühl, daß die meisten Probleme mit den höheren Server kommen. Ich glaube bisher immer nur mit VPS 2000 und RS 2000 solch "schlechte" Werte gehabt zu haben.

    RS 1000 G9.5

    RS 2000 G9.5


    Vergleich zwischen RS 1000 G9.5 und     RS 2000 G9.5

    Server Single-Core Multi-Core Disk-Speed(4k) Disk-Speed(1m)
    RS 1000 G9.5 1073 3299 143.60 MB/s (35.9k) 10.10 GB/s (9.8k)
    RS 2000 G9.5 1080 4510 63.47 MB/s (15.8k) 568.17 MB/s (554)
    Zitat von andreas.

    Schaut man sich die folgenden IO-Werte für den RS 1000 G12 an, so kann man nicht klagen:

    Warte noch ein paar Monate, bis das Wirtsystem überklatscht ist ... Dann bin ich mal gespannt was der 45er an den Tag legt :oooo

    • 🇨🇭 | 🇫🇷 | 🇺🇸
    • sudo rm -rf /*all
    • sudo apt-get reinstall ubuntu.exe
    • ping -6 -c 3 172.16.0.1

    Zitat von SnowBerryZ

    Warte noch ein paar Monate, bis das Wirtsystem überklatscht ist ... Dann bin ich mal gespannt was der 45er an den Tag legt :oooo

    Als ich diese IO-Werte gesehen hatte, habe ich auch so gedacht.

    Momentan habe ich eventuell Glück, da es eher so aussieht, als würden sehr viele Kunden von dieser neuen Generation G12 Abstand nehmen, diesen zu bestellen.

    Weil ich aber diesen Server mit der regulären Kündigungsfrist von einem Monat bestellt habe und es zudem auch kein Produktivsystem ist, kann ich mich von diesen Server auch recht schnell wieder trennen.

    Zitat von andreas.

    Schaut man sich die folgenden IO-Werte für den RS 1000 G12 an, so kann man nicht klagen:

    Ich wollte mal nachfragen, ob Du bei 4k immer noch so viele IOPS hast, ohne den Server auszuschalten und über das SCP neu zu starten?
    Weil bei mir hängt es eigentlich immer exakt nach 24 Stunden bei 4k auf 100.9k.


    War das nen Netcup Image, wo du nen anderen Kernel installiert hast oder komplett selbst über cd installiert?

    Zitat von nitram

    Ich wollte mal nachfragen, ob Du bei 4k immer noch so viele IOPS hast, ohne den Server auszuschalten und über das SCP neu zu starten?
    Weil bei mir hängt es eigentlich immer exakt nach 24 Stunden bei 4k auf 100.9k.


    War das nen Netcup Image, wo du nen anderen Kernel installiert hast oder komplett selbst über cd installiert?

    Heute habe ich nochmal die Messung wiederholt und es sieht so aus, dass nun das IO wie bei den meisten vServern des Typs RS ... G12 auf das Netcup-Normal-IO festgenagelt wurde.

    Zitat von nitram

    War das nen Netcup Image, wo du nen anderen Kernel installiert hast oder komplett selbst über cd installiert?

    Auf den Server habe ich ein eigenes noch vorher optimiertes Image eingespielt.

    Zitat von andreas.

    Heute habe ich nochmal die Messung wiederholt und es sieht so aus, dass nun das IO wie bei den meisten vServern des Typs RS ... G12 auf das Netcup-Normal-IO festgenagelt wurde.

    Ah ok also liegt es nicht an mir, sondern es gibt wohl wirklich eine allgemeine Drossel der IOPS nach einer gewissen Zeit.
    Ich habe vor 5 Tagen dazu nen Ticket aufgemacht um genau das zu Fragen, ob es das gibt.

    Heute die Antwort bekommen ich solls im Rettungs-System testen...

    Ist zwar Server unabhängig aber gut. Er bekommt wahrscheinlich sein gewünschtes Log Morgen mit zu 99,99% dem gleichen Ergebnis, da ich jetzt ja 24 Stunden warten muss bis es passiert, weil ich den Server ja ausschalten musste um ins Rettungs-System zu kommen.

    Ich vermute da wurde mein Ticket mal wieder nicht richtig gelesen und mit einem Textbaustein abgestempelt.

    Wäre halt schön wenn so eine IOPS Drossel klar Dokumentiert ist. [netcup] Sarah G.

    Ich hab irgendwie drei verschiedene RS 2000 G11 und bekomme mit YABS folgende Werte:

    Single Core | 1788

    Multi Core | 8718

    Single Core | 1466

    Multi Core | 7084

    Single Core | 1515

    Multi Core | 7335

    Irgendwie sind die beiden aus einer Aktion doch signifikant langsamer. Das Ticket ist seit 3 Wochen offen bei Netcup :(.

    Mein RS 16.000 G12 ist von der Leistung auch wackelig, die CPU um 5000 Punkte und die IOPS sind mehr als halbiert seit Bereitstellung. Mein G9.5 und mein G11 sind mittlerweile schneller als die neuste Servergeneration, das kann nicht sein.

    Was mir nicht in den Schädel geht: Bei der Beschwerdelage darüber scheint das ja ein globaleres Problem zu sein. Warum wird jeder Kunde stundenlang in das Rettungssystem gezwungen, statt einfach mal auf X Hosts Test-VMs in verschiedenen Größen bereitzustellen? Die Techniker werden ihre eigenen Messergebnisse sicherlich höher gewichten, als die vom Kunden bereitgestellten.

    Wäre ein Win für alle: Kunden bleiben Online während die Techniker genaue Ergebnisse haben. Ebenfalls wäre es sinnvoll hierzu den Support zu informieren, damit man sich einem Sammelticket anhängen kann ohne Textbausteine wie "Prüfen Sie das im Rettungssystem".

    Einmal editiert, zuletzt von sla (10. Oktober 2025 um 11:49)

    Nothing irritates me more than this request to start recovery mode. Any problem, they tell me to start recovery mode. Even problems that don't require recovery mode. It's infuriating. I reported packet loss on a server and opened a ticket. The packet loss occurred in the middle of the night, and they ask me to test in recovery mode. Imagine leaving the server offline for over 12 hours to confirm a problem that was reproduced on Ubuntu itself and confirmed by other independent monitoring systems. It's a complete waste of time. You need to be very patient with technical support. It seems they do this deliberately to make you drop the complaint.