Optimierung des SQL Servers mit mehreren Datenträgern

[natZONE]

Im JTL Blog wird erklärt, welche Maßnahmen sich zur Optimierung des SQL Servers eignen. Insbesondere wird dabei auch betont, dass die eigentliche Datenbank (also die *.mdf Datei) und die Logfiles sowie die TempDB Dateien jeweils auf unterschiedliche Festplatten zu verteilen sind.

Ist dieser Hinweis auch mit größeren Geschwindigkeitsvorteilen bei SSDs anstelle von herkömmlichen Festplatten verbunden?

In einem meiner Notebooks habe ich eine Samsung 850 Pro 512GB (SSD1) und eine 1TB (SSD2) verbaut (SATA 3.0). Die vorherige Festplatte habe ich gegen die 512GB-SSD (SSD1) ausgetauscht und das DVD-Laufwerk gegen die 1TB-SSD (SSD2).

Betriebssystem und SQL-Server befinden sich aktuell auf SSD1, *.mdf Datei sowie alle Logs und die acht TempDB Dateien auf SSD2. Weitere SSDs kann ich in dem Notebook nicht verbauen mangels Platz und Anschlüssen.

Ist meine derzeitige Konfiguration optimierungsbedürftig? Habt ihr konkrete Erfahrungen mit anderen Konfigurationen und dabei erhebliche Performancegewinne feststellen können?

 

[css-umsetzung]

So wie ich es verstanden habe, würden auch Virtuelle Festplatten reichen, dann wäre nur der Datendurchsatz die Begrenzung.

 

[natZONE]

Es geht mir ja gerade um den Datendurchsatz, dieser soll mit maximaler Geschwindigkeit ablaufen. So wie es ausschaut, geht dann an einem System mit vier oder fünf physischen (nicht virtuellen) Datenträgern kein Weg vorbei, was wiederum bedeutet, dass für diesen Anspruch ein Desktop-System mit ausreichend vielen Anschlüssen (am besten PCIe für M.2 SSDs) eingerichtet werden muss. Ein Notebook stößt dabei zwangsläufig an Grenzen.

 

[css-umsetzung]

Ich werde da niemanden reinreden, aber Laptop sagt mir, das nur einer daran Arbeitet,
da denke ich, muss man nicht versuchen die letzte Millisekunde zu finden.

Auch sollte am Ende, immer das Verhältnis zwischen Hardwarekosten und Geschwindigkeit, ausgeglichen sein.

 

[natZONE]

Hardwarekosten wären irrelevant. Ich möchte mittelfristig ein auf Datendurchsatz optimiertes System haben, an welchem dann zwei oder drei Mitarbeiter arbeiten werden. Mich interessiert in erster Linie, ob jemand eigene Erfahrungen mit solch einem System (d. h. mehrere separierte SSD-Datenträger, Arbeitsspeicher zwischen 128 und 512 GB RAM) hat und wie die o. a. Dateien idealerweise anzuordnen sind. Im JTL Blog sind ja schon einige Hinweise gegeben worden. Dort wurde etwa davon abgeraten, bei einem System mit nur zwei Festplatten *.mdf und TempDB auf demselben Datenträger zu verwalten.

 

[exe]

Hi !

Ich kann dir wegen der MSSQL nur wenig sagen, allerdings gibt es grundlegende Logiken. Betriebssystem und die reine Datenbank sollten immer getrennt auf verschiedenen Festplatten laufen. Alle weiteren können oder sollten auf andere Festplatten ausgelagert werden, wenn diese hohe Schreibraten benötigen und damit den primären Vorgang ausbremsen könnten.

Was ebenfalls noch hilft, sind SSD mit NVMe, da kitzelt man noch mal etwas an der Zugriffszeit.

 

[natZONE]

Das wird in den Ratschlägen des JTL Blogs für ein System mit zwei Festplatten anders erklärt: Betriebssystem und Datenbank auf dieselbe Festplatte, TempDB und die Logs auf jeweils separate Festplatten. NVMe ist hinfällig, da ich bereits M.2 erwähnt habe. Die grundlegende Logik der Trennung der erwähnten Dateien ist mir bereits klar. Mir geht es um konkrete Erfahrungswerte bei dieser Optimierung.

 

[elevennerds.de]

Hallo,

ich empfehle für maximale Performance folgende Konfiguration:

2 x RAID10 mit jeweils mindestens 4 SSDs (vernünftige Server-SSDs)
1 x SSD (diese SSD muss sehr schnell sein, perfekt wäre hier eine SSD die mittels PCIe angebunden ist)

