Konfigurieren von persistentem Speicher (PMEM) für SQL Server für Linux

Gilt für:SQL Server unter Linux

In diesem Artikel wird beschrieben, wie PMEM (Persistent Memory, persistenter Arbeitsspeicher) für SQL Server 2019 (15.x) und höher unter Linux konfiguriert wird.

Überblick

In SQL Server 2019 (15.x) wurden zahlreiche In-Memory-Features eingeführt, die PMEM verwenden. Dieser Artikel behandelt die Konfiguration von PMEM für SQL Server für Linux.

Hinweis

Der Begriff Aufklärung wurde eingeführt, um das Konzept eines Dateisystems auszudrücken, das persistenten Speicher unterstützt. Der direkte Zugriff auf das Dateisystem von Anwendungen des Benutzerbereichs aus erfolgt mithilfe einer Speicherzuordnung (mmap()). Wenn eine Speicherzuordnung für eine Datei erstellt wird, kann die Anwendung Lade-/Speicheranweisungen ausgeben und den E/A-Stapel dabei vollständig umgehen. Dies gilt aus der Perspektive der Hosterweiterungsanwendung (dem Code, über den SQLPAL mit Windows- oder Linux-Betriebssystemen interagieren kann) als „aufgeklärte“ Dateizugriffsmethode.

Erstellen von Namespaces für PMEM-Geräte

Konfigurieren der Geräte

Verwenden Sie in Linux das Hilfsprogramm ndctl.

• Installieren Sie ndctl das PMEM-Gerät über die Installation von NDCTL.
• Erstellen Sie einen Namespace mit ndctl. Namespaces sind PMEM-NVDIMM-übergreifend verschachtelt und können unterschiedliche Typen von Benutzerbereichszugriffen auf Speicherbereiche auf dem Gerät bereitstellen. fsdax ist der standardmäßige und der empfohlene Modus für SQL Server.

ndctl create-namespace -f -e namespace0.0 --mode=fsdax --map=dev

Hier wurde der fsdax-Modus ausgewählt, und seitenbezogene Metadaten werden im Systemspeicher gespeichert. Es wird empfohlen, --map=devzu verwenden. Mit dieser Option werden die Metadaten direkt im Namespace gespeichert. Derzeit ist das Speichern von Metadaten im Arbeitsspeicher mit --map=mem experimentell.

Verwenden Sie ndctl, um den Namespace zu überprüfen.

Die Beispielausgabe sieht wie folgt aus:

# ndctl list -N
{
  "dev":"namespace0.0",
  "mode":"fsdax",
  "map":"dev",
  "size":4294967296,
  "sector_size":512,
  "blockdev":"pmem0",
  "numa_node":0
}

Erstellen Sie ein PMEM-Gerät, und binden Sie es ein (mounten Sie es).

Beispiel: mit XFS:

mkfs.xfs -f /dev/pmem0
mount -o dax,noatime /dev/pmem0 /mnt/dax
xfs_io -c "extsize 2m" /mnt/dax

Beispiel: mit ext4:

mkfs.ext4 -b 4096 -E stride=512 -F /dev/pmem0
mount -o dax,noatime /dev/pmem0 /mnt/dax

Technische Überlegungen

• Blockzuordnung von 2 MB für XFS oder Ext4, wie zuvor beschrieben
• Abweichungen zwischen Blockzuweisung und mmap führen zu einem automatischen Fallback auf 4 KB
• Dateigrößen müssen ein Vielfaches von 2 MB sein (Modulo: 2 MB)
• Deaktivieren Sie keine Transparent Huge Pages (THP), standardmäßig in den meisten Distributionen aktiviert.

Wenn das Gerät mit ndctl konfiguriert, erstellt und eingebunden wird, können Sie Datenbankdateien darin ablegen oder eine neue Datenbank erstellen.

Sie können die SQL Server-Datendateien (MDFS, NDFS) und tempdb-Dateien auf einem PMEM-Gerät speichern, wenn Sie den Modus fsdax mithilfe des folgenden Befehls konfigurieren. Verwenden Sie diese Konfiguration nicht zum Speichern des SQL Server-Protokolls (LDFS), da sich das Transaktionsprotokoll in einem Speicher befinden muss, der Unteilbarkeit für den Sektor garantiert:

