Optimale Clustergrößen für SQL Server auf SSDs
– sind 64K noch wichtig?
In letzter Zeit fragen sich mit der Weiterentwicklung von SSDs immer mehr Administratoren: Ist die alte Regel, eine 64K-Clustergröße (auch“File Allocation Unit Size“) für SQL Server zu verwenden, immer noch auf den heutigen Festplatten zutreffend, besonders auf SSDs oder gar Flash? Und: Trifft es auf alle RAID-Typen gleich zu? Diesen Sommer nahm ich mir etwas Zeit, einige IO Benchmarks auf SSDs unter verschiedenen RAID-Konfigurationen (RAID 0, RAID 10, RAID 50) durchzuführen, deren Ergebnisse ich jetzt endlich schaffe zu veröffentlichen.
Das Wichtigste zuerst: Wann immer ihr Empfehlungen aus dem Internet erhaltet, es ist sehr unwahrscheinlich, dass euer System identisch konfiguriert ist. Die Laufwerke, die ich testete, waren HGST Ultrastar SSD800MH.B Enterprise MLC 12Gb/s SAS Solid-State-Laufwerke (HGST ist eine Tochterfirma von Western Digital).
An dieser Stelle ein großes Dankeschön an DB Netz AG, die mir netterweise erlaubten, ihre brandneue Hardware für diese Tests zu verwenden.
Idealerweise könnt ihr eure eigenen Benchmarks machen. Wenn ihr jedoch keine Zeit dazu findet, dann hilft dies hoffentlich vielen.
Das Setup:
Ich hatte Glück, 46 dieser SSDs zu haben, gleichmäßig (2×23) aufgeteilt unter den 2 HBAs im Server (4x Intel E7-8891 v3 à 10 cores, 20 Threads, 2TB RAM), und konnte daher 6 Volumes mit der folgenden RAID-Konfiguration auf einmal vorbereiten, vor den eigentlichen IO-Tests. Die IO-Tests wurden natürlich nacheinander ausgeführt. Die Stichpunkte geben die Laufwerk-Buchstaben aus dem Testserver an:
(N) RAID 10 bestehend aus 4 Disks
gespiegelt über Storage Pools und dann gestriped über Datenträgerverwaltung.
(O) RAID 10 bestehend aus 6 Disks
(M) RAID 10 bestehend aus 10 Disks
(T) RAID 0 (Stripe Set) bestehend aus 4 Disks
gestriped über Storage Pools
(S) RAID 0 (Stripe Set) bestehend aus 4 Disks
gestriped über Storage Pools und nochmal gestriped über Datenträgerverwaltung.
(R) RAID 50 bestehend aus 6 Disks (2×3)
Alle Volumes wurden nacheinander formatiert und getestet mit einer Clustergröße von 4 und 64 K. Es wurden auch einige Tests auf 8 K-Clustergröße gemacht.
So sahen die finalen Volumes im Server aus:
(Das finale Setup bestünde natürlich nur aus 2 oder 3 größeren Volumes, nicht so vielen.)
Die IO-Tests
Diskspd wurde für die Load-Tests verwendet, und die folgenden 6 IO-Test-Konfigurationen wurden für alle Tests verwendet:
| Name | Path | Block size | Operation | Read / Write | Outstanding IO | Threads |
| Read Random 8K | M: | 8K | Random | 100% Read | 8 | 8 |
| Read Random 64K | M: | 64K | Random | 100% Read | 8 | 8 |
| Write Random 8K | M: | 8K | Random | 100% Write | 8 | 8 |
| Read sequential 64K | M: | 64K | Sequential | 100% Read | 8 | 8 |
| Write sequential 8K | M: | 8K | Sequential | 100% Write | 8 | 8 |
| Read sequential 256K | M: | 256K | Sequential | 100% Read | 8 | 8 |
Nicht alle Laufwerkkonfigurationen wurden komplett mit 8-K-Clustergrößen getestet, da ich feststellte, dass die Unterschiede zu 64 K oft zu vernachlässigen waren.
Die Ergebnisse
Die Tests brachten einige unerwartete Ergebnisse, und andererseits einige weniger deutliche Unterschiede als erwartet.
Meine Tests zeigen das Folgende:
- 64 K Cluster Size ist performanter in
a. fast allen Raid-Konfigurationen + Workloads
i. Ausnahmen:
-
-
- Raid50
- 8K Random Reads erstaunlich schlecht (8 und sogar 4 K Clustergröße hier performanter) – das trifft jedoch nicht auf 8 K Random Writes zu, wo 8 und 64 K Cluster beide (gleichermaßen) performanter sind
- Read Random 64K
- Read sequential 64K
- 8K Sequential Writes keine Ausnahme bei 8 K Perf. -> für OLTP Muster evtl. tatsächlich 8 K schneller (4K nicht)
- Raid10 mit 4 Disks: kein relevanter Unterschied
- Raid50
-
- 8 K Cluster Size Performance ist fast dieselbe wie für 64 K
- 4 K Cluster Size ist performanter für Random 8K Reads nur bei RAID 50
- Raid 10 von 10 Disks sind wesentlich schneller bei 64K Random Reads als Sequential Reads! – Boost ab 6 Disks. Für Sequential Reads und Random Writes wurden keine wesentlichen Unterschiede gemessen.
- Die Stripe Sets sind NICHT schneller als die anderen RAID Konfigurationen. Sie sind nur beim Schreiben (Write Random 8K) wesentlich schneller als Raid10. Beim Lesen sind sie manchmal sogar teilweise langsamer als Raid10 bzw. Raid 50.
a. Das entlarvt den Mythos, dass ein Stripe Set von Natur aus performanter als ein echtes redundantes Raid ist! - Raid50 (aus 6 Disks, netto 2,89TB) ist wesentlich schneller als Raid10 (6 Disks, netto 2,16 TB).
- Ein nur über StoragePool konstruiertes Stripe Set (4 Disks) ist schneller als ein über StoragePool und Datenträgerverwaltung konstruiertes Stripe Set.
a. Außer bei 4 K!
Schlüsse:
- 64 K Cluster Size ergibt wirklich noch Sinn als ein Standard. Obwohl es stark von der tatsächlichen Laufwerkkonfiguration abhängt, werden die Ausnahmen auf eine Minderheit von Servern zutreffen.
- Es lohnt sich, abseits von RAID 5 und Raid 10 „Standards“ zu denken.
- Aufgrund von Geschwindigkeit und dem viel höheren Risiko von Ausfällen lohnt es sich im Allgemeinen nicht, auf Stripe Sets zu gehen.
- In meinen Augen (und auch aus Integritätssicherheitsgründen!) macht es keinen Sinn, eine Cluster-Size von 4 K in Betracht zu ziehen – es sei denn, euer Storageanbieter beweist es euch!
- Wer eine bestimmte Workload bis zum letzten IO tunen kann/muss oder ein besonders edles Stück Hardware vor sich hat, sollte genau messen und nicht nach irgendwelchen allgemeinen Empfehlungen (wie auch diesem Blog-Post ;-)) gehen, und die beste Konfiguration für sich ermitteln.
Ihr könnt die kompletten Ergebnisse hier herunterladen, um eure eigenen Schlüsse zu ziehen: 1711_Disk-Benchmark-Results.zip
Ich hoffe, ihr findet diesen Beitrag für eure nächsten Diskussionen und Umsetzungspläne hilfreich.
Andreas
Hallo Benni,
Sorry für die späte Antwort. So hunderprozentig kann ich mich nicht an die Test Parameter erinnern. Den Dateien nach hatte ich aber keine Möglichkeit die Stripe Size (Stripe Size in dem Sinne: Die Einheit in der die Daten auf di verschiedenen Laufwerke reihenweise geschrieben werden) zu ändern. Sie sollte in jedem Fall nicht kleiner der Cluster Size sein. 256 K ist ziemlich Standard. Einen solchen Performancegewinn wie Du ihn mit 64K zu 64K bekommen hast hätte ich ehrlich nicht erwartet. Aber jedes System wird sich da anders verhalten.
Grüße
Andreas
Hast du nur mit der Clustersize des Filesystem oder auch der Stripe Size des RAID Volumes gespielt?
Ich hoffe es ist klar was ich meine. Bei mir ist es so, dass ich im RAID Manager beim erstellen eines Volumes eine Stripesize angeben kann und man kann eben beim Formatieren des Filesystem eine Blockgröße vorgeben.
Stripesize ist bei mir default 256K, da hatte ich mit 4K Filesystem Blöcken nicht 100% Performance.
Also mal Volume neu mit 64K Stripesize und 64K Filesystem Cluster. Ergebnis Verdopplung der I/O Performance.
Jetzt frag ich mich an was liegts? An beiden, evtl nur an einem?
Macht es Sinn beide gleich oder evtl Filesystem 64k, Stripesize 256K (noch nicht ausprobiert)
Bin gespannt was du drüber denkst.