Extreme Unterschiede: /run vs SSD 830

[zwiebelchen]

Hi,

habe mal interessehalber ausprobiert, was die RAM-Disk unter Linux (standartmäßig unter /run gemountet bei Debian Wheezy) so schafft. Aber was da für Ergebnisse raus kamen, da musste ich selber erstmal schwer staunen :

Was habe ich gemacht:
-SQL-Script für Inserts erstellt (ca. 78.000 Stück, jeweils nur eine Spalte + auto PK)
-das Script jeweils in den entsprechenden Mountpoint kopiert
-die DB im "ohne-Import"-Zustand auf beide Mountpoints kopiert
-"time sqlite3 database.db < script.sql" ausgeführt (jeweils in den entsprechenden Ordnern / Mountpoints)

Die Datenbank ist eine SQLite3 (enthält nur ca. 100 Einträge in 2 Tabellen, also quasi "leer"), das Dateisystem ist ext4 auf meiner Samsung 830 / SATA6G (wo quasi alles drauf läuft) und an RAM laufen 16 GB (4 x 4 GB, Corsair XMS3 DDR3-1600) auf nem Asus P8H77-V mit nem Xeon E3-1230V2.

So, nun wirds spannend:

ca. 3 Sekunden (Ram-Disk) vs. 22 MINUTEN !!!

WAS ZUM TEUFEL !?!?

Ist es das Filesystem (Journaling) ?

Das eine RAM-Disk schneller ist, klar, aber das ist doch nicht mehr normal

BTW.: die CPU hat sich ziemlich entspannt, es liegt also definitiv am Durchsatz zum Speicherort / Mountpoint / Filesystem...

 

[austi24]

anbei ein Bild meiner 4GB RAM DISK. Im sequentiellen Lesen ist sie 5x so schnell wie ne SSD830. Im Schreiben noch etwas mehr. Und auch die Reaktionszeit ist besser. Das Filesystem wird einiges ausmachen bei Dir.

 

[DaZpoon]

Jeder INSERT wird doch direkt in die SQLite-Lokaldatenbank gespeichert. Dabei wird nun nicht nur der Chunk an Daten in die DB geschrieben, sondern auch aller Filesystem-Overhead erledigt.
Auf der SSD bedeutet schreiben aber eben auch immer einen Prozess aus lesen, ändern und wieder zurückschreiben. Und gerade bei sehr kleinen Blöcken die geschrieben werden knickt die Schreibrate eben stark ein, ca. 50MB wenn's gut kommt.
Beim RAM ist der Schreibprozess deutlich einfacher. Hier kann man wirklich bei aktuellen Konfigurationen mit über 12GB/s schreiben/lesen.

Interessanter wäre in dem Falle aus meiner Sicht mal, wie sich das ändert wenn du die Speicherfrequenz absenkst/erhöhst.

 

[obi68]

Diesen Thread sollte jedem unter die Nase gehalten werden welcher immer noch glaubt eine RAM-Disk bringe nichts. An meinem Produktiven PC arbeite ich immer noch mit XP x86 und einer 28 GB grossen RAM-Disk, die Performance auf dieser Disk kann zur Zeit durch nichts getoppt werden.

 

[supastar]

Ja und, was ist daran jetzt so unerwartet?
War doch zu erwarten, ich meine, der RAM hängt doch direkt an der CPU.

Das Problem an der RAM-Disk ist halt ganz einfach, dass sie unpraktisch zu nutzen ist, da man die Daten erstmal reinkopieren muss.

 

[Nugget100]

Vor Kurzem ist im Ext 4 Dateisystem ein Bug bekannt geworden und gleichzeitig ein Patch zu Verfügung gestellt worden der das behebt. Im Regelfall reicht für SSD Ext 3 Dateisystem zu 100% aus. Kapazitätsgrößen AB 4 - 6TB (Raid Systeme oder einzelene Platten) da würde das Ext 4 Dateisystem auch Sinn machen. Also bei der Installation nicht immer auf automatisch durchklicken sondern auch mal sich die Schritte zur Installation ansehen und Konfigurieren.

Was SSD betrifft so hab ich mit einer OCZ Agility 3 gute bis sehr gute Erfahrungen gemacht.
SQL Datenbank mit 250.000 Einträgen ( Name,Vorname,Geboren,Straße, Hausnummer, Stadt ,Telefon)
Und das mit Ext 3 !
Das SSD Modell ist dieses hier : KLICK

Da können Zugriffe von bis zu 1000 Gleichzeitig auf der SSD stattfinden Sie bricht nicht ein. Auch 1000 gleichzeitige Durchsuchungen der Datenbank (Stichwortsuche). Zugriffszeiten liegen im Bereich 2-4 sek ( je nach Prio). Eine Ramdiskt nutze ich dafür nicht.

Wenn ich eine Ramdisk haben will dann setzte ich diese direkt in den Arbeitsspeicher ein und Nutze Sie von dort aus. Setzt vorraus das man mit viel Arbeitsspeicher arbeitet. Also mit 4,8,16 GB Ram ist es nicht getan. Interessant wird es erst AB 32 GB Ram. Solche Ram Disks haben einen Speed der spürbar ist.

 

[westef]

Vor Kurzem ist im Ext 4 Dateisystem ein Bug bekannt geworden und gleichzeitig ein Patch zu Verfügung gestellt worden der das behebt. Im Regelfall reicht für SSD Ext 3 Dateisystem zu 100% aus. Kapazitätsgrößen AB 4 - 6TB (Raid Systeme oder einzelene Platten) da würde das Ext 4 Dateisystem auch Sinn machen. Also bei der Installation nicht immer auf automatisch durchklicken sondern auch mal sich die Schritte zur Installation ansehen und Konfigurieren.

Warum sollte man mit Absicht ext3 verwenden wenn es keinen Grund gibt? ext4 ist nicht nur neuer, sondern auch schneller:

ext3 can generally be avoided: it is often slower than ext4 or xfs, yet it has the more limited feature set; for example, it is quite prone to fragmentation.

Was SSD betrifft so hab ich mit einer OCZ Agility 3 gute bis sehr gute Erfahrungen gemacht.
SQL Datenbank mit 250.000 Einträgen ( Name,Vorname,Geboren,Straße, Hausnummer, Stadt ,Telefon)
Und das mit Ext 3 !
Das SSD Modell ist dieses hier : KLICK

Da können Zugriffe von bis zu 1000 Gleichzeitig auf der SSD stattfinden Sie bricht nicht ein. Auch 1000 gleichzeitige Durchsuchungen der Datenbank (Stichwortsuche). Zugriffszeiten liegen im Bereich 2-4 sek ( je nach Prio). Eine Ramdiskt nutze ich dafür nicht.

Du greifst lesend drauf zu, der Autor hat aber die Schreibrate getestet. Und 2-4 Sekunden zugriffszeit? Du meinst eher "ms" oder?

Hast du das ganze mal mit ext4 getestet?

Wenn ich eine Ramdisk haben will dann setzte ich diese direkt in den Arbeitsspeicher ein und Nutze Sie von dort aus. Setzt vorraus das man mit viel Arbeitsspeicher arbeitet. Also mit 4,8,16 GB Ram ist es nicht getan. Interessant wird es erst AB 32 GB Ram. Solche Ram Disks haben einen Speed der spürbar ist.

Ich verstehe deinen Satz nicht? Was heißt "setze ich diese direkt in den Arbeitsspeicher ein und nutze sie von dort aus"? Das ist doch der Sinn einer RAM-Disk. Die kann man nur im Arbeitsspeicher anlegen oO. Außerdem ist es für den Speed doch unerheblich, ob die Ram disk jetzt 4 oder 16 GB groß ist.

 

[mensch183]

@zwiebelchen
Das sqlite macht in Standardeinstellung nach jeder Transaktion(T), also bei dir nach jedem Insert, einen fsync() auf das Datenbank-File. Das gehört sich so für eine Datenbank, die die geänderten Daten sicher auf der Platte wissen möchte, bevor sie dem Nutzer den Erfolg der T zurückmeldet. Das dauert bei einer Festplatte natürlich recht lange.

Wenns dir um Geschwindigkeit für viele Inserts geht, kannst du folgende 3 Dinge tun:
1. die syncs nach jeder T weglassen.
2. die vielen Inserts nicht als viele einzelne T laufen lassen sondern in eine T zusammenfassen.
3. das DB-File irgendwo ablegen, wo fsync() entweder schnell ist (RAM-Disk) oder ignoriert wird (bestimmte Mount-Optionen je nach Filesystem)

Da du nicht der erste bist, der über dieses "Problem" stolpert, finden sich die ersten beiden Antworten in den FAQs zu SQLite.

Realisiere also 1. und 2. in deinem SQL-Skript und die Sache wird auf Platte ähnlich schnell sein wie auf der RAM-Disk. Und nein, auch eine SSD ist bei winzigen writes mit sync dazwischen nicht annähernd so schnell, wie die tollen "x tausend writes/s" der Werbung suggerieren. Die syncs machen die ganzen Optimierungen der SSD kaputt.