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

  • Artikel

Gilt für:SQL Server – 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, um das PMEM-Gerät zu konfigurieren. Sie finden das Hilfsprogramm hier.
  • 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. Das Speichern von Metadaten im Arbeitsspeicher mithilfe von --map=mem ist zurzeit 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).

Beispielsweise mit XFS

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

Beispielsweise mit EXT4

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

Technische Überlegungen

  • Nehmen Sie Blockzuweisung von 2 MB für XFS- oder EXT4-Systeme vor, 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. Ablaufverfolgungsflag 3979 deaktiviert das Verhalten der erzwungenen Leerung für 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

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

Empfohlene Konfiguration:

  1. Aktivieren Sie das Ablaufverfolgungsflag 3979 als Startparameter.

  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 das Ablaufverfolgungsflag 3982 als Startparameter (dies ist der Standardwert für SQL Server im Linux-Ökosystem), und stellen Sie sicher, dass das Ablaufverfolgungsflag 3979 nicht als Startparameter aktiviert ist.

  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 das XFS-Dateisystem verwenden und sollte FUA unterstützen. 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 Ablaufverfolgungsflag 3979 als Startparameter.

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

Zugehöriger Inhalt