ndctl create-namespace -f -e namespace0.0 --mode=fsdax --map=dev

Beachten Sie folgende Punkte, bevor Sie die Option „-map“ im vorherigen Befehl festlegen:

• Für optimale Leistung beim Zugriff und bei der Aktualisierung dieser NVDIMM-Seiteneinträge ist die Verwendung von -map=mem vorzuziehen.
• Wenn die Kapazität des NVDIMM zu groß ist (mehr als 512 GB), legen Sie –map=dev fest, was sich auf den E/A-Durchsatz auswirken und die Leistung beeinträchtigen würde.

Bei SQL Server-Protokolldateien auf PMEM-Geräten konfigurieren Sie die PMEM-Geräte für die Verwendung der Sektor-/Blockübersetzungstabelle. Dies bietet die erforderliche Sektorunteilbarkeit für SQL Server-Protokolldateien für diese Technologie von Speichergeräten. Es wird auch empfohlen, Workloadleistungsüberprüfungen durchzuführen. Sie können die SQL Server-Protokollleistung für Ihre Workload zwischen dieser Lösung und branchenführenden NVMe-SSDs vergleichen. Wählen Sie dann die Lösung aus, die Ihren Anforderungen am besten entspricht und eine bessere Leistung bietet.

ndctl create-namespace -f -e namespace0.0 --mode= sector

Deaktivieren des Verhaltens der erzwungenen Leerung

Da PMEM-Geräte im Hinblick auf O_DIRECT (direkte E/A) sicher sind, können Sie das Verhalten der erzwungenen Leerung deaktivieren.

Hinweis

Ein Speichersystem kann sicherstellen, dass alle zwischengespeicherten oder mehrstufigen Schreibvorgänge als sicher und dauerhaft gelten, indem es garantiert, dass die an das Gerät ausgegebenen Schreibvorgänge auf einem hardwareredundanten Medium gespeichert werden, das Systemabstürze, Schnittstellenrücksetzungen und Stromausfälle überdauert.

• Datenbankdateien (.mdf und .ndf) und Transaktionsprotokolldateien (.ldf) verwenden writethrough und alternatewritethrough nicht standardmäßig in SQL Server 2017 (14.x) CU 6 und höher, da sie das Verhalten der erzwungenen Leerung verwenden. Die Trace-Flag 3979 deaktiviert die Verwendung des erzwungenen Flush-Verhaltens für die Datenbank- und Transaktionsprotokolldateien und verwendet die writethrough- und alternatewritethrough-Logik.

• Andere Dateien, die mithilfe von FILE_FLAG_WRITE_THROUGH in SQL Server geöffnet werden, z. B. Datenbankmomentaufnahmen, interne Momentaufnahmen für Datenbankkonsistenzprüfungen (DBCC CHECKDB), Profiler-Ablaufverfolgungsdateien und erweiterte Ereignis-Ablaufverfolgungsdateien, verwenden die Optimierungen writethrough und alternatewritethrough.

Weitere Informationen zu den Änderungen, die in SQL Server 2017 (14.x) CU 6 eingeführt wurden, finden Sie unter KB 4131496. Weitere Informationen zum erzwungenen Zugriff auf Einheiten (Forced Unit Access, FUA) finden Sie unter Informationen zu FUA.

FUA-EA-Subsystemfunktion (Forced Unit Access) in SQL Server

Bestimmte Versionen unterstützter Linux-Distributionen bieten Unterstützung für die FUA-E/A-Subsystemfunktion, um für Dauerhaftigkeit der Daten zu sorgen. SQL Server verwendet die FUA-Funktion, um für hocheffiziente und zuverlässige E/A für SQL Server-Workloads zu sorgen. Weitere Informationen zur Unterstützung für FUA durch Linux-Distributionen und zu den Auswirkungen auf SQL Server finden Sie unter SQL Server On Linux: Forced Unit Access (FUA) Internals (SQL Server für Linux: Informationen zu FUA (Forced Unit Access)).

