RAM-IO-Test auf einem KVM-Server

[andreas0]

Heute habe ich mal auf einem gemieteten KVM-Server mit zugewiesenem RAM von 16GB mit Hilfe einer RAM-Disk 6GB groß und mit folgendem Befehl einen RAM-IO-Test durchgeführt:

dd if=/dev/zero bs=1M count=5000 of=/mnt/ramdisk/outputfile5GB

Ergebnis:
5000+0 Datensätze ein
5000+0 Datensätze aus
5242880000 Bytes (5,2 GB) kopiert, 61,3276 s, 85,5 MB/s

Da mir die Schreibleistung eher so aussieht, als hätte ich auf eine Festplatte geschrieben, meine Frage:

Kann es sein, dass man bei KVM-Servern, um an teuren RAM zu sparen, anstelle eines echten RAMs den RAM-Speicher auch über Festplatten realisieren kann?

Auf dem Wirtsystem ist laut der CPU-Info der Prozessor "Intel Xeon CPU E5-2670 v2" verbaut.

Folgenden Wert habe ich auf meinem Consumer-PC mit dem Prozessor "Intel Core i7-4790T" erreicht:
5000+0 Datensätze ein
5000+0 Datensätze aus
5242880000 Bytes (5,2 GB) kopiert, 1,84262 s, 2,8 GB/s

 

[Lord Gurke]

Es kann auch schlicht sein, dass der Host überbucht ist und du in den Host-Swap geschrieben hast. Wie viel RAM ist denn garantiert?

 

[andreas0]

Wie viel RAM ist denn garantiert?

Es sind 16GB RAM garantiert.

 

[[netcup] Felix]

Wurde richtig gemountet?

Viele Grüße

Felix

 

[Deleted member 15972]

Vermutung:
RAM ist unglaublich langsam: die CPU muss mehrere hundert Zyklen warten, wenn sie Daten zum ersten mal anfordert und/oder diese nicht sequentiell verfügbar sind. Er erreicht nur dann eine hohe Bandbreite, wenn die Daten im Burst Mode übertragen werden können (dann wird im Idealfall pro Taktflanke einmal übertragen).
Bei (v)Servern hat man jetzt üblicherweise das Problem, dass viele Nutzer gleichzeitig den RAM benutzen, für völlig unterschiedliche Aufgaben.

Dann passiert folgendes: Daten werden übertragen, anderer Prozess möchte etwas, neue Row and Col werden selektiert, Daten übertragen, neuer Prozess möchte etwas und so weiter.

Das tritt in geringerem Maße natürlich auch auf gewöhnlichen Servern auf, allerdings behaupte ich, dass auf dem durchschnittlichen vServer-Host wesentlich mehr völlig verschiedene Prozesse laufen, die aber alle CPU-Zeit benötigen (die CPU holt ihre Daten wiederum aus dem RAM, denn soviel Platz ist in den schnellen Caches nicht).

Um diese Theorie zu prüfen, habe ich einmal sehr kleine Tempdateien in ein tmpfs geschrieben (1G) und dann sehr große (5G) und die Transferrate war bei den kleinen Dateien wesentlich größer. Das ist natürlich kein Beweis, passt aber IMO ganz gut zu den technischen Eigenschaften von RAM.

Auf meinem physischen Server komme ich z.B. auf Transferraten von 4,5GB/s, was bei Übertragung im Burstmode durchaus realistisch ist.
Auf dem vServer komme ich auf Werte zwischen 1,8GB/s (sehr kleine Dateien) bis runter auf 380-500 MB/s (große Dateien).

Von daher *KÖNNTEN* Deine Werte davon kommen, dass der Host wirklich sehr ausgelastet ist. Ich persönlich würde also erst einmal nicht davon ausgehen, dass hier geschummelt wird.

tl;dr: dieser Effekt dürfte mit steigender Auslastung des vServer-Hosts immer weiter zunehmen, selbst wenn ("mengenmäßig") gar nicht so viel RAM belegt ist.

 

[[netcup] Felix]

Also das halte ich nicht für die Ursache. Selbst wenn ein vServer 100 Zyklen warten müsste, sollten die Schreibraten deutlich schneller sein wenn in den RAM geschrieben wird. Moderne vServer haben jedoch garantierte Kerne und können somit faktisch ohne Verzögerung durch andere Prozesse auf den RAM zugreifen.

Ich vermute nach wie vor das der Mount falsch ist und gerade auf einer Festplatte geschrieben wird, statt im RAM.


VG Felix

 

[Deleted member 15972]

