[Suche] relevante/praktische Berichte|Tests|Benchmark für SSD Caching (nur für Daten)

[jbase00]

Hi, ich versuche erneut meine Frage zu formulieren, falls etwas unklar ist, bitte ich euch um Verständnis.

Es geht um die SSD-Caching Technik, welche eine HDD beschleunigen sollte. Ich würde gern wissen, wie stark diese Technik in realer Situation durch schlägt, wenn man bereits eine SSD als OS Partition hat.

Ich synchronisiere jede Woche ca. 600 GB Daten und davon werden ca. 10-30GB verändert (gelöscht/kopiert) + ca. 5 GB für System Backup.
Benutze den Rechner für Visual Studio, Eclipse und VMware, einige andere Sache noch dazu ...
Wenn ich Visual Studio starte, dann wird das Programm zwar im SSD gestartet aber die Daten müssen von HDD geladen.
Oder bei Compilieren, würde viele Dateien gelöscht und erneut generiert, das dauert für mein Verhältnis zu lange, weil diese Daten eben auf die HDD gelesen und geschrieben werden müssen.

Jetzige System: Konfiguration 1
SSD: OS und Programme (Partition C)
HDD: Reine Daten (Partition D)

Meine Idee wäre eine kleinere SSD (64GB) als Caching zu einzurichten.

Konfiguration 2
SSD: OS und Programme (Partition C)
HDD: Reine Daten (Partition D)
SSD-Caching: Cache für HDD (Partition S)


Herkömmliche Konfiguration zum Test waren entweder
SSD: OS + Programme + Daten
oder
HDD: OS + Programme + Daten
oder
SSD-Caching + HDD: OS + Programme + Daten

Also ich interessiere für den "Mehrgewinn" von Konfiguration 2 zu Konfiguration 1, mach es für Hardcore User bemerkbar?

Aus einigen Tests kann ich sehen/lesen, das ein reine SSD-System schneller läuft und schneller lädt als ein reine HDD-System, aber wie verhält es sich nur bei einem "gemischte" System?

Frage:
Verliere ich meine tolle Caching, wenn ich 600GB Daten jede Woche synchronisiere? Es werden zwar nicht alle 600GB Dateien gelesen aber die Metadata werden aufjeden fall gelesen und jede Datei muss mindesten 1 Mal zugegriffen werden.

Gewinne ich durch SSD-Caching Zeit? Beim Compilieren? Wenn jedes mal tausende Dateien gelöscht und erneut generiert wird?

SSD bringt anscheinend doch sogar mehr FPS im Spiel, kann SSD-Caching das auch, wenn die Daten richtig gecacht wurde?
Aktive Anwendung? z.B: Festplatte in*di*zie*ren?
Wie genau wird es gecacht? Nur bei kleinere Dateien oder auch größere wie VMware Festplatte-Image?

Ich hoffe, ihr versteht was ich meine. Die Frage ist schon sehr spezifisch und für mich schwer zu erklären.

Einige Tests und Videos, die ich gefunden habe.
https://www.youtube.com/watch?v=1CUwUvhMC_E
https://www.youtube.com/watch?v=InermmePbd4
https://www.youtube.com/watch?v=RbuKRH0aHRM
http://www.hardcoreware.net/ssd-cache-performance/2/
http://www.com-magazin.de/praxis/ss...age=1_ssd-caching-es-gibt-drei-moeglichkeiten
Com-Magazin hat +75% gemesen, diese Zahl scheint mir aber zu viel hoch gegriffen.

An Experten:
Welche Caching-Methode wird bei unterschiedliche Caching Hardware-Lösungen bzw. Software-Lösungen angewendet? Hat jemand zufällig Information darüber?

 

[Hallo32]

Compilieren:

Kopiere dein Projekt einmal auf die SSD und schreibe auch die erzeugten Dateien auf die SSD und vergleiche die Zeit zum Kompilieren von der SSD mit der Zeit von der HDD. Dann hast du zumindest eine Idee, wie viel es bringen könnte und ob nicht evtl. der CPU bremst. Wie sieht die Auslastung des RAMs beim compilieren aus?

Viele Caching Tools cachen auf LBA Basis und nicht auf Datei Basis.

 

[Holt]

Also ich interessiere für den "Mehrgewinn" von Konfiguration 2 zu Konfiguration 1, mach es für Hardcore User bemerkbar?

Gerade beim Caching sind die Vorteiel extrem vom Nutzungprofile abhängig und daher nicht vorherzusagen. Ist wie beim Hybridauto, auf der Autobahn bei konstanter Geschwindigkeit ist die ganze Hybridtechnik nur Balast, in der Stadt bei Stop-and-Go bringt es eine Menge.

Verliere ich meine tolle Caching, wenn ich 600GB Daten jede Woche synchronisiere? Es werden zwar nicht alle 600GB Dateien gelesen aber die Metadata werden aufjeden fall gelesen und jede Datei muss mindesten 1 Mal zugegriffen werden.

In dem Fall vermutlich nicht, da ja nur deren Metadaten, also die Einträge im Directory über die Dateien wie deren Namen, Größe und das Datum der letzten Änderung gelesen werden und das dürfte weniger als die Cacheröße sein, wenn es nicht sehr viele kleine Dateien sind. Das hängt davon ab ob und wie vielie Dateien wirklich gelesen werden und welches Volumen dabei zusammen kommt.

Gewinne ich durch SSD-Caching Zeit? Beim Compilieren? Wenn jedes mal tausende Dateien gelöscht und erneut generiert wird?

Da das gleiche Projekt vermutlich öfter hintereinander compiliert wird und ein Projekt wohl kaum den Rahmen des Caches sprengt, dürfte hier der Gewinn deutlich sein. Wie sehr dürfte auch davon abhängen ob der Cache wie üblich nur als Lesecache oder ausnahmsweise auch als Schreibcache wirkt, denn beim Compilieren werden ja auch viele Dateien geschrieben.

Wie genau wird es gecacht? Nur bei kleinere Dateien oder auch größere wie VMware Festplatte-Image?

Die die ganze Cache Lösungen i.d.R. unterhalb der Filesystemebene liegen, HW-Caches garantiert, kann nur auf Basis von LBAs und Zugriffslängen gecacht werden, Dateien oder Partitionen kennen Platten ja nicht, das ist eine Sache des Betirebssystems. Jeder Zugriff wird vom Betriebssystem (dort konkret dem Treiber des SATA Host Controllers) als ATA Befehl weitergereicht und sieht i.d.R. so aus, dass damit eine LBA und bis zu 2^16 folgenden LBAs zum Lesen oder Schrieben adressiert werden. Das kommt dann bei der Cacheverwaltung an und zu welcher Partition oder Datei diese LBAs gehören, kann die gar nicht wissen.

Dagegen ist der Diskcache den Windows selbst schon mitbringt natürlich im Vorteil, der kennt die Dateien und kann auf der Basis schlauer entscheiden.

An Experten:
Welche Caching-Methode wird bei unterschiedliche Caching Hardware-Lösungen bzw. Software-Lösungen angewendet? Hat jemand zufällig Information darüber?

Nein, die halten die Hersteller natürlich zurück. Aber gehen mal davon aus, dass es kein sehr ausgeklügelter Algorithmus sein kann, weil der Verwaltungsaufwand zu hoch wäre. Überlege mal wie viele LBAs eine 4TB HDD hat, das sind 4*1000^4 Bytes und bei 512 Byte pro LBA dann 7.812.500.000 LBAs und selbst wenn man auf 4k Zugriffe optimiert, also nur je jeden 8. LBA verwaltet, noch immer 976.562.500 Einträge, fast eine Milliarde! Würde man nur ein Byte für einen simplen Zähler der Anzahl der Zugriffe oder als einen Timestamp für den letzten Zugriff pro Eintrag speicher, wäre das fast 1GB an Daten, so viel RAM müsste eine SW Lösung sich mindestens reservieren und eine HW für den Controller haben, dann müss darauf schnell darauf zugegreifen und bei Lesenvorgang von Daten die im Cache stehen entscheiden werden, ob diese nun aufgenommen und vor allem welche dafür verdrängt werden. Und in einem Bytes bekommt man weder einen sinnvollen Zähler noch ein brauchbares Zugriffsdatum unter, der Überlauf wäre schnell erreicht, für eine sinnvolle Verdrängungstrategie die auch dem Zeitpunkt der letzten Zugriffes oder der Häufigkeit der Zugriffe bzw. besser noch der Kombination beider Werte basiert, dürfte also die Resourcen fehlen.

Daher vermute ich da ganz einfach Algorithmen die einfach jeden Zugriff unterhalb einer bestimmten Länge in den Cache aufnehmen, die sind zwar weniger effektiv aber einfach zu implementieren, denn der Controller muss ja auch noch verwalten welche Daten im Cache stehen, da hängt der Aufwand nur von der Größe des Caches ab und ist entsprechend deutlich geringer.

Wenn Du selbst SW entwickelst kannst Du Dir ja mal Strategieen für so eine Cacheverwaltung ausdenken die eine 4TB HDD mit einer 60GB SSD cache können ohne gewaltige Resourcen zu verbrauchen und dann auch funktionieren, wenn sie z.B. bei der Verwaltung der Buchungen eines Stations eingesetzt werden, wo letzte Woche dann z.B. das Endspiel war, also sehr viele Zugriffe passiert sind die aber schon nicht mehr interessieren und dieses Wochende spielen die alten Herren, die Daten fürs letzte Wochenende dürfe also ewig im Cache bleiben, nur weil so ein Andrang vielleicht erst beim nächsten Endspiel übertroffen wird.

Com-Magazin hat +75% gemesen, diese Zahl scheint mir aber zu viel hoch gegriffen.

Diesen Link hatte ich Dir schon gepostet, lies Dir das mal durch, denn wird klar wieso die Tests meist solche Beschleunigungen ermitteln, eben weil alles mehrfach hintereinander gemacht wird und damit der Cache optimal mit den Daten geladen wird. Die dort verlinkten Screenshots zeigen auch deutlich, dass das Caching nur bei kurzen Zugriffen funktioniert, bei HD Tune bei 64k ja aber bei 1MB nicht mehr und bei HD Tach sieht man an der Zugriffszeit deutlich, dass schon beim ersten Lesen die Daten in den Cache übernommen wurden, der Algorithmus also simpel sein muss, vorher wurden ja auch andere Tests gemacht und die Daten von denen wurden schon beim ersten Lauf von HD Tach wieder verdängt.

Deine Links habe ich mir jetzt nicht angeschaut, aber in jedem Fall solltest Du Dich über die Methodik des Tests informieren bevor Du die Ergebnisse bewertest. Mehrfache Wiederholungen des gleichen Ablaufes sind bei Tests beliebt um Messfehler zu minimieren, wenn aber nur die Mittelwerte angegeben werden, sind sie für alles was mit Caching arbeitet schlicht irreführend und nicht praxisrelevant.

Ergänzung (1. Februar 2015)

PS: Informiere Dich auch, ob die gewünschte Lösung überhaupt Datenlaufwerke cache kann, da gibt es bei einigen auch Einschränkungen auf das Systemlaufwerk!