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 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:

  1. 64 K Cluster Size ist performanter in
    a. fast allen Raid-Konfigurationen + Workloads
    i. Ausnahmen:
      1. Raid50
        1. 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
        2. Read Random 64K
        3. Read sequential 64K
        4. 8K Sequential Writes keine Ausnahme bei 8 K Perf. -> für OLTP Muster evtl. tatsächlich 8 K schneller (4K nicht)
      2. Raid10 mit 4 Disks: kein relevanter Unterschied
  1. 8 K Cluster Size Performance ist fast dieselbe wie für 64 K
  2. 4 K Cluster Size ist performanter für Random 8K Reads nur bei RAID 50
  3. 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.
  4. 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!
  5. Raid50 (aus 6 Disks, netto 2,89TB) ist wesentlich schneller als Raid10 (6 Disks, netto 2,16 TB).
  6. 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

Tags:

Categories: PerformanceStorage Engine

0 Kommentare

Dein Kommentar

Want to join the discussion?
Feel free to contribute!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.