ich beobachte ein seltsames Verhalten beim Upload eines erstellten Image auf den Server.
Virtualisiert mit XCP-ng 8.2
Folgendes passiert:
Erstelle ich auf einem Client ein Image und lade es hoch, dann beginnt der Upload mit einer den Netzwerkkarten passenden Übertragungsrate von ca. 100MB/s (mit zwei unterschiedlichen Clients getestet). Danach fällt die Übertragungsrate stark ab. Zeitweise liegt die Übertragungsrate unter 1 MB/s. Die Übertagungsrate steigt auch mal wieder über 50 MB/s, aber liegt meist zwischen 1 MB/s und 20 MB/s.
Beim Upload sieht es anders aus. Da erreicht die Übertragungsrate dauerhaft zwischen 300 und 400 Mbit/s
Ich habe folgendes getestet:
Zwei unterschiedliche Clients mit unterschiedlichen Netzwerkkarten (keine Änderung)
Netzwerkleitung getauscht
Switch getauscht
Auf dem Server habe ich alle Stromsparmaßnahmen abgeschaltet.
Wenn es deterministisch zu Beginn funktioniert und dann langsam wird, würde ich die Netzwerk-Hardware erstmal garnicht in Betracht ziehen.
Ich würde auf dem Server die IO-Last betrachten. Was tut der Prozess, der da schreibt zu Beginn, was, wenn es langsam wird? Ich finde atop ist ein nettes Tool dafür (‚d‘ zeigt Disk-Aktivitäten an).
Du könntest auf dem Server einmal eine ähnlich große Datei kopieren (zB per dd of=out.img if=in.img status=progress) und dir so die IO-Geschwindigkeit anzeigen lassen und schauen, ob die heruntergeht.
P.S.: Du schreibst 2x vom „Upload“, ist das ein Typo?
Ich habe natürlich während des Upload (Cloop vom Client auf den Server kopieren) htop ausgeführt. Die Auslastung des Servers ist dabei extrem niedrig. Trotzdem habe ich dem Server mehr Prozessoren und mehr Speicher zugewiesen ohne eine Änderung zu bewirken.
Atop muss ich noch laufen lassen. Iftop habe ich ausgeführt. Das bestätigt die geringen Übertragungsraten.
Damit ist gemeint dass der Client ein erstelltes cloop auf den Server lädt.
Das Kopieren einer großen Datei auf den Server werde ich noch testen und dann berichten.
Es geht nicht um Prozessor oder Memory, es könnte um IO-Last gehen. Darum der dd Befehl um mal zu schauen, was da so geht, wenn’s größer wird. Wenn IO geblockt ist, hilft weder Prozessor noch Speicher, da wird dann gewartet.
Du nennst zwei Mal „Upload“, einmal wo es nicht geht (cloop auf server) und ein zweites Mal wo es geht (da meinst du vielleicht download?). Ausserdem wechselst du die Einheiten beim Vergleich von MB/s zu Mbit/s.
Hallo Alois,
ich bin bei Linux nicht zuhause. Zeigt htop nicht nur Ram und Prozessor an, aber nicht die Auslastung der Festplatte?
Ich würde auch zuerst darauf tippen, dass die Festplatte die Daten nicht schnell genug wegschreibt. Die 100MB/s sind etwa das, was eine Festplatte liefert. Aber wenn der Cache der Platte voll ist, dann geht das schnell nach unten.
Hast du Festplatten, SSD, Raid?
Ein paar Daten wären hilfreich.
Da ist mir ein Fehler unterlaufen. Upload vom Client auf den Server wird langsam. Beim Übertragen vom Server auf den Client gehts zügig und ohne große Schwankungen.
Der Einheitenwechsel ist der Anzeige beim Up- bzw. Download geschuldet.
Beim Hochladen vom Client wird unter Linbo MB angezeigt, beim Download auf den Client werden unter Linbo Mb angezeigt.
Das ist natürlich blöd, wenn man nicht sicher weiss, wie das umzurechnen ist. Deine erwarteten 100MB/s allerdings erreichen 400Mb/s aber auch bei Weitem nicht, oder?
Hallo Alois,
die SSDs sollten das schaffen, außer die werden beim Schreiben von großen Datenmenge mangels Kühlung extrem warm und drosseln sich. Ist aber unwahrscheinlich.
Trotzdem würde ich den Tipp von mdt umsetzen und auf dem Server mal extreme Schreiblast verursachen. Dann ist ein Fehlerbereich gefunden oder eben ausgeschlossen. Dann kann man weiterschauen.
So ganz sicher bin ich mir bei den MB/S oder MBit/s auch nicht, aber 100 MB/s ist eigentlich so das praktische Maximum von 1GBit/s Netzwerken. Mehr geht nicht über die Leitung. Wenn es dann drosselt, läuft irgendwo ein Cache voll und wenn die Leistung nicht wieder ganz hochgeht ist die Datenspeicheranbindung normalerweise der Flaschnhals.
300 bis 400 MBit/s wären dagegen beim Download auf die Clients nur etwa 50 MB/s. Das ist eigentlich zu langsam, wenn das Netz nicht anderweitig ausgelastet ist.
Bin mal auf die Lösung des Problems gespannt.
Da hilft nur testen.
Vom Server auf eine externe USB-Festplatte zeigt „atop“ zwischen 240 und 340 M (ich nehme an Bit) an.
Umgekehrt schwankt die Übertragungsrate zwischen 19000 K und ca. 300 M !?
Das war ein Versuch mit scp
Was tun?
Wo ist der Flaschenhals?
Mit dem mc sieht es ganz ähnlich aus. Anfangs recht flott (ca. 250 M) und dann geht es wieder runter auf kleine Werte (ca. 10000 K). Ebenfalls stark schwankend.
Hallo,
die externe Festplatte hängt schon am Server?
Wenn ja, dann liegt es wohl am Datenspeicher des Servers.
Wichtigste Frage: Hast du ein aktuelles, funktionierendes Backup?
Vorher würde ich am Server gar nichts machen.
Ansonsten, welches Raid (Hardware, Software, Version), was für SSDs, …?
Ist eine SSD ausgefallen und ist der Server mit der HotSpare im Rebuild?
Gibt es Garantie oder Service von einem externen Dienstleister?
Die Festplatte hängt am Virtualisierer und ist per attach mit dem Server verbunden.
Nein, das ganze ist frisch aufgesetzt, aber noch nicht produktiv.
Beim Raid-Controller muss ich nachsehen. Er ist fest verbaut in dem HP Z800. Bei den SSD’s müsste ich auch nachsehen, da sie eingebaut sind.
Die SSD’s sind nagelneu, was nicht bedeutet dass eine nicht ausfallen könnte. Es gibt keine Hotspare.
Nein, keine Garantie und kein Service vom Dienstleister (der bin ich in dem Fall selbst )
Ich bin gerade dabei mit dem mc von außen eine größere Datei auf den Server zu kopieren. Der mc zeigt mir permanent 7,5 MB/s an. Das Schreiben auf die Festplatte schwankt zwischen 60000K und 90000K. Die Zeit bis 7800M kopiert war lag bei ca. 12 - 15 Minuten. M.E. ein recht guter Wert.
Warum bricht das beim Kopieren von Festplatte auf den Server bzw. übers interne Netz auf den Server so stark ein?
Noch ein Test von einem Verzeichnis des Servers ins andere Verzeichnis kopieren.
Start mit 500M geht dann sehr schnell auf 1200K runter. Arbeitet dann weiter mit 104 M, dann mal wieder auf 400M und zurück auf 1000K - 2000K. Derweil zeigt der mc einen Wert von etwa 8 MB/s (vermutlich ein Durchschnittswert) an.
Vom Server auf die externe Festplatte geht’s mit dem mc mit 300 M (byte?). der mc gibt derweil ca. 38 MB/s an.
Das Problem liegt beim Reinkopieren in den Server und beim Kopieren von einer Platte auf die andere.
das Raid wird als degradet gemeldet und eine Festplatte fehlt gänzlich im Raid. Dein Verdacht war also richtig.
Nachtrag: Nach dem Ausbau der fehlenden Festplatte und testen mit smartmontools (offenbar ist die Festplatte ok) wird sie im Controller als vorhanden und „unsyncd“ angezeigt. Der Sync-Vorgang läuft. Stellt sich nur die Frage ob der rebuild auch weiter läuft, wenn ich den Server produktiv laufen lasse.
Und dann ist noch die Ursache für das zeitweilige fehlen der Festplatte völlig unklar. M.E. kann es sich nur um einen Wackler handeln und der kann natürlich immer wieder auftreten .
Hallo Alois,
ein Wackler ist echt ungünstig.
Aber eigentlich müsste im Log ein Hinweis auf die Ursache stehen. Der Controller oder XCP hat sicher eine Meldung mit Grund geschrieben, warum die SSD als defekt markiert wurde.
Du solltest die SSD auch noch mit den Herstellertools überprüfen. Smart-Werte scheinen einige SSD Hersteller eher als nettes Feature zu betrachten, das man mit irgendwelchen Fantasiewerten belegen kann.
heutige Versuche haben eindeutig ergeben dass der Port des Raid-Controllers an dem die Festplatte hängt offenbar das Problem ist. Alles andere lässt sich ausschließen.
Ich bin gerade dabei die virtuellen Maschinen zu exportieren und dann wird auf einen anderen Server „umgezogen“.
Viele Grüße und nochmals vielen Dank für Deine Unterstützung
scp über das Netzwerk? Und dann über USB? Warum nutzt du nicht den von mir empfohlenen Befehl dd? Ich würde auf eine Datei ins selbe FS schreiben oder nach /dev/null (für Lese-Performance). - dd schliesst Doppeldeutungen aus…
.