Also das halte ich nicht für die Ursache. Selbst wenn ein vServer 100 Zyklen warten müsste, sollten die Schreibraten deutlich schneller sein wenn in den RAM geschrieben wird. Moderne vServer haben jedoch garantierte Kerne und können somit faktisch ohne Verzögerung durch andere Prozesse auf den RAM zugreifen.
VG Felix

Und was ändern dedizierte Kerne?
Du hast immer Kontextwechsel zwischen verschiedenen Prozessen und mehr Kerne die auf den selben RAM zugreifen "verschlimmern" die Situation nur noch, da noch mehr Kontextwechsel in einem bestimmten Zeitraum X statt finden. Kontextwechsel bedeuten i.A., dass keine örtliche Lokalität der Daten mehr gegeben ist -> mehrere hundert Zyklen, bis die erste Übertragung beginnt.

Das Problem ist nicht all eine die Latenz *bis* der Zugriff stattfinden kann, sondern die Tatsache, dass bei ständigen Kontextswitches der Burstmode wesentlich kürzer zum Tragen kommt und damit diese hohe Latenz immer und immer wieder "bezahlt" werden muss.

Bei vServern ist das Problem eben deutlich größer, da hier viel mehr Prozesse laufen (30+ vServer auf einem physischen Host sind ja nicht unbedingt selten). Die Quintessenz ist ohnehin: die Hostauslastung spielt eine große Rolle aber die kann man nicht nur daran ablesen, wie viele GB des RAM belegt sind, sondern eben auch daran, was genau dort ausgeführt wird.

 

[andreas0]

Vielen Dank für den regen Austausch zu diesem Thema.

Laut Provider wurden mir folgende technische Daten zum KVM-Server zugesichert:
Prozessor: Intel Xeon E5-2670V2
Prozessorkerne: 4
Arbeitsspeicher DDR 3 ECC 16 GB
Festplatte: 1000 GB
RAID 50 für hohe Datensicherheit auf SAS-Festplatten mit bis zu 10K IOPS auf dem Wirtsystem

Wurde richtig gemountet?

Ja die RAM-Disk wurde richtig eingehängt. Denn als ich die RAM-Disk wieder ausgehängt hatte, war auch die erzeugte Datei nicht mehr vorhanden.

Ich vermute nach wie vor das der Mount falsch ist und gerade auf einer Festplatte geschrieben wird, statt im RAM.

Da ich als Kunde nicht auf das Wirsystem schauen kann, kann man hier als Kunde auch nur spekulieren, ob dieser Schreibzugriff auf echtem RAM oder nur auf Festplatte durchgeführt wurde bzw. wird. Die RAM-Disk wurde aber von mir richtig reingehängt.

Um diese Theorie zu prüfen, habe ich einmal sehr kleine Tempdateien in ein tmpfs geschrieben (1G) und dann sehr große (5G) und die Transferrate war bei den kleinen Dateien wesentlich größer. Das ist natürlich kein Beweis, passt aber IMO ganz gut zu den technischen Eigenschaften von RAM.

Diese Eigenschaften habe ich insbesondere auch beim Beschreiben von Festplatten mit und auch ohne RAID-Controler beobachten können. Von daher habe ich auch, um den Cache vom Controler oder der Festplatte mit einer übergroßen Datei überfluten zu können, eine größere Datei >5 GB mit Hilfe des DD-Befehls angelegt.

Auf einen nicht ausgelasteten dedizierten Server, auf dem ich diesen RAM-IO-Test auch mal mit kleinen bis großen Dateien (1 bis 20 GB) getestet hatte, konnte ich dieses Verhalten nicht feststellen. Die Schreibleistung war immer gleich schnell.

Es kann auch schlicht sein, dass der Host überbucht ist und du in den Host-Swap geschrieben hast.

Also, ich gehe auch mal davon aus, dass mir entweder nur RAM zur Verfügung gestellt wird, der über Festplatten realisiert wird oder dass der KVM-Server wegen permanenter Überbuchung des Wirtsystems auch permanent in den Host Swap des Wirtsystems schreibt.

 

[Thunderbyte]

Ich vermute auch, dass Du auf die Festplatte geschrieben hast. Vielleicht solltest Du mal näher erläutern mit welchen Befehlen Du die Ramdisk erstellt hast. Vielleicht findet sich ja dann die Lösung.

Wie schlägt sich die Ramdisk in einem "df" nieder? Wird der freie Speicher vor vs nach dem Anlegen, überprüft mit "free -g" auch wirklich weniger?

 

[andreas0]

Ich vermute auch, dass Du auf die Festplatte geschrieben hast. Vielleicht solltest Du mal näher erläutern mit welchen Befehlen Du die Ramdisk erstellt hast. Vielleicht findet sich ja dann die Lösung.

Ich habe es heute noch mal wie folgt durchgespielt:

free -g (ohne RAM-Disk nach einem Neustart)
             total       used       free     shared    buffers     cached
Mem:            15          0         15          0          0          0
-/+ buffers/cache:          0         15
Swap:            1          0          1


cat /etc/fstab
.
.
# RAM-Disk
tmpfs    /mnt/ramdisk    tmpfs    defaults,size=6G      0       0


mount /mnt/ramdisk


df -h /mnt/ramdisk
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
tmpfs           6,0G       0  6,0G    0% /mnt/ramdisk


ls -al /mnt/ramdisk
insgesamt 4
drwxrwxrwt 2 root root   40 Jan 16 15:57 .
drwxr-xr-x 3 root root 4096 Aug 24  2014 ..


free -g (nach dem Einhängen der RAM-Disk)
             total       used       free     shared    buffers     cached
Mem:            15          0         15          0          0          0
-/+ buffers/cache:          0         15
Swap:            1          0          1


Erster Durchgang:
nohup dd if=/dev/zero bs=1M count=5000 of=/mnt/ramdisk/savefile5GB.test &


Zweiter Durchgang:
nohup dd if=/dev/zero bs=1M count=5000 of=/mnt/ramdisk/savefile5GB.test &


cat nohup.out
Erster Durchgang:
5000+0 Datensätze ein
5000+0 Datensätze aus
5242880000 Bytes (5,2 GB) kopiert, 137,864 s, 38,0 MB/s

Zweiter Durchgang:
5000+0 Datensätze ein
5000+0 Datensätze aus
5242880000 Bytes (5,2 GB) kopiert, 187,102 s, 28,0 MB/s


ls -la /mnt/ramdisk/
insgesamt 5120004
drwxrwxrwt 2 root    root            60 Jan 16 16:03 .
drwxr-xr-x 3 root    root          4096 Aug 24  2014 ..
-rw-r--r-- 1 root    root    5242880000 Jan 16 16:06 savefile5GB.test


free -g
             total       used       free     shared    buffers     cached
Mem:            15          5         10          0          0          4
-/+ buffers/cache:          0         15
Swap:            1          0          1


df -h /mnt/ramdisk/
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
tmpfs           6,0G    4,9G  1,2G   82% /mnt/ramdisk


umount /mnt/ramdisk


ls -la /mnt/ramdisk
insgesamt 8
drwxr-xr-x 2 root root 4096 Aug 24  2014 .
drwxr-xr-x 3 root root 4096 Aug 24  2014 ..


free -g (nach dem Aushängen der RAM-Disk)
             total       used       free     shared    buffers     cached
Mem:            15          0         15          0          0          0
-/+ buffers/cache:          0         15
Swap:            1          0          1

Wie man sehen kann, sehen die Ergebnisse heute noch schlechter aus.

 

[andreas0]

Vielleicht solltest Du mal näher erläutern mit welchen Befehlen Du die Ramdisk erstellt hast. Vielleicht findet sich ja dann die Lösung.

Eventuell habe ich hier, wie eventuell Thunderbyte vermutet, auch nur einen Gedankenfehler. Von daher mal meine Frage: Gibt es hier zufälligerweise noch jemanden, der bei meinem zuvor aufgezeigten Problem bei der Ausführung der Problemanalyse einen Fehler erkennt?

 

[ThomasChr]

Hallo andreas,

ich habe exakt deine Befehle mal auf einem netcup Server L durchprobiert.
Ergebnis:

5000+0 records in
5000+0 records out
5242880000 bytes (5.2 GB) copied, 6.82392 s, 768 MB/s

5000+0 records in
5000+0 records out
5242880000 bytes (5.2 GB) copied, 3.13203 s, 1.7 GB/s

In dem Fall ist das übrigens ein Server mit SSD, aber das wird hier ja keinen Einfluss haben.

Wenns dir hilft, ich habe auch schon mal einen Server bei Strato gehabt, da konnte man den RAM garnicht mounten (Virtuozzo) und einen bei Hetzner da sah es so aus:

10+0 records in
10+0 records out
1342177280 bytes (1,3 GB) copied, 17,2858 s, 77,6 MB/s

(ACHTUNG! Andere Blocksize! Befehl war:

dd if=/dev/zero of=/media/ram/test/test.file bs=128M count=10

)

Ich hatte dieses "vernichtende" Ergebnis mal nachgefragt und bekam folgende Antwort:

RAM steht dediziert zur Verfügung, wird aber erst bei Bedarf zugeteilt. D.h. inital ist die Geschwindigkeit langsamer als sie sein könnte. So schnell wie bei einem dedizierten Server ist es aber nie.

Aber obs das bei dir auch ist?
Spätestens beim zweiten Test sollte doch alles an RAM da sein.