Betriebssystem wird auf ein RAID10 installiert. Wichtig für MSSQL ist, dass der RAID-Controller nativ mit 64kb-Blöcken arbeitet und alle Dateisysteme, auf denen Datenbankdateien abgespeichert werden, ebenfalls mit 64kb-Blöcken formatiert sind. Für das Betriebssystem ist das leider nicht möglich, deswegen hier eine Partition für Windows abtrennen.

Auf das zweite RAID-System werden die Transaktions-Logs gespeichert (bei der Instanz-Installation kann dies zugewiesen werden).

Auf die einzelne superschnelle SSD werden die tempdb's (eine pro CPU-Core) abgelegt.

Nicht erwähnen brauche ich sicherlich, dass der Server über ordentliche CPUs (Intel Xeon) und ordentlich RAM (DDR4 ECC) verfügen sollte. Mehr Kerne sind hier besser als die CPU-Geschwindigkeit.

MfG

Rene

 

[natZONE]

Hört sich gut an. Die SSD mit der Datenbank ist bereits mit 64kb-Blöcken formatiert, OverProvisioning wurde mit 25 % großzügig bemessen, Arbeitsspeicher im Notebook 32GB RAM. Damit ist die Sache ausgereizt, mehr geht nicht mit dieser Hardware.

RAID-eins-null klingt vernünftig, einen LSI-Controller habe ich hier noch, dazu ein Board mit zwei Xeon-CPUs. ECC-Speicher ist ohnehin Pflicht für alles, was größer ist als 32GB RAM. Der SQL Server 2016 schlägt bereits bei der Erstinstallation die angemessene Anzahl der TempDBs vor pro logischem Core. Die passenden SSDs fehlen mir noch. Offensichtlich reichen für die Logfiles kleinere SSDs aus (vielleicht 128 oder 256GB).

 

[Marc Völker]

Täusch dich mal nicht bei Logfiles, auch mit Ordentlicher konfiguration können die was an festplatten speicher ziehen.

Was Ram und CPU angeht gibt es aber auch eine der Sql Server geschuldeten Maximal anzahl, Bitte nicht vergessen auch die Mssql Standard Edition ist begrenzt.

Bis 2014 auf 16 Cores, und glaub 64/128 GB Ram. Find gerade auf die schnelle nicht das Datenblatt, und mein Rechner im Büro ist aus.

Gerade was die Festplatten angeht, ist vor allem auch die Frage, welcher Controller läuft da drunter. Weil auch ein Billiger Controler kann zum Nadelohr werden, und nein Virtuelle Festplatten, oder partitionen oder sowas sind nicht als eine der Festplatten gemeint. Hier wird schon von Logischen Laufwerken / Raids gesprochen und nicht nur Virtuellen partitionen oder Ähnlichem.

Sprich ist der Server Virtuell (hier gibt es keine echte Meinung was besser für nen DB Server ist, ob virtuell oder Physich) was aber klar ist, bei Virtuell müssen die Platten auch ordentlich der Virtuellen kiste zu verfügung gestellt werden, sprich entweder Komplett durch gereich werden. Oder wenn man Virtuellen Platten gearbeitet wird, diese wirklich ordentlich auf Physichen Platten abgelegt werden. Und was dann auch gerne falsche gemacht wird, Bitte die Festplatten nicht mit Dynamischer Vergrößerung.... Sonst hast du auch eine Klasse Fragmentierung.

P.S. 2016 Ist von JTL noch nicht freigegeben für die Wawi. Aber mir fällt da eh gerade auf, ernst haft ne 2016 Enterprise? Bisher kenne ich nur ein Unternehmen im JTL umfeld (wollen es aber erst einsetzen) wo wirklich eine Enterprise (da dann sogar mehrere Instanzen im Cluster) nötig ist. Wie haste den Lizensiert? Bzw warum? Den kannst du ja eh nur nach Core Lizensieren. Da kannste mit CALS ja nicht mehr arbeiten. Wenn du keine Features wie Clustering, mehr als 16 Core, mehr als 128 GB Ram, und was da sonst noch gibt (was im übrigen auch JTL nicht nutzen wird) verschenkst du da eine Menge geld. Ich meine nur 14.000 $ Pro Core (einzige Preis den ich gerade fand) Mal ernsthaft? Wie Groß seit ihr?

Aber ansonsten würde ich hier defintiv auf Server SSDs, welche über PCIe angebunden werden setzen, SSds mit SATA oder SAS anschluss wirste so defintiv nicht alles raus hollen. Und wenn du wirklich ein System aufbauen willst, wo du alles raus hollst. Dann sollte eigentlich das Geld da sein, für entsprechende Dienstleister, die davon auch Ahnung haben. Hab aber jetzt leider auch auf die kürze nicht gesehen um welche Kennzahlen der zu erwartenen Kunden / Aufträge / Mitarbeiter es hier bei dir geht.