Günstige Server SSD

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hab aber trotzdem ein RaidZ aus 4x1TB 860er Evos am 9305 als HBA. Bilde mir ein, dass die noch ganz gut performen, sind aber auch nur halb voll aktuell.
Halbvoll haben die Controller ja auch ohne TRIM noch genug freie NAND Pages um auch mit vollen Pseudo-SLC Schreibcache schnell schreiben zu können, sofern eben deren Schreibcache aktiv ist. Das ist der Punkt auf den man eben bei Consumer SSDs an SAS HBAs/RAID Controller achten muss, wie ich doch schon hier geschrieben habe. Wie dies bei welchem per Default gehandhabt wird und einzustellen ist, müsst ihr aber schon selbst nachschauen.
Meiner Meinung nach taugt die nichts, lieber die Intel 760P oder die Corsair MP510.
Klar ist die Intel 660p nicht die NVMe SSD mit der besten Performance, eher im Gegenteil, aber ihr Preis pro TB ist eben mit Abstand der besten von allen NVMe SSDs, vor allem in der 2TB Version.

Die Intel 660p ist eben vor allem für leseintensive Anwendungen, da kann sie durchaus schneller als SATA SSDs sein die sogar teurer sind und dafür will besterino sie ja offenbar auch einsetzen:
Für primär Leselast übers Netz wird’s hoffentlich langen.
Man muss ja nicht immer für jede Anwendung die besten SSDs nehmen, die kosten nur mehr und sind dann zuweilen einfach nur unnötig teuer. Wenn die Kohle hat und sie sonst nirgends fehlt, kann man dies machen, aber andernfalls würde ich immer die nehmen die für die Anwendung noch gut genug und möglichst günstig ist.
 
Mit Consumer SSDs an einem HW RAID Controller kann man dann schnell wieder das Problem mit der schlechten Performance wegen deaktiviertem Schreibcache der SSDs bekommen.

Ich hatte seiner Zeit auf der Arbeit einen Test durchgeführt mit 8x Samsung 850 Pro SSDs an einem MegaRAID SAS 9361-8i 2G, PCIe 3.0 x8 Controller mit BBU.
Es hat sich genau das Verhalten herausgestellt was in den ganzen "Best Practice" Artikeln stand bzw. empfohlen wurde. Hierbei sollte man den Schreib-Cache ausschalten, sofern man ein Array aus SSDs aufbaut.
Demnach kann man zu den günstigen Controllern greifen, sofern man keine normalen HDDs im System einsetzen will. Und weil die Consumer-SDDs keine Power-Loss-Protection haben, sollte man auch die "Disk Cache Policy" ausschalten.

Daher sollte man dann schon so "preisgünstigen" Enterprise SATA SSDs greifen, wo man diesen auch nutzen kann.
Wie das Verhalten mit den neuen 94xx Controllern kann ich nicht sagen. Hierbei wird aber immer noch DDR3 verwendet.
 
Zuletzt bearbeitet:
Hi

Danke!

@MarroniJohny
Hast du mal nachgeschaut, ob du NFS auf Sync oder Async laufen hast. So niedrige Schreibwerte kenne ich nur vom Sync-Betrieb. gea hatte mir da vor inzwischen mehreren Jahren mal extremst weitergeholfen.

Unter ZFS Info? Da steht bei beiden Freigaben SYNC auf Standard und RSYNC off. Habe mal testmässig Sync aus gemacht, und siehe da, das kopiert jetzt schneller. Fängt bei einem 75GB File mit ca 100MB/s an, und fällt dann auf gut 50. Soll ich das nur bei den NFS Freigaben aus machen, oder auf dem gesammten Pool? Nur bei der SSD, oder auch bei der HDD? Und was bedeutet das überhaupt?

Bei reservation habe ich 184GB drin, ist das gut so bei einer 2TB SSD?

Wo deaktiviere ich denn den Schreibcache? Im napp-it Admin Interface? Meint Ihr den Schreibcache der SSD selbst, oder der im HBA?

Nicht denken, nachsehen! Gibt es denn keine Tools um zu sehen wie hoch die I/O Last ist, wie z.B. iostat?

Leider liegen die meisten Leute die auf der Basis von "ich denke" anfangen ihr System zu optimieren, am Ende leider falsch, geben dann das Geld an der falschen Stelle aus und habe doch nicht den gewünschten Erfolg gehabt. Analysiere also vernünftig wo das Problem wirklich liegt.

iostat gibt folgendes aus im "idle":

iostat.PNG

Von der SSD auf die HDD zurück schreiben fängt übrigens mit 200MB/s an, und geht dann auf stabile 165MB/s zurück. Wär ja nice, wenn das in die andere Richtung auch gehen würde.
 
Zuletzt bearbeitet:
Und weil die Consumer-SDDs keine Power-Loss-Protection haben, sollte man auch die "Disk Cache Policy" ausschalten.
Und damit deren Schreibperformance in den Keller, sofern sie die Einstellung nicht ignorieren, wie es z.B. die mit Sandforce Controller (alle?) gemacht haben.
Daher sollte man dann schon so "preisgünstigen" Enterprise SATA SSDs greifen, wo man diesen auch nutzen kann.
Eben, die Enterprise SSD mit Full-Power-Loss-Protection interessiert es auch nicht ob man ihnen sagt sie dürfte den Schreibcache nutzen oder nicht, denn dies macht man ja um Datenverlust bei unerwarteten Spannungsabfällen zu vermeiden, die Daten sollen dann nur im Cache des RAID Controllers stehen und dort von der BBU geschützt sein, aber solche Enterprise SSDs haben eben durch ihr Stützkondensatoren die Möglichkeit die Daten aus ihrem Schreibcache auch nach einem Spannungsabfall selbst noch ins NAND zu schreiben.

Wo deaktiviere ich denn den Schreibcache? Im napp-it Admin Interface? Meint Ihr den Schreibcache der SSD selbst, oder der im HBA?
Beide sind wichtig, aber bei der Nutzung von SSDs ist vor allem der Schreibcache der SSD selbst relevant, die Consumer SSDs werden nämlich sehr viel langsamer wenn der nicht aktiv ist.
iostat gibt folgendes aus im "idle":
Im idle nutzt es nichts, wenn dann musst Du das mal beobachten während Du das Backup auf die SSD schreibst und dazu solltest Du nicht nur iostat angeben, sondern z.B. iostat 1 1000 um zu sehen wie die Werte so sind.
 
Das geht halt arg runter:

Am Anfang

iostat1.PNG

Nach 23 Minuten:

iostat23.PNG

Nach 60 Minuten:

iostat60.PNG

mc.PNG

Ein 220GB Verzeichnis war das, bei 450GB Platz noch auf der Freigabe.
 
Zuletzt bearbeitet:
Das geht halt arg runter:

Am Anfang
Wenn ich das richtig sehe, passiert nebenbei nicht sehr viel.

Ein 220GB Verzeichnis war das, bei 450GB Platz noch auf der Freigabe.
Wie gesagt, wenn die SSD nicht getrimmt wird und schon mal ganz voll war, dann bleibt sie dies aus Sicht des Controller für immer (außer man macht ein Secure Erase). Daten werden ja nur ungültig indem die Adresse (LBA) unter der sie geschrieben wurden überschrieben wird oder wenn der LBA getrimmt wird. In den Pseudo-SLC Schreibcache kann man natürlich auch ohne TRIM immer schnell schreiben, der wird ja vom Controller im Idle immer geleert, aber danach kann es eben langsam werden und eben erst recht, wenn die Einstellungen der Schreibcaches ungünstig sind.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh