Welche SSD für RAID 1 ohne TRIM

Welche SSD für RAID 1 ohne TRIM (13 Beiträge, 343 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Frage steht schon im Header. Hintergrund: Ich will auf einem Server möglichst hohe Performance bei gleichzeitiger Redundanz. Allerdings funktioniert TRIM auf md-Raid derzeit noch nicht. Ich brauche daher Platten mit einer guten Garbage Collection, so, dass ich da in keine Pro0bleme laufe.

Erfahrungsberichte wären hilfreich.
--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

TRIM wird auf der lkml immer wieder kontrovers diskutiert... alte SSDs laufen nicht ohne, moderne kommen mit ihrer garbage collection auch so gut zurecht, gleichzeitig verursacht TRIM starke Performanzprobleme (wenn was größeres gelöscht wird muß die SSD erst ein paar tausend TRIM Befehle verarbeiten ehe es weitergeht) ...

Trotzdem sollte es unterstützt werden damit man die Möglichkeit hat, und seit Kernel 3.7 ist das ja auch so. Da diese Kernel-Version früher oder später Einzug in die Standarddistris halten wird bzw. auch heute schon genutzt werden kann brauchst dir da eig. weiter keine Gedanken drum machen.

Ich nutze selbst Crucial m4, würde heute aber wahrscheinlich eine Samsung 830 oder 840 nehmen.

Zum Thema max Performance: http://www.anandtech.com/show/6489/playing-with-op und ich würd mal sagen, wennst auf deiner SSD 25% frei lässt ist der Garbage Collector zu jeder Zeit ausreichend.

auf einem Server möglichst hohe Performance

Dann wäre TRIM eh falsch, oder?

http://www.spinics.net/lists/raid/msg39641.html

If TRIM were well implemented, then it could still have been useful. But it is a synchronous command, and cannot be queued - this means it is slow, and breaks the flow of commands. So the result is that operations such as "delete" can take many times longer to complete if TRIM is enabled.

Ich würde - wie schon empfohlen - auf 10-20% Overprovisioning setzen:
http://www.thomas-krenn.com/de/wiki/SSD_Over-Provisioning_mit_hdparm

hdparm -Np aktiviert die Host Protected Area. Dabei wird die Anzahl an sichtbar bleibenden Sektoren direkt nach der -Np Option angegeben (ohne Leerzeichen dazwischen). Als weitere Parameter sind die Optionen --yes-i-know-what-i-am-doing und der Devicename notwendig:

Der Einwand gegen Trim erscheint mir als wenig relevant. Große Datenmengen löschen ist nicht so häufig, und da interessiert die Performance wenig.

Also werde ich auf den neuen Kernel setzen, der das kann, und bis dahin auf die Garbage Collection vertrauen.
--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

Der Einwand gegen Trim erscheint mir als wenig relevant.

Wie sicher bist Du Dir da? [ keine blöde Frage, ehrlich gemeint ]

Delete und Truncate gibt es schon öfters... Und jedesmal entspricht das Ding einer Barrier, soweit ich das verstehe. Bei SSDs wohl nicht so das Riesen-Thema, aber wohl doch IOPS-reduzierend (und wegen der IOPS legen wir uns ja SSDs zu).

Wenn man konstant hohe IOPS will - führt nach meinem Nachlesen nichts an einem Overprovisioning von 25% vorbei - so teuer das ist. Wenn einem die IOPS aber wurscht sind - braucht man eh keine SSD

.

In meine Rechner kommen für das System nun SSDs (waren bei Amazon recht günstig). Von einer 500er werde ich nur wagen, 350 zu verwenden - und das obwohl ich da kein md drunter fahre und daher TRIM zur Verfügung habe...

Die Unkalkulierbarkeit der Auswirkung von TRIM stört mich total - und man liest des öfteren, dass TRIM nur zu der Zeit Sinn machte, als der GC schwach war. Du schwörst aber weiter auf TRIM - warum?

[ Echt keine blöde Frage und auch kein Versuch, dich wo hinzubewegen. Meine SSDs kommen halt in ein paar Tagen - und ich will bis dahin meine Überlegungen und Planungen abgeschlossen haben

]

Delete und Truncate gibt es schon öfters... Und jedesmal entspricht das Ding
einer Barrier, soweit ich das verstehe. Bei SSDs wohl nicht so das
Riesen-Thema, aber wohl doch IOPS-reduzierend (und wegen der IOPS legen wir
uns ja SSDs zu).

Meiner Überzeugung nach sind diese Operationen selten zeitkritisch.
Denn gößere Mengen an zu löschenden Daten fallen an, wenn: Ich Dateien verschiebe oder Lösche.
Das sind aber Fälle, die selten wirklioch Zeitkritisch sind.

Das andereProblem sind die Datenbanken. Die sind aber so organisiert, dass bei jeder Operation, die Dateien wachsen. Und nur bei Datenbankwartungsoperationen wie vacuumdb wirklich gelöscht wird. Die time ich aber sowieso zu Zeiten, wo ich das verschmerzen kann.

Daher habe ich liebr einen Leistungseinbruch während der seltenen Ereignisse des Löschens, und volle Leistung währen des Regelbetriebs, wo ich primär R/W Ops habe.
--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

Ich befürchte, dass Du die Parallelität vergisst...

Angenommen, es rennt logrotate an: Viele Dateien truncated oder deleted. In der Zeit wird es halt bitter für PostgreSQL - und dort kann schon zeitkritisches rennen.

Ebenso diverse Scripts, die viele tmp-Dateien anlegen und wieder löschen...

Dem könnte man aber auch mit anderen begegnen.

Ich spiele mit dem Gedanken, dass /tmp und /var/tmp ein tmpfs werden. Was hältst Du davon? Einerseits um deletes zu vermeiden - andererseits um die Lebensdauer der SSD zu erhöhen. Aus letztem Grund denke ich auch mal an, die Swappiness auf beinahe-0 zu setzen. FS-Caches braucht man bei SSD eh weitaus weniger, nehme ich an...

Daher habe ich liebr einen Leistungseinbruch während der seltenen Ereignisse
des Löschens, und volle Leistung währen des Regelbetriebs, wo ich primär R/W
Ops habe.

Die volle Leistung hast aber bei Overprovisioning (was man scheinbar immer braucht - siehe hdparm -N) sowieso... Wobei ich glaube, dass eine große Anzahl an W durchaus den GC belastet und das wieder nach Overprovisioning schreit...

Irgendwie kämpfe ich beim Verständnis der idealen Konfiguration einer SSD... Es gibt tausende Schrauben, aber alle sind drecks-indirekt...

Angenommen, es rennt logrotate an: Viele Dateien truncated oder deleted. In
der Zeit wird es halt bitter für PostgreSQL - und dort kann schon
zeitkritisches rennen.

Nun sind auch das getimete Aktionen. Die finden sowieso zu Zeiten stett, wo es mir ganz egal ist, wie schnell sie sind, da sonst eh keine Last anliegt.

Ebenso diverse Scripts, die viele tmp-Dateien anlegen und wieder löschen...

Das einzige was mir jetzt einfallen würde, was halbwegs bedeutsam ist, wäre der Apache, der da seine Sessions ablegt. Und auch da. Öffnen und schreiben sind Zeitkritisch. Das Löschen nicht.

Ich spiele mit dem Gedanken, dass /tmp und /var/tmp ein tmpfs werden. Was
hältst Du davon?

Wenig. Denn es spielt sich da kaum was ab. Ich habs einmal probiert. Hat aber nichts an spürbarer Performance gebracht.

Aus letztem Grund denke ich auch mal an, die Swappiness auf beinahe-0 zu
setzen. FS-Caches braucht man bei SSD eh weitaus weniger, nehme ich an...

Auch da bin ich nicht überzeugt, ob es den Aufwand wert ist:
auf 4 Maschinen:

MemTotal:        8075840 kB
MemFree:         3202284 kB
Buffers:         2855720 kB
Cached:          1004348 kB
SwapTotal:      15998972 kB
SwapFree:       15998972 kB

MemTotal:       16349260 kB
MemFree:         6995980 kB
Buffers:          298180 kB
Cached:          6653772 kB
SwapTotal:      16776360 kB
SwapFree:       16776360 kB

MemTotal:       16392520 kB
MemFree:          903240 kB
Buffers:          374140 kB
Cached:         12428180 kB
SwapCached:          228 kB
SwapTotal:       7812488 kB
SwapFree:        7811252 kB

MemTotal:        3789908 kB
MemFree:          336936 kB
Buffers:          592136 kB
Cached:          1116468 kB
SwapCached:        18776 kB
SwapTotal:      24579444 kB
SwapFree:       24526192 kB

Also swap Nutzung ist zu vernachlässigen, und wenn sie stattfindet, ist sie gecached.

Unter Windows, das ich auf den VMs habe, ist es so, dass ich da sowieso mehr oder weniger blind glauben muss, dass die wissen, was sie tun bei der Speicherverwaltung. Und sonst gilt für die MS-SQL Datenbabnk das selbe. Plattenplatz wird da nur freigegeben, wenn ich eine Wartung starte.

Ich bin daher sehr überzeugt davon, dass ich mit Trim besser fahre, als auf die statistische Wahrscheinllichkeit zu hoffen, dass mir die garbage collection den Müll rechtzeitig aus dem Weg räumt.

--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

Danke für die aufwendige Antwort!

Öffnen und schreiben sind Zeitkritisch. Das Löschen nicht.

Eh... Meine Sorge ist aber, dass - wenn ein Löschen anfällt - _andere_ Services benachteiligt werden.

Hat aber nichts an spürbarer Performance gebracht.

Stimmt - riesig viel ist da nicht los. Bei mir sind die Dateien dort halt i.d.R. klein - daher wäre es simpel möglich.

Also swap Nutzung ist zu vernachlässigen, und wenn sie stattfindet, ist sie
gecached.

Ein Cached-Swap ist mir neu. Was bringt der? Da wurde in den Swap geschrieben - es befindet sich aber noch im Cache? Wenn ja - dann ist das natürlich I/O...

Unter Windows, das ich auf den VMs habe

Windows sieht aber eh nicht direkt die Platten - sondern geht ja über den Host-Cache, oder? Da wäre es dann auch wurscht...

.

Ich bin daher sehr überzeugt davon, dass ich mit Trim besser fahre, als auf
die statistische Wahrscheinllichkeit zu hoffen, dass mir die garbage
collection den Müll rechtzeitig aus dem Weg räumt.

Das sehe ich schon... Meine abschließende Frage: Ist das eher so ein Bauchgefühl bei Dir (keine Kritik) - oder hast Du irgendwo Zahlenmaterial dazu gefunden? Es ist einfach so, dass mein Bauchgefühl das anders sieht... Eben _weil_ ich noch kein Zahlenmaterial gefunden habe.

Das sehe ich schon... Meine abschließende Frage: Ist das eher so ein
Bauchgefühl bei Dir (keine Kritik) - oder hast Du irgendwo Zahlenmaterial dazu
gefunden?

Nein. Keine Zahlen. Nur so, dass ich am Notebook auf das Discard vergessen habe, und die selbe ssd die ich im Standpc habe, sich dort um einiges zäher anfühlt.
--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

Nein. Keine Zahlen. Nur so, dass ich am Notebook auf das Discard vergessen
habe, und die selbe ssd die ich im Standpc habe, sich dort um einiges zäher
anfühlt.

Aaah... Danke für den Hinweis. Bleiben nur noch wenige Fragen:
- Hast Du Overprovisioning am Notebook eingesetzt (glaube mal nicht, wenn vergessen).
- Inwieferne zäh? Nicht wirklich wie eine Spindelplatte, oder?
- An der Hardware (Laptop vs. StandPC - anderer SATA-Controller) kann es nicht liegen?
- Hilft es nicht, das TRIM nachträglich zu aktivieren? Beispielsweise Laptop sichern, alles TRIMmen, neu aufsetzen und Revovern?

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung