PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Keine Ramdisk unter SuSE 11.1?



Noether
05.05.09, 16:14
Wie schon früher mehrmals, unter mehreren SuSE-Versionen, wollte ich nun unter SuSE 11.1 eine Ramdisk verwenden, aber ich mußte feststellen, das es unter 11.1 kein /dev/ram* gibt, während es unter Debian Lenny gleich 16 gibt.
Wieso gibts es unter 11.1 keine Ramdisk (/dev/ram*) mehr
und wie bekomme ich die wieder? :confused:

Rain_maker
05.05.09, 17:37
Konsultiere mal die man-page von mount zum Thema tmpfs.

Noether
15.05.09, 18:14
Also tmpfs ist nicht schlecht, aber kein echter Ersatz: Es kann geswappt werden.

Inzwischen habe des Rätsels Lösung gefunden: Nach Installiern der Kernel-Sourcen, ncurses und qt konnte ich mittels
make oldconfig
die Konfigurationsdatei vom Kernel erstellen und mittels
make xconfig
sehen, das die RAMDisks unter BLK_DEV_RAM, RAM block device support nur als Modul vorhanden sind.
Mittels
modprobe rd
erhält man unter SuSE die RAMDisks.

derRichard
20.05.09, 00:25
hi!

was ist so schlecht wenn tmpfs swap verwendet, wenn der speicher knapp wird?

//richard

Noether
20.05.09, 18:51
hi!
was ist so schlecht wenn tmpfs swap verwendet, wenn der speicher knapp wird?
//richard

Also eine RAMDisk verwendet man wenn man ein richtig schnelles Dateisystem benötigt.
Nur wenn es wirklich komplett im RAM ist, ist es wirklich schnell.
Tmpfs ist daher nicht empfehlenswert, außer man verwendet kein Swap.

derRichard
21.05.09, 00:10
hi!

naja, swap verwendet es ja nur wenn eh schon der ram voll ist.
und ansonsten kannst ja den swap abstellen, wenn sooo kritisch ist.

//richard

Rain_maker
21.05.09, 00:19
Also eine RAMDisk verwendet man wenn man ein richtig schnelles Dateisystem benötigt.
Nur wenn es wirklich komplett im RAM ist, ist es wirklich schnell.



mount |grep tmpfs
udev on /dev type tmpfs (rw)
tmpfs on /tmp type tmpfs (rw,size=1610612736,mode=1777)

dd if=/dev/zero of=/tmp/plumbaquatsch bs=1024k count=1000
1000+0 Datensätze ein
1000+0 Datensätze aus
1048576000 Bytes (1,0 GB) kopiert, 0,998976 s, 1,0 GB/s

Schnell genug?


Tmpfs ist daher nicht empfehlenswert, außer man verwendet kein Swap.

Wenn die Kiste anfängt zu swappen, weil der RAM knapp wird, dann ist es komplett wurscht, welches Dateisystem man für die Ramdisk verwendet.

Noether
21.05.09, 02:22
...
1048576000 Bytes (1,0 GB) kopiert, 0,998976 s, 1,0 GB/s

Schnell genug?

Nein: Beim SAS-Controller habe ich gecacht 2 GB/s, ungecacht, mit 8x 15K3 HDDs im RAID0, 1 GB/s. Beim aktuellen Nehalem-Rechner mit (nur) 2 CPUs habe ich aber eine (gemessene) RAM-Bandbreite von 20 GB/s (bei 2 Threads je Node).
Mit RAM habe ich also zehnmal mehr Bandbreite, selbst wenn ich mit 8 HDDs im RAID0 vergleiche.
Und bei den Latenzzeiten ist RAM mehr als tausendmal schneller!
Hinzu kommt, das die 8 3,5" HDDs mehr Platz benötigen als RAM-Riegel, das sie lauter sind, häufiger ausfallen usw.; HDDs mit RAMDisks zu vergleichen ist so wie Äpfel mit Eiern zu vergleichen.




Wenn die Kiste anfängt zu swappen, weil der RAM knapp wird, dann ist es komplett wurscht, welches Dateisystem man für die Ramdisk verwendet.

