Metall vs. RS

  • Packe oder entpacke mal mehrere Gigabytes an Daten. Da hakts bei mir. Ich vermute aber, dass es am Host liegt und der ein Speicherproblem hat. Daher möchte ich ja einen Hostwechsel erreichen, um das auszuschließen. Insofern hoffe ich, dass Du z.B. das Problem nicht hast, denn dann wärs eine generelle Limitation statt eines lokalen Host Problems.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

    2 Mal editiert, zuletzt von TBT ()

  • Packe oder entpacke mal mehrere Gigabytes an Daten. Da hakts bei mir. Ich vermute aber, dass es am Host liegt und der ein Speicherproblem hat. Daher möchte ich ja einen Hostwechsel erreichen, um das auszuschließen. Insofern hoffe ich, dass Du z.B. das Problem nicht hast, denn dann wärs eine generelle Limitation statt eines lokalen Host Problems.

    Ich habe eben mal testweise auf einem netcup RS ein 50 GB großes Verzeichnis (mit tar -cz) gepackt.

    Nach einer Viertelstunde habe ich dann abgebrochen. ;) Da war die Archivdatei 20 GB groß.

    Während der ganzen Zeit konnte ich völlig flüssig arbeiten. Sowohl auf der shell als auch in den Anwendungen. Sogar ein Moodlebenchmark ergab normal Werte in dieser Zeit.

    Der tar-Thread lag durchgängig bei ca 90% Last. munin "Utilization per device" zeigt für diese Zeit 92% an. Latency praktisch keine.

    Man hat also gar nicht gemerkt, dass da was im Hintergrund lief.

    (System Ubuntu 20.04, Treiber virtio)

  • Herzlichen Dank für den Test. Bei mir ists ein Windows, daher also etwas anderes. Es würde bei Linux vermutlich um die IO Wait Werte gehen. Ich kenns ja eigentlich auch anders, deswegen versuche ich mit dem Support der Sache auf den Grund zu gehen. Normal ist das bei mir nicht.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

  • Und HEUTE hat der Support meinen RS Fast Rabbit auf ein anderes Hostsystem umgezogen. Und was soll ich sagen: die KISTE RENNT WIEDER!!!! ^^^^:thumbup::thumbup::thumbup::!:


    War also definitiv eine Sache des Hosts und keine allgemeingültige Sache.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

    Ente gut, alles gut 5 Gefällt mir 1
  • Schön, dass das nun behoben ist. :thumbup:


    Was ich mich in solchen Fällen immer frage:

    Betrachtet der Support die Sache dann als erledigt? (Der Kunde, der mit dem Host Probleme hatte ist nun ja zufriedengestellt)

    Oder wird da weiter nachgeforscht, um die Sache grundlegend zu beheben? Das Problem auf dem Host ist ja noch da.

  • Schön, dass das nun behoben ist. :thumbup:


    Was ich mich in solchen Fällen immer frage:

    Betrachtet der Support die Sache dann als erledigt? (Der Kunde, der mit dem Host Probleme hatte ist nun ja zufriedengestellt)

    Oder wird da weiter nachgeforscht, um die Sache grundlegend zu beheben? Das Problem auf dem Host ist ja noch da.

    Das Problem ist dann erledigt.
    Auch wenn es ein RS ist wird es halt bei IO und Netzwerk eng wenn alle gleichzeitig die Ressourcen nutzen.
    Wäre bestimmt interessant, ob es da ein load-balancer gibt der automatisch VM's verschiebt :D

  • Betrachtet der Support die Sache dann als erledigt? (Der Kunde, der mit dem Host Probleme hatte ist nun ja zufriedengestellt)

    Oder wird da weiter nachgeforscht, um die Sache grundlegend zu beheben? Das Problem auf dem Host ist ja noch da.

    Gute Frage. Das Verhalten des vorherigen Hosts ist definitiv nicht normal, fällt aber ggfalls bei weniger datenintensiven Vorgängen kaum oder nicht auf und der Kunde denkt sich halt "ist halt immer so". Von mir haben sie die Info nun, dass der Host ein Problem hat (evtl hat der SSD Controller ja eine fehlerhafte Einstellung oder einen Defekt). Ich würde im Interesse der anderen Kunden hoffen, dass sie etwas tun, evtl haben sie auch schon nachgeforscht und auf Basis des Ergebnisses (Fehler gefunden) mich - und hoffentlich andere - Kunden weggeschoben und den Horsti überarbeitet.


    Ich glaube nicht, dass das ein Overprovisioning Problem ist.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

    Einmal editiert, zuletzt von TBT ()

  • Es gibt ja auch Anbieter von KVM-virtualisierten Servern, die mit dedizierten Ressourcen werben ("Garantierte Festplattenleistung", "Beeinträchtigungen durch Nachbarserver gehören der Vergangenheit an")


    Ich habe mir dort mal einen Server gegönnt und tatsächlich ist die SSD-Performance dort durchgängig konstant gut, ohne punktuelle Einbrüche. Disk-Latenzen praktisch nicht vorhanden.

    Schon nach einem Tag kann ich sagen, dass die dort zwar sehr gut sind, aber ihre Garantien auch nicht durchgängig einhalten können

    Eine interessante Beobachtung habe ich dort gemacht:


    Ich hatte dort ja einen Server getestet und die SSD hat auch gut performt. Kurz danach habe ich noch einen zweiten, kleineren Server dazu genommen und plötzlich gingen die Werte beim (zeitgleichen!) Test bei beiden Servern in den Keller. Und die Graphen auf beiden Servern sind praktisch identisch:

    pasted-from-clipboard.png

    Kann mir keiner sagen, dass diese Korrelation noch Zufall wäre. :/


    Meine Vermutung war: Beide Server liegen auf dem gleichen Host und da der Test (1 GB in 4k-Blocks schreiben und lesen) crongesteuert zu der exakt gleichen Zeit erfolgt, hat das Auswirkungen.

    Ich habe dann mal den job auf einem der Server um ein paar Minuten verschoben und, siehe da, die Performance stieg auf beiden Servern wieder auf gute Werte an. (Die beiden Graphen sind dann auch nicht mehr korreliert) Sobald ich die jobs wieder zeitgleich laufen lasse, geht es auf beiden Servern wieder in den Keller.


    Änderungen auf dem einen Server beeinflussen die Werte auf dem anderen also eindeutig und sehr deutlich!

    So viel zu "Beeinträchtigungen durch Nachbarserver gehören der Vergangenheit an"  ;) (Zumindest bezüglich SSD)