Überlegungen zur Hardware für In-Memory-OLTP in SQL Server
In-Memory-OLTP verwendet Arbeitsspeicher und Datenträger anders als herkömmliche datenträgerbasierte Tabellen. Die Leistungsverbesserung, die Sie mit IN-Memory OLTP sehen, hängt von der verwendeten Hardware ab. In diesem Artikel werden verschiedene allgemeine Hardwareüberlegungen behandelt und allgemeine Richtlinien für die Verwendung von Hardware mit In-Memory OLTP bereitgestellt.
Hinweis
Dieser Artikel war ein Blog, der am 1. August 2013 vom Microsoft SQL Server 2014-Team veröffentlicht wurde. Die Webseite des Blogs wird außer Betrieb gesetzt.
CPU
In-Memory OLTP erfordert keinen High-End-Server, um eine OLTP-Workload mit hohem Durchsatz zu unterstützen. Es wird empfohlen, einen Mid-Range-Server mit zwei CPU-Sockets zu verwenden. Aufgrund des erhöhten Durchsatzes, der von In-Memory OLTP aktiviert wird, sind zwei Sockets wahrscheinlich für Ihre geschäftlichen Anforderungen ausreichend.
Wir empfehlen, gleichzeitiges Multithreading (SMT) mit IN-Memory OLTP zu aktivieren. Bei einigen OLTP-Workloads haben wir bei der Verwendung von SMT Leistungssteigerungen von bis zu 40 % gesehen.
Arbeitsspeicher
Alle speicheroptimierten Tabellen befinden sich vollständig im Arbeitsspeicher. Daher müssen Sie genügend physischen Arbeitsspeicher für die Tabellen selbst haben und die Arbeitsauslastung für die Datenbank beibehalten – wie viel Arbeitsspeicher Sie tatsächlich benötigen, hängt von der Arbeitsauslastung ab, aber als Ausgangspunkt benötigen Sie genügend verfügbaren Arbeitsspeicher für etwa doppelt die Datengröße. Außerdem benötigen Sie genügend Arbeitsspeicher für den Pufferpool, falls die Workload auch auf herkömmlichen datenträgerbasierten Tabellen ausgeführt wird.
Um festzustellen, wie viel Arbeitsspeicher eine bestimmte speicheroptimierte Tabelle belegt, führen Sie die folgende Abfrage aus:
select object_name(object_id), * from sys.dm_db_xtp_table_memory_stats;
Die Ergebnisse zeigen den Speicher, der für speicheroptimierte Tabellen und deren Indizes verwendet wird. Die Tabellendaten enthalten die Benutzerdaten und alle älteren Zeilenversionen, die noch zum Ausführen von Transaktionen erforderlich sind oder noch nicht vom System sauber wurden. Der von Hashindizes verwendete Speicher ist konstant und hängt nicht von der Anzahl der Zeilen in der Tabelle ab.
Es ist wichtig zu berücksichtigen, wenn Sie IN-Memory OLTP verwenden, dass Ihre gesamte Datenbank nicht in den Arbeitsspeicher passen muss. Sie können über eine Multi-Terabyte-Datenbank verfügen und trotzdem von In-Memory OLTP profitieren, solange die Größe Ihrer Hot Data (d. h. die speicheroptimierten Tabellen) 256 GB nicht überschreitet. Die maximale Anzahl von Prüfpunktdatendateien, die SQL Server für eine einzelne Datenbank verwalten kann, beträgt 4.000, wobei jede Datei 128 MB beträgt. Obwohl dies ein theoretisches Maximum von 512 GB geben würde, um sicherzustellen, dass SQL Server mit dem Zusammenführen von Prüfpunktdateien schritt halten kann und nicht die Grenze von 4.000 Dateien erreicht, unterstützen wir bis zu 256 GB. Dieser Grenzwert gilt nur für die speicheroptimierten Tabellen; Es gibt keine solche Größenbeschränkung für die herkömmlichen datenträgerbasierten Tabellen in derselben SQL Server-Datenbank.
Nicht dauerhafte speicheroptimierte Tabellen (NDTs), d. h. speicheroptimierte Tabellen mit DURABLEY=SCHEMA_ONLY werden nicht auf dem Datenträger beibehalten. Obwohl NDTs nicht durch die Anzahl der Prüfpunktdateien beschränkt sind, wird nur 256 GB unterstützt. Die Überlegungen für Protokoll- und Datenlaufwerke im re Standard der dieses Beitrags gelten nicht für nicht dauerhafte Tabellen, da die Daten nur im Arbeitsspeicher vorhanden sind.
Protokolllaufwerk
Protokolldatensätze zu speicheroptimierten Tabellen werden zusammen mit den anderen SQL Server-Protokolldatensätzen in das Transaktionsprotokoll der Datenbank geschrieben.
Es ist immer wichtig, die Protokolldatei auf einem Laufwerk mit geringer Latenz zu platzieren, sodass Transaktionen nicht zu lang warten müssen und die Konflikte bei der Protokoll-E/A verhindern. Ihr System läuft so schnell wie Ihre langsamste Komponente (Amdahls Gesetz). Sie müssen sicherstellen, dass ihr Protokoll-E/A-Gerät beim Ausführen von IN-Memory OLTP nicht zu einem Engpass wird. Wir empfehlen die Verwendung eines Speichergeräts mit niedriger Wartezeit, mindestens SSD.
Speicheroptimierte Tabellen verwenden weniger Protokollbandbreite als datenträgerbasierte Tabellen, da sie keine Indexvorgänge protokollieren und keine UNDO-Datensätze protokollieren. Dies kann dazu beitragen, die Protokoll-E/A-Verdichtung zu entlasten.
Datenlaufwerk
Persistenz von speicheroptimierten Tabellen mithilfe von Prüfpunktdateien verwendet Streaming-E/A. Daher benötigen diese Dateien kein Laufwerk mit geringer Latenz oder schneller zufälliger E/A. Stattdessen ist der Standard Faktor für diese Laufwerke die Geschwindigkeit der sequenziellen E/A und bandbreite des Hostbusadapters (HBA). Daher benötigen Sie keine SSDs für Prüfpunktdateien. Sie können sie auf Hochleistungsspindeln (z. B. SAS) platzieren, solange ihre sequenzielle E/A-Geschwindigkeit Ihren Anforderungen entspricht.
Der größte Faktor beim Bestimmen der Geschwindigkeitsanforderung ist Ihr RTO (Recovery Time Objective) beim Serverneustart. Während der Wiederherstellung der Datenbank müssen alle Daten in den speicheroptimierten Tabellen vom Datenträger in den Arbeitsspeicher gelesen werden. Die Datenbankwiederherstellung erfolgt mit der sequenziellen Lesegeschwindigkeit Ihres E/A-Subsystems; Datenträger ist der Engpass.
Um strenge RTO-Anforderungen zu erfüllen, empfehlen wir, die Prüfpunktdateien über mehrere Datenträger zu verteilen, indem sie der MEMORY_OPTIMIZED_DATA Dateigruppe mehrere Container hinzufügen. SQL Server unterstützt das parallele Laden von Prüfpunktdateien von mehreren Laufwerken. Die Wiederherstellung erfolgt mit der aggregierten Geschwindigkeit der Laufwerke.
Hinsichtlich der Datenträgerkapazität empfehlen wir, 2 - 3 Mal die Größe der speicheroptimierten Tabellen verfügbar zu haben.