Entäuscht von der "Root" Server Leistung

    Zitat von andreas.

    Bezogen auf die Größe des vServers ist das schon ein ziemlich schlechtes Ergebnis, da man beim Mitbewerber aus Falkenstein schon für kleineres Geld (166 Euro) mit sehr kurzer Laufzeit weitaus mehr geboten bekommt, wie folgendes Ergebnis zeigt:

    Meßergebnis vom Produkt EX130-X

    ============================

    Da hat aber jemand kein ZFS Dateisystem oder?

    Aber die Werte sind wirklich gut. Ist das Raid 0 oder Raid 1 oder sogar etwas ganz anderes?

    Reading this entire thread reminded me of the hell I experienced at a well-known German host, starting with "c," where a configuration issue was simply crashing VMs. The company spent a year trying to identify the problem. Servers were crashing on several different hosts, repeatedly for several months, and only months later did they discover that the problem was caused by a configuration error.

    Basically, ZRAM was limiting server memory and causing widespread crashes. Several servers on different hosts were affected. It took months for them to actually figure out the cause. I had over 15 servers on different hosts, and they were all experiencing the same problem.

    I don't know if this problem is intentional or a limitation, but it reminded me of this episode. It took them many months to figure it out, and after they disabled ZRAM, the problems disappeared. Of course, this has nothing to do with this thread, but I remembered how long the problem lasted until they figured out the solution. Some things are really complex.

    Zitat von andreas.

    Es ist ext4 im Software-RAID-Verbund 1.

    Schau dir mal die Taktfrequenz der CPU an, die zum Zeitpunkt der Messung gemessen wurde.

    800.000 MHz bei der CPU, da muss dein Server ja wie eine Sonne im Rechenzentrum glühen ;)

    Mein VPS von den ich eben übernommen habe hat 10 @ 1996.250 MHz .

    Ich glaube die Werte sind nicht ganz aussagekräftig.

    Denke im Leerlauf fährt die CPU die Cores nur mit Minimal Takt.

    Wichtiger ist aber das du echt gute IOPS Werte hast. Zumal du nur Software Raid I nutzt und nicht 10 oder 0.

    Eine Reaktion vom Support vor dem Wochenende:

    Zitat von netcup Support

    vielen Dank für Ihre Anfrage und Geduld.

    Die zuständigen Kollegen sind aktuell dabei, den Sachverhalt gründlich zu untersuchen. Ich bitte noch um ein wenig Geduld. Wir melden uns bei Ihnen, sobald wir Neuigkeiten haben. Danke für Ihr Verständnis.

    Bin gespannt wie lange die Analyse dauert, Ticket liegt seit 6 Werktagen in der Fachabteilung.

    Edit: Den YABS von heute vergessen

    Einmal editiert, zuletzt von sla (24. Oktober 2025 um 18:05)

    Zitat von sla

    Eine Reaktion vom Support vor dem Wochenende:

    Bin gespannt wie lange die Analyse dauert, Ticket liegt seit 6 Werktagen in der Fachabteilung.

    Edit: Den YABS von heute vergessen

    Tja, ich bin zwar kein Hellseher, aber vor Montag wird das sowie nichts.

    Hoffe aber das es bald eine Lösung für dein Leistungsproblem gibt.

    Zitat von sla

    Eine Reaktion vom Support vor dem Wochenende:

    Bin gespannt wie lange die Analyse dauert, Ticket liegt seit 6 Werktagen in der Fachabteilung.

    Edit: Den YABS von heute vergessen

    Normal könnte der Provider netcup das IO-Problem für solche großen vServer recht schnell lösen, indem er für solche vServer dediziert mindestens zwei Datacenter NVME´s im RAID 1 Verbund zur Verfügung stellen würde.

    Zwar kann dann betreffender vServer nicht mehr live migriert werden, aber der Kunde wird damit langfristig glücklicher sein als mit derzeitiger IO-Situation.

    Zitat von andreas.

    Normal könnte der Provider netcup das IO-Problem für solche großen vServer recht schnell lösen, indem er für solche vServer dediziert mindestens zwei Datacenter NVME´s im RAID 1 Verbund zur Verfügung stellen würde.

    Zwar kann dann betreffender vServer nicht mehr live migriert werden, aber der Kunde wird damit langfristig glücklicher sein als mit derzeitiger IO-Situation.

    Personally, I wouldn't trade live migration for better performance.

    Live migration is a differentiator I wouldn't give up.

    Danke für das Teilen eurer Erfahrungen. Habe noch einen RS 2000 SAS *G8* und die IO Performance ist über die letzten Monate immer schlechter geworden. Ist natürlich noch keine SSD. Aber selbst das Aufrufen von simplen Core Linux Binaries dauert beim ersten Aufruf tlw. mehrere Sekunden. CPU ist ok. Habe jetzt auch ein Ticket eröffnet. YABS:

    Einmal editiert, zuletzt von ncdk (27. Oktober 2025 um 08:01)

    Ich lass mal was von heute da.

    sla kann dich trösten, mein achso starker dedizierter stillgelegter RS4000 liegt bei R/W (4k) von glatten sau starken 102 MB/s ...

    Einfach nur noch traurig und wohl gemerkt, der VPS ist komplett zurückgesetzt mit Ubuntu Noble.

    Also kein Rescue System notwendig xD

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

    Mein VPS macht gut 40K IOPS jeweils Read und Write mit 4K Blöcken. Ist auch nicht so viel mehr als hier. Die ca 160 MB/s sehe ich mittlerweile als normal für die netcup VS an und bin froh, wenn das mein VPS erreicht, jedenfalls hatte ich auch schon deutlich weniger. Was hatte denn der RS für Werte als er neu war? Ich glaube mich zu erinnern, dass die zumindest bei G12 deutlich höher waren als bei den VPS G11.

    Zitat von SnowBerryZ

    sla kann dich trösten, mein achso starker dedizierter stillgelegter RS4000 liegt bei R/W (4k) von glatten sau starken 102 MB/s ...

    Einfach nur noch traurig und wohl gemerkt, der VPS ist komplett zurückgesetzt mit Ubuntu Noble.

    Also kein Rescue System notwendig xD

    Wenn es ein RS 4000 G9 oder G9.5 ist, dann würde ich sagen, dass das gemessene IO tatsächlich sehr gut ist, da bis zu dieser Generation noch keine NVMe´s verbaut wurden.

    Und wenn es ein RS 4000 G11 / G12 sein sollte, so würde ich auch sagen, dass das IO-Ergebnis bezogen auf dessen Größe und dessen Preis doch sehr gut ist. Denn man darf nicht vergessen, dass so ein vServer RS 4000 G11 / G12 gegenüber einem RS 16000 G11 / G12 deutlich günstiger ist.

    Ich würde ja jetzt sagen schön das ich nicht alleine bin, so traurig die Situation auch gerade ist. Dennoch kann es nicht sein, dass ein RS 16000 G12 mit einem VPS gleichzieht. Sorry dann braucht man auch keine 140€/Monat ausgeben. Es ist ja nicht das erste Mal, dieser Thread lebt zum zweiten Mal mit gleichem Fehlerbild auf, langsam wirds peinlich

    Zitat von sla

    Ich würde ja jetzt sagen schön das ich nicht alleine bin, so traurig die Situation auch gerade ist. Dennoch kann es nicht sein, dass ein RS 16000 G12 mit einem VPS gleichzieht. Sorry dann braucht man auch keine 140€/Monat ausgeben.

    Ich weiß jetzt nicht, ob du meinen Beitrag richtig gelesen hast. Denn eigentlich meinte ich mit meinem Beitrag #155: Wer mehr für seinen vServer bezahlt, wie in deinem Fall, soll auch mehr IO bekommen und nicht, dass z.B. ein RS 1000 GX genauso viel IO bekommt wie ein weitaus teurer und größerer vServer.

    Zitat von andreas.

    Ich weiß jetzt nicht, ob du meinen Beitrag richtig gelesen hast. Denn eigentlich meinte ich mit meinem Beitrag #155: Wer mehr für seinen vServer bezahlt, wie in deinem Fall, soll auch mehr IO bekommen und nicht, dass z.B. ein RS 1000 GX genauso viel IO bekommt wie ein weitaus teurer und größerer vServer.

    Ist denn der IO-Test überhaupt für Multi-Core ausgelegt? Ansonsten wäre es ja ok, wenn jeder Core gleichviel IO bekommt. Der große Server hat ja "etwas" mehr Cores als mein kleiner VPS 1000 mit seinen 4 vCores.

    Beim GB 6 ist es aber nach meiner Beobachtung während des Tests jedenfalls nicht so, dass da bei jedem Test alle Cores ausgelastet werden - oder überhaupt benutzt. Mein VPS ARM 2000 hat ja einige vCores, da kann ich das gut sehen. In "top" geht der CPU-Wert jeweils bis zu einem Vielfachen von 100%, das ist aber nicht bei jedem Test der selbe Wert. Manchmal ist es etwas weniger -> Steal. Es sieht also für mich so aus, als ob für jede "Disziplin" eine Maximalzahl von benutzten Cores im Test reinkodiert ist und diese Maximalzahl durchaus unterschiedlich ist und bei mir selten alle 10 vCores beteiligt sind. Teilweise sind offenbar auch nur 2-4 vCores beteiligt.

    Absolut gesehen, wenn ich den ARM 2000 (10 vCores) und den x86 1000 (4 vCores) vergleiche, dann gewinnt der kleinere x86 den GB6 Test sowohl Single-Core (sehr deutlich, doppelter Score) als auch Multi-Core :!: (wesentlich weniger deutlich, aber immerhin...)

    Beim fio-Test sieht die Sache anders aus. Selber Test-Aufruf bei beiden vServern, jeweils

    curl -sL https://yabs.sh | bash -s -- -ing

    Der ARM 2000 schafft das in 9 Sekunden, der x86 1000 braucht 23 Sekunden. Allerdings sehen die angezeigten fio-Ergebnisse (IOPS) trotzdem ziemlich ähnlich aus. Vielleicht also doch alle vCores im Einsatz und es werden dann irgendwie die IOPS pro vCore gerechnet?! Der von der CPU-Leistung her langsamer getestete ARM führt den fio-Test wesentlich schneller durch, ist dann aber im Testergebnis ähnlich. Ich schreibe hier bewusst keine absoluten Zahlen rein, die Werte schwanken relativ wild, das kann schon mal 50% Unterschied machen von Test zu Test. Bei beiden lag das Maximalergebnis (4k) aber bei ca 50k IOPS.

    Immerhin, die Testdauer des fio-Tests passt im Vergleich ziemlich genau zu den Zahlen der vCores (9/23 Sekunden, 10/4 vCores)

    Und der Server mit mehr vCores scheint denn doch irgendwie deutlich schneller mit seinen IOs fertig zu sein, obwohl die IOPS Zahlen recht vergleichbar sind. Werden da einfach eine vorgegebene Gesamtzahl von IO Operationen auf alle vCores verteilt und parallel ausgeführt? Und am Ende rechnet man das dann pro vCore um?Dann hätte der Server mit mehr vCores letztlich doch auch entsprechend mehr Ressourcen bekommen beim Zugriff auf den Speicherverbund.

    Also eventuell doch nicht so "ungerecht" wie gedacht. Dass die vCores des ARM eigentlich viel "langsamer" sind, scheint keinen großen Einfluss zu haben, eher gar keinen. So furchtbar viel haben die vCores beim fio-Test eben nicht zu tun. Auch die langsameren vCores warten hier noch die meiste Zeit auf die IO. Schlechte IO-Werte wegen langsamer Cores scheint hier also jedenfalls nicht zuzutreffen.