Hallo,
ich habe hier einen Server unter anderem mit einer 2 GB RAM-Disk am laufen, dabei sind mir folgende Dinge aufgefallen:
1. Blocksize (ext2fs)
Man kann eine RAM-Disk nur mit einer Blocksize von 1k verwenden, alle anderen Einstellungen funktionieren nicht.
Weiss jemand warum?
2. top / free und andere Tools
Der verfügbare Speicher wird nicht um den durch die RAM Disk verwendeten Speicher reduziert. Ein 4 GB System zeigt auch bei Nutzung von 2,5 GB durch RAM-Disks folgende Ausgabe:
# free total used free shared buffers cached Mem: 4155628 3758484 397144 0 1751656 961184 -/+ buffers/cache: 1045644 3109984 Swap: 4192956 0 4192956
3. Datendurchsatz
Tests haben gezeigt, dass der Durchsatz der RAM-Disk bei ca. 50 MB/s liegt... das finde ich erstaunlich wenig. Ist aber identisch mit dem Durchsatz einer Datei, die aus dem Cache gelesen wird.
Das "gecachte" Daten langsamer - als absoluter RAM Durchsatz - geliefert werden kann ich noch in etwa verstehen, aber das Daten aus einer RAM-Disk so langsam kommen finde ich geradezu ernüchternd.
Frage: Gibt es eine Möglichkeit den Durchsatz in der RAM-Disk zu steigern (andere Blockgröße geht nicht, siehe Punkt 1)?
Pjah... vielleicht fällt jemanden von Euch dazu etwas ein.
Einzige Alternative zum bisherigen verfahren wären ja wohl solid state disks... aber gibt es sowas überhaupt noch, und sind die bezahlbar?
Grüße,
Alexander Finger
On Wednesday 29 September 2004 14:06, Alexander Finger wrote:
Hallo,
ich habe hier einen Server unter anderem mit einer 2 GB RAM-Disk am laufen, dabei sind mir folgende Dinge aufgefallen:
Wozu?
- Datendurchsatz
Tests haben gezeigt, dass der Durchsatz der RAM-Disk bei ca. 50 MB/s liegt... das finde ich erstaunlich wenig. Ist aber identisch mit dem Durchsatz einer Datei, die aus dem Cache gelesen wird.
Wie kommst du denn auf diese Werte?
In einem lurzen Test erhalte ich ein deutlich anderes Ergebnis: [ronny@bserv tmp]$ time dd of=/dev/zero if=test bs=1M count=100 100+0 Records ein 100+0 Records aus
real 0m1.094s user 0m0.000s sys 0m0.260s
[ronny@bserv tmp]$ time dd of=/dev/zero if=test bs=1M count=100 100+0 Records ein 100+0 Records aus
real 0m0.131s user 0m0.000s sys 0m0.130s
Hallo!
On Mon, 2004-10-04 at 22:48, Ronny Buchmann wrote:
On Wednesday 29 September 2004 14:06, Alexander Finger wrote:
Hallo,
ich habe hier einen Server unter anderem mit einer 2 GB RAM-Disk am laufen, dabei sind mir folgende Dinge aufgefallen:
Wozu?
Ich benötige stabile Transferraten, der Server muss eine Volltextsuche auf einem großen Index durchführen. Da bei Plattenzugriffen nur theoretische 50 MB/s zur Verfügung stehen - und in der Praxis sinkt die Transferrate (ohne Cache) auf 10 MB/s ab (was OK ist, war nicht anders erwartet). Deshalb habe ich mich für die RAM-Disk entschieden. In Erwartung stabile rund vor allem schneller Schreib- und Lesereaten. Die Stabilität ist in jedem Fall eingetreten, d.h. es gibt keine IO-Waits mehr, aber die Transferraten sind enttäuschend.
- Datendurchsatz
Tests haben gezeigt, dass der Durchsatz der RAM-Disk bei ca. 50 MB/s liegt... das finde ich erstaunlich wenig. Ist aber identisch mit dem Durchsatz einer Datei, die aus dem Cache gelesen wird.
Wie kommst du denn auf diese Werte?
test ist eine 100 MB Datei.
Mein Test:
$ time dd if=test of=/dev/null 204800+0 records in 204800+0 records out
real 0m2.129s user 0m0.718s sys 0m1.407s
Dein Test:
$ time dd if=test of=/dev/null bs=1M 100+0 records in 100+0 records out
real 0m0.199s user 0m0.001s sys 0m0.198s
Wie Du siehst, ist es nicht ganz egal wie man auf die Dateien im Dateisystem "zugreift". Normale Programme lesen mit der Standard-Blocksize. Es ist diese Leistung, bzw. eben die Nicht-Leistung die mich hier vor Probleme stellt.
Vielleicht ist auch die Wahl des Dateisystem nicht unerheblich... Beispielen folgend habe ich mich für ext2 entschieden... gibt es eine Alternative?
In einem lurzen Test erhalte ich ein deutlich anderes Ergebnis: [ronny@bserv tmp]$ time dd of=/dev/zero if=test bs=1M count=100 100+0 Records ein 100+0 Records aus
real 0m1.094s user 0m0.000s sys 0m0.260s
[ronny@bserv tmp]$ time dd of=/dev/zero if=test bs=1M count=100 100+0 Records ein 100+0 Records aus
real 0m0.131s user 0m0.000s sys 0m0.130s
Siehe oben.
Pjah. Jetzt wissen wir schon mal, dass es gravierende Unterschiede gibt, abhängig davon mit welcher Blocksize gearbeitet wird. Nicht jede Software ist selbst geschrieben, daher ist diese Tuning-Option verschlossen. Noch dazu kann man ein RAM-Disk-Filesystem nicht mit einer anderen Blocksize als 1K anlegen.
Ach ja, ganz vergessen warum ich hier Poste:
$ cat /etc/redhat-release Fedora Core release 2 (Tettnang)
Danke für die Antwort und Grüße,
Alexander
On Tuesday 05 October 2004 11:48, Alexander Finger wrote:
- Datendurchsatz
Tests haben gezeigt, dass der Durchsatz der RAM-Disk bei ca. 50 MB/s liegt... das finde ich erstaunlich wenig. Ist aber identisch mit dem Durchsatz einer Datei, die aus dem Cache gelesen wird.
Wie kommst du denn auf diese Werte?
test ist eine 100 MB Datei.
Mein Test:
$ time dd if=test of=/dev/null 204800+0 records in 204800+0 records out
real 0m2.129s user 0m0.718s sys 0m1.407s
damit liest du in 512-Byte Blöcken, die Blockgröße des Dateisystems ist AFAIK unerheblich.
Dein Test:
$ time dd if=test of=/dev/null bs=1M 100+0 records in 100+0 records out
real 0m0.199s user 0m0.001s sys 0m0.198s
Wie Du siehst, ist es nicht ganz egal wie man auf die Dateien im Dateisystem "zugreift". Normale Programme lesen mit der Standard-Blocksize. Es ist diese Leistung, bzw. eben die Nicht-Leistung die mich hier vor Probleme stellt.
Wie die reale Anwendung liest, siehst du mit "strace -f trace=file program".
Vielleicht ist auch die Wahl des Dateisystem nicht unerheblich... Beispielen folgend habe ich mich für ext2 entschieden... gibt es eine Alternative?
Ich denke das ist für diesen Fall das Sinnvollste. Evtl kannst du auch mal ramfs probieren (das ist eine dynamische Ramdisk)
In einem lurzen Test erhalte ich ein deutlich anderes Ergebnis: [ronny@bserv tmp]$ time dd of=/dev/zero if=test bs=1M count=100 100+0 Records ein 100+0 Records aus
real 0m1.094s user 0m0.000s sys 0m0.260s
das ist übrigens von Platte
Pjah. Jetzt wissen wir schon mal, dass es gravierende Unterschiede gibt, abhängig davon mit welcher Blocksize gearbeitet wird. Nicht jede Software ist selbst geschrieben, daher ist diese Tuning-Option verschlossen. Noch dazu kann man ein RAM-Disk-Filesystem nicht mit einer anderen Blocksize als 1K anlegen.
s.o. die Blockgröße des Dateisystems ist dabei kaum von Bedeutung. Häufig lesen Anwendungen ganze Dateien auf einmal, oder Blöcke von 4KB. siehe "man 2 read"
Ich denke das Problem ist dein "Benchmark" und nicht die Ramdisk.
Hallo,
On Tue, 2004-10-05 at 20:55, Ronny Buchmann wrote: [...]
damit liest du in 512-Byte Blöcken, die Blockgröße des Dateisystems ist AFAIK unerheblich.
Aber es ist nicht unerheblich mit welcher Blockgröße die Application liest... das ist klar.
[...]
Wie die reale Anwendung liest, siehst du mit "strace -f trace=file program".
Danke für den Tip! Jetzt bin ich schlauer, scheint als hätte "man" sich auf 4K geeinigt.
Vielleicht ist auch die Wahl des Dateisystem nicht unerheblich... Beispielen folgend habe ich mich für ext2 entschieden... gibt es eine Alternative?
Ich denke das ist für diesen Fall das Sinnvollste.
Du denkst ext2 ist das sinnvollste? Ja, dachte ich auch... nur scheint der FS Huddel beim lesen und schreiben nicht unerheblich zu sein, daher die "miese" Performance... ich meine, wir sprechen hier von 400 MHz DDR RAM... auf einer Dual P4 Maschine... mit allen Schnickschnack den man sich denken kann... da sollte eine RAM-Disk Performance von einigen hundert Megabyte doch nun wirklich nicht das Problem sein.
Evtl kannst du auch mal ramfs probieren (das ist eine dynamische Ramdisk)
Jups, werde ich.
In einem lurzen Test erhalte ich ein deutlich anderes Ergebnis: [ronny@bserv tmp]$ time dd of=/dev/zero if=test bs=1M count=100 100+0 Records ein 100+0 Records aus
real 0m1.094s user 0m0.000s sys 0m0.260s
das ist übrigens von Platte
einfach mal cat zu nehmen wäre ja auch zu simpel gewesen... cat und unsere Anwendung verwenden die gleiche Blockgröße beim lesen der Daten.
$ time cat test.bin > /dev/null
real 0m6.672s user 0m0.877s sys 0m5.694s
Die Datei test ist 1 GB gross. Insofern ist die Performance nicht so schlect wie anfänglich erwartet / befürchtet.
Es bleibt nur die Frage: Wieso ist die Performance der RAM-Disk insgesamt so weit hinter dem möglichen Datendurchsatz zurück? Ich hätte intuitiv mit 200 bis 400 MB/s gerechnet... und nicht mit 100 bis 150 MB/s (mehrere Tests). Das Ergebnis entspricht einfach nicht den Erwartungen, zumal hdparm bei den Buffer-Cache Reads im Produktionsbetrieb (auf dem Server ist recht viel los) folgendes ermittelt:
Timing buffer-cache reads: 2220 MB in 2.00 seconds = 1110.72 MB/sec
Also... warum ist die RAM-Disk so langsam?
Häufig lesen Anwendungen ganze Dateien auf einmal, oder Blöcke von 4KB. siehe "man 2 read"
Danke! Der Hinweis auf strace und die "man 2 read" waren sehr hilfreich.
Ich denke das Problem ist dein "Benchmark" und nicht die Ramdisk.
Und davon bin ich noch nicht überzeugt... :-) Mir ist die RAM-Disk noch zu langsam, auch wenn sich das Bild etwas korrigiert hat. Warum kann man der 1 GB/s nicht nahe kommen... Speicher und alles andere wären dazu locker fähig... ist etwa ext2 / ext3 wegen dem Overhead die Bremse?
Wie oben erwähnt, Test mit ramfs folgt.
Dank und Grüße,
Alexander
On Wednesday 06 October 2004 11:57, Alexander Finger wrote:
Du denkst ext2 ist das sinnvollste? Ja, dachte ich auch... nur scheint der FS Huddel beim lesen und schreiben nicht unerheblich zu sein, daher die "miese" Performance... ich meine, wir sprechen hier von 400 MHz DDR RAM... auf einer Dual P4 Maschine... mit allen Schnickschnack den man sich denken kann... da sollte eine RAM-Disk Performance von einigen hundert Megabyte doch nun wirklich nicht das Problem sein.
Evtl kannst du auch mal ramfs probieren (das ist eine dynamische Ramdisk)
Ich habe das mal kurz unter RHEL3 probiert und komme auf 450MB/s
einfach mal cat zu nehmen wäre ja auch zu simpel gewesen... cat und unsere Anwendung verwenden die gleiche Blockgröße beim lesen der Daten.
Machen wahrscheinlich alle Programme, die _zeilenweise_ lesen
Und davon bin ich noch nicht überzeugt... :-) Mir ist die RAM-Disk noch zu langsam, auch wenn sich das Bild etwas korrigiert hat. Warum kann man der 1 GB/s nicht nahe kommen... Speicher und alles andere wären dazu locker fähig... ist etwa ext2 / ext3 wegen dem Overhead die Bremse?
Wie oben erwähnt, Test mit ramfs folgt.
Evtl ist tmpfs noch besser geeignet.
Ramdisks scheinen doch ziemlich überholt zu sein.
Hallo!
On Wed, 2004-10-06 at 21:04, Ronny Buchmann wrote: [...]
Evtl kannst du auch mal ramfs probieren (das ist eine dynamische Ramdisk)
Dazu habe ich im Kernel-Tree keine Docu. gefunden.
[...]
Ich habe das mal kurz unter RHEL3 probiert und komme auf 450MB/s
Leider kann ich den Durchsatz nicht bestätigen. Zumindest nicht bei "grossen" Dateien, und auf einem viel beschäftigten System.
[...]
Wie oben erwähnt, Test mit ramfs folgt.
Evtl ist tmpfs noch besser geeignet.
/dev/shm oder auch tmpfs ist ja ganz nett, aber...
1. Der Speicher kann geswappt werden... 2. siehe erstens.
Damit ist das Kriterium "immer garantiert schnell" dahin.
Ramdisks scheinen doch ziemlich überholt zu sein.
Das sehe ich leider anders, Festplatten sind einfach zu langsam, demnach gibt es keine Alternative.
Grüße und vielen Dank!
Alexander Finger
de-users@lists.fedoraproject.org
-
Alexander Finger -
Ronny Buchmann