Ja, aber man kann ja ein paar GiB mehr reinstecken um das Problem zu beseitigen.
Daheim habe ich 16 GiB und es wird nichts geswapt.; bei der Arbeit verwende ich in einem kleinen PC mit zwei CPUs 96 GiB und in das RAM passt so ziemlich alles rein, was man wirklich schnell braucht.
Bei derzeit um 10 Euro pro GiB sind ein paar dutzend GiB mehr doch wirklich nicht der Rede wert!

Rain_maker
21.05.09, 03:10
Sieht hier mit den Geschwindigkeit etwas anders aus, selbst bei direktem Schreiben auf das device (also ohne jeglichen Overhead durchs Dateisystem) ist eine Ramdisk langsamer als tmpfs:



dd if=/dev/zero of=/tmp/plumbaquatsch bs=1024k count=125
125+0 Datensätze ein
125+0 Datensätze aus
131072000 Bytes (131 MB) kopiert, 0,128384 s, 1,0 GB/s

dd if=/dev/zero of=/dev/ram1 bs=1024k count=125
125+0 Datensätze ein
125+0 Datensätze aus
131072000 Bytes (131 MB) kopiert, 0,24299 s, 539 MB/s

wenn ich die Ramdisk mit verschiedensten Dateisystemen formatiere (was einem gerade so einfällt), dann wirds noch deutlicher, z.B. mit ext4:



mkfs.ext4dev /dev/ram1

mount /dev/ram1 /mnt/
dd if=/dev/zero of=/mnt/plumbaquatsch bs=1024 count=125
125+0 Datensätze ein
125+0 Datensätze aus
128000 Bytes (128 kB) kopiert, 0,00119918 s, 107 MB/s

//Nachtrag:

Witzigerweise wird das Ganze dann wiederum schneller (= genau so schnell wie direkt mit tmpfs), wenn man /dev/ramX als "tmpfs" mountet, "ramfs" ist sogar noch etwas schneller, nur das geht auch beides ohne /dev/ramX (siehe man mount), daß allerdings das direkte Schreiben auf das Device /dev/ramX merklich langsamer als auf ein /dev/ramX als tmpfs/ramfs gemountet ist, finde ich zunächst mal überraschend.

Noether
21.05.09, 11:15
Aha, Benchmarks habe ich dazu bisher nicht gefunden und die Ergebnisse sehen komisch aus, aber ich sehe hier ähnliches.
Bisher hatte ich aber keine Performance-Probleme mit RAMDisks, wohl hauptsächlich wegen den kleinen Latenzzeiten.

Noether
22.05.09, 20:09
Also ich habe mal mit einem aktuellen Rechner mit dual Xeon W5580 (Intel Nehalem, 3,2 GHz)
gemessen, unter 64-Bit SuSE 11.1, mit dd if=/dev/zero bs=64k count=10000:

/dev/ram0: um 700 MB/s

tmpfs: 2,0 GB/s

ramfs: 2,6 GB/s

/dev/null: 12,7 GB/s

7x 15K2 2,5" HDDs im RAID0 mit ext2: Um 900 MB/s (bei den äußeren Sektoren 950 MB/s, innen 800)
- wobei mit 66 und 600 GB getestet wurde wegen der starken Pufferung

bei /dev/urandom als Quelle: 10 MB/s

Die Werte sind reproduzierbar.
Etwas genauere Werte erhät man mit der Zeit zum Syncen, z. B. so:
sync; time dd if=/dev/zero of=/dev/null bs=64k count=10000; time sync
Damit erhält man die Gesamt-Zeit und die gesamte Datenmenge und hieraus
kann man die gemessene Datenrate, mit dem Leeren der Puffer, berechnen.
Allerdings ist auch das nicht exakt: Beim RAID ist mir aufgefallen das erstmal sekundenlang
Puffer gefüllt werden, bevor die HDDs Aktivität zeigen; man erhält damit also zu niedrige Werte,
weil die HDDs erst verzögert anfangen zu arbeiten.

Bei den Dateisystemen im RAM ist dieses Puffern nicht vorhanden, wie das letzte time zeigt, und wahrscheinlich ist das der Grund für die mieserable Performance.

Die physikalische Bandbreite erreicht man leider nur mit /dev/null.