Aktuelle Benchmarks RS / VPS Produkte

    Zitat von tab

    Welche IOWait-Probleme hattest du denn?

    Ich habe eine relativ "aktive" Datenbankanwendung und letzte Woche hatte Postgres ohne erkennbaren Grund immer langsamere Queries. Stellenweise war die CPU auf 100%, aber nur mit IOWait-Last. So 3% IOWait sind im Schnitt mal normal, aber hier waren es teilweise 20% im Durchschnitt eines Tages.

    Ich habe den Server vor einer Stunde mal komplett neugestartet, da der Support Benchmarks angefordert hat und bisher sieht es wieder besser aus. Muss ich mal noch eine Weile beobachten. Am besten wären natürlich trotzdem 0% IOWait, falls das mit den Root Servern wahrscheinlicher erzielbar wäre (?).

    Könnte sein, dass wir das gleiche IO-Problem haben? Schau mal hier.

    Meine IOPS sind von 32000 auf 800 runter, meine Datenrate von 1,7 GB/s auf 5MB/s, der Server praktisch nicht mehr zu gebrauchen. Allerdings habe ich einen Root-Server.

    Mir sind die Probleme Mittwoch aufgefallen und ich versuche es seit dem zu Debuggen. Der Support wollte von mir einen yabs im Rettungssystem haben, funktioniert allerdings nicht richtig. Das Rettungssystem hat keine funktionierende DNS Auflösung und (nach Beheben dieses Problems) meine Festplatte zu wenig freien Speicher (da LUKS verschlüsselt) um den fio Disk Speed von yabs auszuführen.

    Ein Reboot (vor dem Gewurschtel mit dem Rettungssystem) hat keine Besserung gebracht, das Aus- und wieder Einschlaten dann schon. Ich dachte erstmal super, Problem gelöst, aber nach ca. 10-12 Stunden war es dann wieder unbenutzbar.

    Da ich meinen Server schon vor 8 Jahren aufgesetzt habe, war der HDD-Treiber noch auf SCSI (war ein Server mit SAS Platten und damals so voreingestellt) und ich hatte auch einen Snapshot.

    Ich habe jetzt mal den Snapshot gelöscht, den Treiber auf virtio umgestellt (war ein bisschen Bastelei, da der erstmal nicht gebootet hat) und dann hat mir das SCP mitgeteilt, dass meine Festplatte in einem veralteten Format ist und geändert werden muss.

    Ich werde weiter beobachten und hoffe, dass es das nun war...

    Wie sieht das bei Dir aus? Festplatte recht voll oder verschlüsselt? Ggf auch SCSI-Treiber? Snapshots?

    Zitat von SiebenG

    Mir sind die Probleme Mittwoch aufgefallen und ich versuche es seit dem zu Debuggen. Der Support wollte von mir einen yabs im Rettungssystem haben, funktioniert allerdings nicht richtig. Das Rettungssystem hat keine funktionierende DNS Auflösung und (nach Beheben dieses Problems) meine Festplatte zu wenig freien Speicher (da LUKS verschlüsselt) um den fio Disk Speed von yabs auszuführen.

    Zum Nachstellen bzw. zum Teststen könntest du auch Local Block Storage (LBS) von 50 GB zu unter einem Euro pro Monat zum Server dazu bestellen.

    Das Problem mit der DNS-Auflösung im Rettungssystem hatte ich auch, aber lies sich dann lösen über die Netzwerkkonfiguration über das grml-Menü. Sollte wer bei Netcup vielleicht ins Wiki aufnehmen, vor allem, wenn man mit der Distro noch nie gearbeitet hat. Disk Speed konnte ich wegen Verschlüsselung auch nicht testen.

    Zitat von SiebenG

    Ein Reboot (vor dem Gewurschtel mit dem Rettungssystem) hat keine Besserung gebracht, das Aus- und wieder Einschlaten dann schon. Ich dachte erstmal super, Problem gelöst, aber nach ca. 10-12 Stunden war es dann wieder unbenutzbar.

    Nach meinem Reboot heute hat sich das Ganze erst mal beruhigt. Die Ursache konnte ich jetzt aber nicht wirklich nachvollziehen. Der Server hatte auch nur eine Uptime von 14 Tagen oder so, also ist jetzt nicht so, als wäre der monatelang durchgelaufen.

    pasted-from-clipboard.png

    Der Server ist erst circa ein Jahr alt mit SSD und Virtio-Treiber.

    Zitat von DatAres

    Disk Speed konnte ich wegen Verschlüsselung auch nicht testen.

    Okay, also Verschlüsselung ist der gemeinsamme Nenner. D.h. bei Dir ist auch die Festplatte voll laut SCP?

    Bei mir steht da:

    Code
    Speichernutzung vda: 302 GiB von 240 GiB belegt

    Ist eigentlich auch seltsam, wenn man mal so drüber nachdenkt ...240 GiB stimmt aber, laut Vertrag und meine vda ist auch so groß.

    Zitat von SiebenG

    Das Rettungssystem hat keine funktionierende DNS Auflösung und (nach Beheben dieses Problems) meine Festplatte zu wenig freien Speicher (da LUKS verschlüsselt) um den fio Disk Speed von yabs auszuführen.

    Denkst du der Support würde den Test auf einem verschlüsselten Dateisystem akzeptieren?

    Schließlich kann es ja auch an den Komponenten der Verschlüsselung liegen. Gerade wenn das System 10 Jahre alt ist...

    Zitat von SiebenG

    Ist eigentlich auch seltsam, wenn man mal so drüber nachdenkt ...240 GiB stimmt aber, laut Vertrag und meine vda ist auch so groß.

    Die Anzeige ist normal bei verschlüsselten Systemen, damit Dateigrößen bzw. genutzte Blöcke nicht an das Hostsystem geleaked werden. Bei Bedarf kannst du einen manuellen Trim machen und den Speicher übers SCP optimieren, dann stimmt die Anzeige (zumindest eine Zeit lang) wieder.

    Solche Performanceprobleme sollte das aber trotzdem nicht auslösen. Ich hab auch noch einen 7 Jahre alten VPS mit SAS und noch nie solche Probleme gehabt. Dort laufen aber auch keine allzu ressourcenintensiven Sachen.

    Also für Freitagnacht, scheint mein RS4000 ausnahmsweise echt mal abzuliefern mit einem Single-Core-Score von 1,8k und einem Multi-Core-Score von 12k :ooooo

    Sind etwa auf meinem Wirtsystem alle ausgeflogen und auf den Mond geflüchtet zu SpaceX? :D

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

    Zitat von DatAres

    Bei einem RS sollte die CPU doch immer gleich abliefern, da dediziert? Gibt es bei Netcup jetzt überhaupt irgendwas Dediziertes? Ich gehe aus dem Thread mit mehr Fragen raus, als ich reingekommen bin ?(

    Also der Hauptunterschied zwischen VPS und RS ist, dass beim VPS mehr Kerne pro Knoten verkauft werden, als da sind. Das könnte sich negativ auswirken, indem Dir jemand anders Teile "Deines" Kerns belegt, Das erkennst Du daran, ob Dein VPS einen "CPU Steal" hat, die gelbe Kurve in Deinem Plot bzw. im "top" der Wert "st". Falls der bei Dir hoch ist, könnte sich ein Wechsel auf einen RS lohnen.

    Zweiter Unterschied ist, dass beim RS beim Kauf eine garantierte CPU angegeben ist (derzeit EPYC 9634 == Zen4 Architektur), meist die neuste Generation. Beim VPS ist es ein Lotteriespiel, kannst Glück haben, kannst aber auch auf einem bisschen älteren Server landen. Was ich so im Forum lesen, haben VPS derzeit zwischen Zen2 und Zen4 alles dabei (Rome, Milan, Genoa). Will sagen: also neben geteilter CPU auch mindestens eine CPU Gerneration älter. Zen4 schein im Single Core Benchmark grob 100% schneller zu sein als Zen2.

    Zu Deiner Frage, warum beim RS Benchmarks schwanken: Zum einen gab es hier wohl vor kurzen eine Konfigurationsänderung beim RS G11, da wohl einige mit der Leistung nicht zufrieden waren und es wohl jetzt besser laufen soll. Zum zweiten können Benchmark-Leistungen auch auf dedizierten RS-Kernen auch Schwanken, tun sie aber selten. Single-Core sollte weniger Schwanken als Multi-Core. Ich habe bei meinen RS auch schon 20% Einbußen im SingleCore gesehen, ist aber wirklich selten (kein steal). Warum? Trotz dediziert zugewiesenen CPU Kern teilst Du Dir einige Komponenten mit anderen Usern, insbesondere die Speicherbandbreite und auch den L3-Cache. Lastet das jemand anders gerade aus, hast Du auch beim RS weniger Performanz. Als drittes gibt es auch noch bei modernen CPUs den sog. "Turbo" Modus, d.h. die können für kurze Zeit (60 Sekunden oder so) extrem stark Hochtakten. Falls Du jetzt einen Benchmark machst und "zufällig" diesen Turbo-Modus erwischt, bekommt Du auch überdurchschnittliche Ergebnisse...

    Zitat von SiebenG

    Ich werde weiter beobachten und hoffe, dass es das nun war...

    Ich habe mich leider zu früh gefreut. Nach genau 47 Stunden uptime tritt das Problem erneut auf, auch mit virtio.

    Was ich aber jetzt weiß, es kommt plötzlich.

    Hier mein fio Test von 11:47 Uhr:

    Und hier mein Test von 12:47 Uhr:

    Und ja, da steht wirklich KB/s. Und ja, da steht tatsächlich auch 0 IOPS. Der erste Test lief übrigens 34 Sekunden, der zweite 35 Minuten.

    DatAres ich habe genau das gleiche beobachtet wie Du, das wait des Prozesses ging auf 98% hoch.

    Hat noch irgendjemand eine Idee, was ich tun könnte (außer alle 12 Stunden neu zu booten)?

    Meine IOWaits haben fast genau 24 Stunden nach dem Reboot Ein-/Ausschalten auch wieder angefangen. Beim Generieren des fio-Testfiles hat der Server für 2 Minuten auf überhaupt keine Eingaben mehr reagiert. Ich denke ich werde später mal eine Speicheroptimierung durchführen, vielleichts bringts ja was.

    SiebenG Benutzt du zufälligerweise auch Ubuntu 24.04.3 LTS? Vielleicht gab es ja wirklich eine softwarespezifische Änderung in einem Update.

    Hmm. Also wenn ich ein Problem habe, das sich regelmäßig durch einen Reboot vorübergehend lösen lässt, dann würde ich als erstes vermuten, dass ich mir an irgendeiner Stelle einen Knoten ins System konfiguriert habe und anfangen danach zu suchen. Ok, vorher würde ich noch versuchen, ein Problem meiner Installation auszuschliessen durch Tests im Rettungssystem. Tritt das Problem auch da auf, dann ist der Fall klar und der Ball liegt in der Hälfte von netcup. Das erspart mir dann die aufwändige Suche in meinem System. Tritt das Problem da nicht auf, dann erspart es eben netcup eine aufwändige Suche. In beiden Fällen eine gute Sache. Es hat nur der den großen Aufwand, auf dessen Seite das Problem auch tatsächlich liegt.

    Aber wieso sollte ein Problem im Speicher sich durch einen Reboot lösen lassen? Ich stelle nicht in Frage, das es in letzter Zeit durchaus relativ heftige Probleme mit der File-IO gab und auch immer noch geben kann, aber dass die dann nach einem Reboot 12 Stunden wie weggeblasen sind, ist - jedenfalls für mich - relativ schwer zu verstehen.

    Ich hatte auf einem VPS auch IO-Probleme, aber die liessen sich nicht einfach mit einem Reboot vorübergehend lösen, ein Reboot hat da gar nichts geändert. Und 0 IOPS hatte ich auch nie. Auch das Löschen aller Snapshots und eine anschliessende Speicheroptimierung hat nichts gebracht. Die Probleme waren erst weg, als netcup seine Änderungen gemacht hatte. Danach war dann allerdings auch noch ein Reboot per SCP notwendig, damit die Werte wieder im Normalbereich waren. Aber vorher hat bei mir ein Reboot, auch per SCP, jedenfalls rein gar nichts gebracht.

    2 Mal editiert, zuletzt von tab (16. August 2025 um 14:21)

    Definitionsfehler von mir: Der Fehler lässt sich durch einen Reboot nicht beseitigen. Nur mit einem Ein- und Ausschalten des kompletten Servers. Ein Reboot bekommt das Hostsystem soweit ich weiß ja nicht mit, aber ein Ein-/Ausschalten schon. Würde daher ja schon dafür sprechen, dass sich auf dem Hostsystem in dem Moment etwas ändert.

    Zitat von DatAres

    SiebenG Benutzt du zufälligerweise auch Ubuntu 24.04.3 LTS? Vielleicht gab es ja wirklich eine softwarespezifische Änderung in einem Update.

    Nein, ich bin auf Debian 12, Kernel 6.1.0-38. Ich hatte beim ersten Auftreten des Problems ja auch noch den SCSI konfiguriert, (virtio/virtio_blk gar nicht verwendet), daher vermute ich weniger eine OS-Problematik.

    Wäre super, wenn Du das Ergebnis Deiner Speicheroptimierung teilst, gerne auch mit Auslastungswerten Deiner vda vorher/nachher im SCP.. Ich habe das noch nie gemacht, nach meinem Verständnis würde das bei einer Vollverschlüsselung auch nichts bringen, da aus Sicht des Hosts halt einfach alle Blöcke belegt sind.

    Meine Vermutung ist, dass sie ihre Filesysteme auf dessen Hosts so stark überbucht haben, so dass nicht alle ihre Kunden auf dem betroffenem Filesystem das zugeteilte Kontingent ihrer virtuellen Platte zu 100% nutzen können.

    Denn der Kunde sieht bei sich auf dem vServer nur, dass er eventuell noch 10% auf seiner virtuellen Platte frei hat, aber das Hostsystem des Providers sieht dies zwar auch - auch wenn die virtuelle Platte verschlüsselt sein sollte, aber sieht auch noch weiterhin auf dessen Filesystem, das der Speicherplatz auf dessen Filesystem nicht mehr reicht und drosselt infolgedessen zum Schutz des eigenen Filesystems die Bandbreite bzw. das IO der virtuellen Platte drastisch runter.

    Zitat von DatAres

    Definitionsfehler von mir: Der Fehler lässt sich durch einen Reboot nicht beseitigen. Nur mit einem Ein- und Ausschalten des kompletten Servers. Ein Reboot bekommt das Hostsystem soweit ich weiß ja nicht mit, aber ein Ein-/Ausschalten schon. Würde daher ja schon dafür sprechen, dass sich auf dem Hostsystem in dem Moment etwas ändert.

    Ja, das ist bei mir genauso. Reboot bringt nichts, nur Aus- und wieder Einschalten.

    Ich habe jetzt mal meine ganze SSD vollgeschrieben, bis es nicht mehr geht, um zu sehen, ob dies das Problem triggert, dem ist aber nicht so.

    Vor dem Vollschreiben im SCP: vda: 302 GiB von 240 GiB belegt

    Nach dem Vollschreiben: vda: 343 GiB von 240 GiB belegt

    Mehr als 240GiB gingen aber nicht auf die Platte. fio Disk Speed hatte danach völlig normale Werte...

    Zitat von DatAres

    Definitionsfehler von mir: Der Fehler lässt sich durch einen Reboot nicht beseitigen. Nur mit einem Ein- und Ausschalten des kompletten Servers. Ein Reboot bekommt das Hostsystem soweit ich weiß ja nicht mit, aber ein Ein-/Ausschalten schon. Würde daher ja schon dafür sprechen, dass sich auf dem Hostsystem in dem Moment etwas ändert.

    Gut. Dann wäre ein Versuch im Rettungssystem immer noch hilfreich. Ansonsten, du schreibst seit letzte Woche. Ich habe jetzt nicht geschaut, wann netcup seine Änderungen genau ausgerollt hat, denke aber um den Dreh oder kurz davor. Könnte (muss aber nicht) also was damit zu tun haben. Zudem benutzt ihr beide Vollverschlüsselung, was wie SiebenG schrieb für den Host so aussieht, als seien alle Blöcke belegt. Vielleicht war die Änderung von netcup ja für solche Systeme nicht ganz optimal (gelinde gesagt).