Ich denke aber trotzdem man kann davon ausgehen dass die Host-Maschine entweder überbelegt, überlastet oder einfach schlecht konfiguriert ist.

Thomas

PS: Deswegen war mein Weg von Strato (mieserabel!) über Hetzner (deutlich besser, aber die vServer werden eher stiefmütterlich behandelt und sind nicht die absoluten Raketen) bis zu netcup.
Bei netcup sieht es momentan absolut perfekt aus.
Und günstig ist es auch (im Vergleich wohl günstiger als bei Hetzner aber teurer als bei Strato - nur was nützt mir das günstige Strato wenn die Leistung ständig einbricht? )

Wenn du weitere Daten brauchst, meld dich einfach.

 

[andreas0]

Hallo Thomas,

vielen Dank für deinen wertvollen Beitrag, der mir auch zeigt, dass auch mehr Bandbreite auf einem KVM-Server möglich sind. Denn vor längerer Zeit so Anfang 2014 hatte ich solche ähnlichen Werte auch mal auf meinem KVM-Server sehen können.

Ich hatte dieses "vernichtende" Ergebnis mal nachgefragt und bekam folgende Antwort:

Zitat:
RAM steht dediziert zur Verfügung, wird aber erst bei Bedarf zugeteilt. D.h. inital ist die Geschwindigkeit langsamer als sie sein könnte. So schnell wie bei einem dedizierten Server ist es aber nie.

Die Antwort vom Provider Strato bezog sich mit höchster Wahrscheinlichkeit auf einen Virtuozzo vServer. Bei einem KVM-Server sollte aber so ein Verhalten unüblich sein.

Seit wann hast du denn deinen KVM-Server vom Provider Netcup?

Gruß
Andreas

 

[ThomasChr]

Die Antwort ist von Hetzner bezüglich einem CX30 - ich denke der ist KVM virtualisiert. Kam mir zumindest so vor.
Hier die Details: https://www.hetzner.de/de/hosting/produkte_vserver/cx30

Ärgert mich jedes Mal dass es die wenigsten Anbieter für wichtig halten die Virtualisierungstechnologie anzugeben. *GNARF*

Den KVM Server bei Netcup hab ich jetzt seit zwei Monaten und bin absolut zufrieden. Muss aber zugeben dass er nicht produktiv läuft.
Den Server den ich damals von Strato weggezogen habe, wegen Problemen (einfache MySQL Querys die manchmal 10 Sekunden gebraucht haben, vollkommen überlastetes IO-System, manchmal keine Reaktion für Sekunden auf der Shell und dann war der Server auch noch einfach so mal nen Tag lang weg - und man konnte auch nicht ins Rescue booten) den hoste ich jetzt selber mit QEMU auf einem Hetzner dedicated. Seitdem natürlich kein Problem mehr

Was netcup betrifft so haben die recht günstige Server und 30 Tage Geld Zurück Garantie. Da kann man wohl nix falsch machen.
Alternativ hatte ich mir damals noch PHP-Friends überlegt, aber den ihr Angebot kam nicht ganz an das von Netcup ran.

Thomas

 

[andreas0]

Hallo Thomas,

... den hoste ich jetzt selber mit QEMU auf einem Hetzner dedicated. Seitdem natürlich kein Problem mehr

hast du zufälligerweise auch mal den Test auf einem QEMU-Server durchgeführt? Und wenn ja: War es da auch so, dass der erste Durchlauf langsamer war als die nachfolgenden Durchläufe?

Auf einem gemieteten dedizierten Server bei IP-Projects habe ich unter openvz auch mal die RAM-Verfügbarkeit mit Hilfe einer RAM-Disk getestet. Dort war der erste Durchlauf genauso hoch wie die nachfolgenden Durchläufe.

Nach meinem Beitrag vom 18.01.2015 um 22:25 Uhr und heute hatte ich noch mal auf meinem KVM-Server die Bandbreite des RAMs getestet und hatte festgestellt, dass nun die Werte zufriedenstellend zwischen ca. 300 MB/s bis 1.4 GB/s liegen.

Da ich wegen diesem Problem kein Tickt aufgegeben hatte, zeigt es mir, dass der Provider trotz niedriger Kampfpreise seine Systeme - auch ohne dass der Kunde gegenüber dem Provider erst aktiv werden muß - unter Kontrolle hält.

Gruß
Andreas

 

[ThomasChr]

Das ist der Test auf meinem selber virtualisierten Server:

5000+0 records in
5000+0 records out
5242880000 bytes (5.2 GB) copied, 1.09431 s, 4.8 GB/s

5000+0 records in
5000+0 records out
5242880000 bytes (5.2 GB) copied, 0.995608 s, 5.3 GB/s