Ab SUSE Linux Enterprise Server 12 SP5, Red Hat Enterprise Linux 8.0 und Ubuntu 18.04 wird die FUA-Funktion im E/A-Subsystem unterstützt. Wenn Sie SQL Server 2017 (14.x) CU 6 und höher verwenden, sollten Sie die folgende Konfiguration für eine leistungsstarke und effiziente E/A-Implementierung mit FUA von SQL Server verwenden.

Verwenden Sie diese empfohlene Konfiguration, wenn die folgenden Bedingungen erfüllt sind.

• SQL Server 2017 (14.x) CU 6 und höhere Versionen

• Linux-Distribution und -Version, die die FUA-Funktion unterstützt (ab Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 oder Ubuntu 18.04)

• XFS-Dateisystem für SQL Server-Speicher unter Linux Kernel 4.18 oder höher.

• ext4 Dateisystem für SQL Server-Speicher auf Linux-Kernel 5.6 oder späteren Versionen.

  Hinweis

  Sie sollten das XFS-Dateisystem zum Hosten von SQL Server-Daten und Transaktionsprotokolldateien verwenden, wenn die Linux-Kernelversion niedriger als 5.6 ist. Ab kernel Version 5.6 können Sie basierend auf Ihren spezifischen Anforderungen zwischen XFS und Ext4 wählen.

• Speichersubsystem und/oder Hardware, die die FUA-Funktion unterstützt und entsprechend konfiguriert ist

Empfohlene Konfiguration:

1. Aktivieren Sie das Ablaufverfolgungs-Flag 3979 als Start-Up-Parameter.

2. Verwenden Sie mssql-conf zum Konfigurieren von control.writethrough = 1 und control.alternatewritethrough = 0.

Für beinahe alle anderen Konfigurationen, die die vorherigen Bedingungen nicht erfüllen, lautet die empfohlene Konfiguration wie folgt:

1. Aktivieren Sie den Trace Flag 3982 als Startparameter (das ist der Standard für SQL Server im Linux-Ökosystem), und stellen Sie sicher, dass der Trace Flag 3979 nicht als Startparameter aktiviert wird.

2. Verwenden Sie mssql-conf zum Konfigurieren von control.writethrough = 1 und control.alternatewritethrough = 1.

FUA-Unterstützung für SQL Server-Container, die in Kubernetes bereitgestellt werden

1. Der SQL Server muss den persistent bereitgestellten Speicher verwenden und nicht overlayfs.

2. Der Speicher muss die XFS - oder Ext4-Dateisysteme verwenden und FUA unterstützen (ext4 unterstützt FUA nicht auf dem Linux-Kernel vor Version 5.6). Bevor Sie diese Einstellung aktivieren, sollten Sie mit Ihrem Linux-Distributions- und Speicheranbieter zusammenarbeiten, um sicherzustellen, dass das Betriebssystem und das Speichersubsystem FUA-Optionen unterstützt. In Kubernetes können Sie den Dateisystemtyp mithilfe des folgenden Befehls abfragen, wobei <pvc-name> Ihr PersistentVolumeClaim ist:

   kubectl describe pv <pvc-name>
   

   Suchen Sie in der Ausgabe nach dem fstype, der auf XFS festgelegt ist.

3. Der die SQL Server-Pods hostende Workerknoten sollte eine Linux-Distribution und -Version verwenden, die die FUA-Funktion unterstützt (ab Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 oder Ubuntu 18.04).

Wenn die oben genannten Bedingungen erfüllt sind, können Sie die folgenden empfohlenen FUA-Einstellungen verwenden.

1. Aktivieren Sie das Ablaufverfolgungs-Flag 3979 als Start-Up-Parameter.

2. Verwenden Sie mssql-conf zum Konfigurieren von control.writethrough = 1 und control.alternatewritethrough = 0.

Zugehöriger Inhalt

• Was ist SQL Server für Linux?
• Bewährte Methoden für die Leistung und Konfigurationsrichtlinien für SQL Server für Linux