Ein System, das wir entwickeln, besteht aus einem Web-App-Frontend und einem Backend, das viele Datenverarbeitungen mithilfe von gespeicherten Prozeduren in SQL Server 2008 R2 durchführt (bitte fragen Sie nicht, warum ...). Diese gespeicherten Prozeduren verwenden häufig temporäre Tabellen (Erstellung, Einfügungen, Verknüpfungen), sodasstempdbDie E/A-Rate ist beim Schreiben und Lesen hoch. Unsere Kunden brauchen Geschwindigkeit, deshalb empfehlen wir Folgendes:
- Kaufen Sie einen Server mit einem RAID 1-SSD-Array zum Speichern der Hauptdatenbank (vielleicht RAID 10, wenn das Geld vorhanden ist), und verwenden Sie eine weitere Festplatte für das Betriebssystem und die SQL Server-Installation, sodass wichtige Daten mit Replikation auf einem schnellen Laufwerk gespeichert werden, sowie 64 GB RAM.
- Verwenden Sie eine Ramdisk zum Speichern dertempdbDatenbank, daher werden temporäre Tabellen (der größte Leistungsengpass, unserer Meinung nach) im RAM verarbeitet.
Einige Kontextdaten:
- Unsere Datenbank nutzt nicht mehr als 10 GB und hat eine sehr geringe erwartete Wachstumsrate. Tempdb wächst normalerweise auf nicht mehr als 2-3 GB.
- Der Server wird für die Datenbank und den Webserver verwendet.
- Die Ramdisk-Software kann die Ramdisk beim Windows-Start mounten.
Wir haben den Ramdisk-Ansatz auf einem Laptop mit viel RAM getestet. Die Beschleunigung ist zumindest bemerkenswert (Ausführungszeiten gespeicherter Prozeduren auf 1/3 reduziert).
Ich brauche Hilfe, um zu entscheiden, ob dies eine gute Lösung ist oder nicht, und um etwaige (offensichtliche oder weniger offensichtliche) Mängel zu erkennen, die mir möglicherweise entgangen sind.
EDIT: Danke für die bisherigen Antworten! Ich habe vergessen, ausdrücklich zu erwähnen, dass es gleichzeitige Benutzer geben wird, die die Anwendung verwenden, sodass mehrere temporäre Tabellenoperationen ausgeführt werden. Außerdem ist die Kombination von Webserver und DB-Server nicht unsere Wahl, wir wissen bereits, dass dies nicht optimal ist ;)
Antwort1
Es geht nicht nur um die Rate, sondern auch um die Wartezeit. Führen Sie einen gründlichen Benchmark durch. Überprüfen Sie die IOPS und die Länge der Festplattenwarteschlange. Verwenden Sie Perfmon und SQL-Profiling. Nur zu – ich warte.
Sie wissen bereits, dass das Betriebssystem auf einem Satz Spindeln, MDFs auf einem anderen, LDFs auf einem anderen und Tempdb-Dateien auf einem weiteren Satz sein sollten, wenn Sie tatsächlich Leistungsbedenken haben. Wenn Sie das nicht tun können, führen Sie Benchmarks durch und finden Sie Ihre Prioritäten heraus. Außerdem können die unterschiedlichen Lese- und Schreibmuster unterschiedliche RAID-Level für jeden dieser Werte erfordern.
Möglicherweise stellen Sie fest, dass Sie mit Standardfestplatten mit den richtigen RAID-Konfigurationen Ihr Ziel erreichen können und nicht auf Enterprise-SSDs zurückgreifen müssen. Wenn Tempdb jedoch stark genug ausgelastet ist, kann eine einzelne SSD gut geeignet sein. Aus Leistungsgründen ist RAID wahrscheinlich nicht erforderlich, aus Redundanzgründen könnte es jedoch eine gute Idee sein. Hängt natürlich von Ihrem Budget ab und davon, wie lange Sie ausfallen können.
Sie wissen auch, dass der SQL-Server vom Webserver getrennt sein sollte, oder? Wenn die Leistung ein Problem darstellt? Selbst wenn Sie jetzt kein Problem haben, wird es bei einem Wachstum schwierig, herauszufinden, was stärker belastet wird und was die geeignete Lösung ist.
Antwort2
RAID ist fürRedundanz, Leistung geht verloren. Zum Beispiel RAID 5 zum Lesen eines DatenstücksalleDie Komponentendisketten müssen gelesen und die Parität überprüft werden (dasIstlangsamer als das Lesen von einer einzelnen Platte, die Kopfbewegungen werden nicht unbedingt synchronisiert, daher wartet man auf dieam längstendes Sets, nicht nur des Durchschnitts), bedeutet Schreiben alles lesen, Parität berechnen und neue Daten und Parität schreiben, deutlich langsamer als einfach nur schreiben.
Ja, eine gute RAID-Implementierung und ein intelligentes Betriebssystem können dies erheblich abmildern (ein Muss, denn selbst einzelne Festplatten sind im Hinblick auf den RAM furchtbar langsam, daher führt jedes gute Betriebssystem unabhängig von den Festplatten umfangreiches Caching durch).
Ja, ein intelligentes DBMS speichert Daten auch so weit wie möglich im RAM zwischen (unter Einhaltung der gemachten Zusagen hinsichtlich Datenkonsistenz, Fehlerresistenz usw.; bei Bedarf wartet es ausdrücklich, bis die Daten sicher auf der Festplatte gespeichert sind, bevor es fortfährt).
Für jede Datenbank ist eine RAM-Disk pures Gift (Daten, die explizit auf die Festplatte geschrieben wurden und daher sicher sind, sind dies nicht).
Antwort3
Vielen Dank für alle Antworten. Sie waren sehr hilfreich. Nach einigen Nachforschungen stellte ich fest, dass die E/A-Geschwindigkeit in diesem speziellen Fall nicht der Hauptengpass war, obwohl sie im Allgemeinen wichtig ist. Zu den Best Practices bei der Tempdb-Verwaltung gehört es, mindestens 4 Datendateien zu haben. Microsoft empfiehlt außerdem 1 Datendatei für jeden CPU-Kern. Mehr Dateien tragen dazu bei, einige Arten von Konfliktproblemen zu reduzieren.
Einige Links dazu:
Antwort4
so dass die TempDB-E/A-Rate beim Schreiben und Lesen hoch ist
Zu wenig RAM. tempdb führt nur dann E/A aus, wenn es überläuft – andernfalls sichert SQL Server die tempdb-Seiten nicht auf der Festplatte.
Eine RAM-Disk hilft also nicht weiter - bauen Sie lieber mehr Speicher ein.