Bewährte Methoden für die Leistung und Konfigurationsrichtlinien für SQL Server für Linux

Gilt für:SQL Server unter Linux

Dieser Artikel enthält bewährte Methoden und Empfehlungen, um die Leistung für Datenbankanwendungen zu maximieren, die mit SQL Server für Linux verbunden sind. Diese Empfehlungen gelten speziell für die Ausführung auf der Linux-Plattform. Alle normalen SQL Server Empfehlungen wie der Indexentwurf gelten weiterhin.

In den folgenden Richtlinien erhalten Sie Empfehlungen zum Konfigurieren von SQL Server und des Linux-Betriebssystems. Verwenden Sie diese Konfigurationseinstellungen, um bei einer SQL Server-Installation die beste Leistung zu erzielen.

• Empfehlungen für die Speicherkonfiguration
• Kerneleinstellungen und CPU-Einstellungen für hohe Leistung
• SQL Server-Konfiguration

Empfehlungen für die Speicherkonfiguration

Das Speichersubsystem, in dem die Daten, Transaktionsprotokolle und weitere dazugehörige Dateien (z. B. Prüfpunktdateien für In-Memory-OLTP) gehostet sind, sollte in der Lage sein, sowohl durchschnittliche Workloads als auch Spitzenworkloads ordnungsgemäß zu verwalten.

Verwenden des Speichersubsystems mit angemessenen Werten für IOPS, Durchsatz und Redundanz

In lokalen Umgebungen unterstützt der Speicheranbieter normalerweise geeignete Hardware-RAID-Konfiguration mit Striping über mehrere Datenträger hinweg, um geeignete IOPS, Durchsatz und Redundanz sicherzustellen. Diese Unterstützung kann sich jedoch in verschiedenen Speicheranbietern und verschiedenen Speicherangeboten mit unterschiedlichen Architekturen unterscheiden.

Für SQL Server unter Linux, die auf virtuellen Azure-Computern bereitgestellt werden, sollten Sie software RAID verwenden, um geeignete IOPS- und Durchsatzanforderungen sicherzustellen. Wenn Sie SQL Server auf virtuellen Azure-Computern mit ähnlichen Speichererwägungen konfigurieren, lesen Sie bitte Konfigurieren des Speichers für SQL Server auf Azure VMs.

Das folgende Beispiel zeigt, wie Sie Software-RAID in Linux auf einem virtuellen Azure-Computer erstellen. Denken Sie daran, basierend auf den Anforderungen an Daten, Transaktionsprotokolle und tempdb-E/A eine angemessene Anzahl von Datenträgern für die erforderlichen Durchsatz- und IOPS-Werte für Volumes zu verwenden. Im folgenden Beispiel wurden acht Datenträger an die VM angefügt; vier zum Hosten von Datendateien, zwei für Transaktionsprotokolle und zwei für tempdb workload.

Verwenden Sie den Befehl lsblk, um die Geräte (z. B. /dev/sdc) für die RAID-Erstellung zu suchen.

# For Data volume, using 4 devices, in RAID 5 configuration with 8KB stripes
mdadm --create --verbose /dev/md0 --level=raid5 --chunk=8K --raid-devices=4 /dev/sdc /dev/sdd /dev/sde /dev/sdf

# For Log volume, using 2 devices in RAID 10 configuration with 64KB stripes
mdadm --create --verbose /dev/md1 --level=raid10 --chunk=64K --raid-devices=2 /dev/sdg /dev/sdh

# For tempdb volume, using 2 devices in RAID 0 configuration with 64KB stripes
mdadm --create --verbose /dev/md2 --level=raid0 --chunk=64K --raid-devices=2 /dev/sdi /dev/sdj

Empfehlungen zur Partitionierung und Konfiguration von Datenträgern

Verwenden Sie für SQL Server eine RAID-Konfiguration. Die bereitgestellte Dateisystem-Stripeeinheit (sunit) und die Streifenbreite stimmen mit der RAID-Geometrie überein. Das folgende Beispiel zeigt beispielsweise eine XFS-basierte Konfiguration für ein Protokollvolume.

# Creating a log volume, using 6 devices, in RAID 10 configuration with 64KB stripes
mdadm --create --verbose /dev/md3 --level=raid10 --chunk=64K --raid-devices=6 /dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf

mkfs.xfs /dev/md3 -f -L log
meta-data=/dev/md3               isize=512    agcount=32, agsize=18287648 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1
data     =                       bsize=4096   blocks=585204384, imaxpct=5
         =                       sunit=16     swidth=48 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=285744, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Das Log-Array ist ein RAID-10 mit sechs Festplatten und einem 64-KB-Stripe. Offensichtlich gilt also Folgendes:

• Für sunit=16 blks entspricht die Stripegröße 16 × 4.096 (Blockgröße) = 64 KB.
• Für swidth=48 blks entspricht die Anzahl der Datenträger im Array (ohne Paritätsdatenträger) swidth / sunit = 3.

Empfohlene Dateisystemkonfiguration

SQL Server unterstützt sowohl ext4- als auch XFS-Dateisysteme zum Hosten der Datenbank, Transaktionsprotokolle und anderer Dateien wie Prüfpunktdateien für IN-Memory-OLTP in SQL Server. Verwenden Sie das XFS-Dateisystem zum Hosten der SQL Server-Daten- und Transaktionsprotokolldateien.

Formatieren Sie das Volume mit dem XFS-Dateisystem:

mkfs.xfs /dev/md0 -f -L datavolume
mkfs.xfs /dev/md1 -f -L logvolume
mkfs.xfs /dev/md2 -f -L tempdb

Sie können das XFS-Dateisystem so konfigurieren, dass die Groß-/Kleinschreibung beim Erstellen und Formatieren des XFS-Volumes nicht beachtet wird. Diese Konfiguration wird nicht häufig im Linux-Ökosystem verwendet, kann aber aus Kompatibilitätsgründen verwendet werden.

Sie können beispielsweise den folgenden Befehl ausführen: Wird -n version=ci verwendet, um das XFS-Dateisystem so zu konfigurieren, dass die Groß-/Kleinschreibung nicht beachtet wird.

mkfs.xfs /dev/md0 -f -n version=ci -L datavolume

Empfehlungen für das PMEM-Dateisystem

Legen Sie für die Dateisystemkonfiguration auf Geräten für beständigen Arbeitsspeicher die Blockzuordnung für das zugrunde liegende Dateisystem auf 2 MB fest. Weitere Informationen finden Sie in technischen Überlegungen.

Beschränkung für offene Dateien

Ihre Produktionsumgebung erfordert möglicherweise mehr Verbindungen als das Standardlimit von 1.024 geöffneten Dateien. Sie können weiche und harte Grenzwerte auf 1.048.576 festlegen. Bearbeiten Sie beispielsweise in RHEL die /etc/security/limits.d/99-mssql-server.conf Datei so, dass sie die folgenden Werte enthält:

mssql - nofile 1048576

Hinweis

Diese Einstellung gilt nicht für SQL Server-Dienste, die von systemd gestartet werden. Weitere Informationen finden Sie unter How to set limits for services in RHEL and systemd.

Datum und Uhrzeit des letzten Zugriffs in Dateisystemen für SQL Server-Daten und Protokolldateien deaktivieren

Um sicherzustellen, dass die an das System angefügten Laufwerke nach einem Neustart automatisch neu installiert werden, fügen Sie sie der /etc/fstab Datei hinzu. Verwenden Sie die UUID (Universally Unique Identifier) in /etc/fstab, um auf das Laufwerk zu verweisen, anstatt nur auf den Gerätenamen (wie /dev/sdc1).

Verwenden Sie das Attribut noatime mit einem beliebigen Dateisystem, auf dem SQL Server-Daten und -Protokolldateien gespeichert werden. Informationen zum Festlegen dieses Attributs finden Sie in der Linux-Dokumentation. Das folgende Beispiel zeigt, wie Sie die noatime Option für ein Volume aktivieren, das in einer virtuellen Azure-Maschine bereitgestellt wird.

Der Eintrag für den Bereitstellungspunkt in /etc/fstab:

UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" /data1 xfs rw,attr2,noatime 0 0

Im vorherigen Beispiel steht der UUID für das Gerät, das Sie mithilfe des blkid-Befehls finden können.

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 die Ablaufverfolgungszeichen 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 (was der Standard für SQL Server im Linux-Ökosystem ist), 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 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-Element, das 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 die Ablaufverfolgungszeichen 3979 als Startparameter.

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

Kerneleinstellungen und CPU-Einstellungen für hohe Leistung

Im folgenden Abschnitt werden die für das Linux-Betriebssystem empfohlenen Einstellungen erläutert, um bei einer SQL Server-Installation hohe Leistung und einen hohen Durchsatz zu erzielen. Der Prozess zum Konfigurieren dieser Einstellungen wird in der Dokumentation zu Ihrer Linux-Distribution beschrieben. Mithilfe von TuneD können Sie wie beschrieben viele CPUs und Kernelkonfigurationen konfigurieren, die im nächsten Abschnitt beschrieben werden.

Verwenden von TuneD zum Konfigurieren von Kerneleinstellungen

Für Benutzer von Red Hat Enterprise Linux (RHEL) konfiguriert das TuneD-Leistungsprofil automatisch einige Kernel- und CPU-Einstellungen (mit Ausnahme von C-Zuständen). Ab RHEL 8.0 bietet ein TuneD-Profil namens mssql, das in Zusammenarbeit mit Red Hat entwickelt wurde, genauer abgestimmte Linux-Leistungsoptimierungen für SQL Server-Workloads. Dieses Profil enthält das RHEL-Profil für mehr Durchsatz und Leistung. Die Definitionen dieses Profils werden in diesem Artikel veranschaulicht, damit Sie es anderen Linux-Distributionen und RHEL-Releases ohne dieses Profil gegenüberstellen können.

Für SUSE Linux Enterprise Server 12 SP5, Ubuntu 18.04 und Red Hat Enterprise Linux 7.x können Sie das tuned Paket manuell installieren. Verwenden Sie es, um das mssql Profil zu erstellen und zu konfigurieren, wie im folgenden Abschnitt beschrieben.

Empfohlene Linux-Einstellungen für ein optimiertes TuneD-Profil mssql

Im folgenden Beispiel wird eine TuneD-Konfiguration für SQL Server für Linux bereitgestellt.

[main]
summary=Optimize for Microsoft SQL Server
include=throughput-performance

[cpu]
force_latency=5

[sysctl]
vm.swappiness = 1
vm.dirty_background_ratio = 3
vm.dirty_ratio = 80
vm.dirty_expire_centisecs = 500
vm.dirty_writeback_centisecs = 100
vm.transparent_hugepages=always
# For multi-instance SQL deployments, use
# vm.transparent_hugepages=madvise
vm.max_map_count=1600000
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
kernel.numa_balancing=0

Wenn Sie Linux-Distributionen mit Kernelversionen nach 4.18 verwenden, kommentieren Sie die folgenden Optionen wie angezeigt aus. Heben Sie andernfalls die Auskommentierung der folgenden Optionen auf, wenn Sie Distributionen mit Kernelversionen vor 4.18 verwenden.

# kernel.sched_latency_ns = 60000000
# kernel.sched_migration_cost_ns = 500000
# kernel.sched_min_granularity_ns = 15000000
# kernel.sched_wakeup_granularity_ns = 2000000

Zum Aktivieren dieses TuneD-Profils speichern Sie diese Definitionen in einer tuned.conf-Datei im Ordner /usr/lib/tuned/mssql und aktivieren das Profil mithilfe der folgenden Befehle:

chmod +x /usr/lib/tuned/mssql/tuned.conf
tuned-adm profile mssql

Überprüfen Sie mit dem folgenden Befehl, ob das Profil aktiv ist:

tuned-adm active

Oder:

tuned-adm list

Empfehlung für CPU-Einstellungen

In der folgenden Tabelle finden Sie Empfehlungen für die CPU-Einstellungen:

Einstellung	value	Weitere Informationen
CPU frequency governor (Kontrolle der CPU-Häufigkeit)	Cluster-	Dokumentation zum Befehl cpupower
ENERGY_PERF_BIAS	Cluster-	Dokumentation zum Befehl x86_energy_perf_policy
min_perf_pct	100	Dokumentation zum Status „intel p“
C-States	Nur C1	In der Linux- oder Systemdokumentation erhalten Sie Informationen dazu, wie Sie sicherstellen können, dass die Einstellung „C-States“ (C-Status) auf „C1 only“ (Nur C1) festgelegt ist.

Wenn Sie TuneD wie beschrieben verwenden, konfiguriert sie automatisch die CPU-Frequenzkontrolle, ENERGY_PERF_BIASund min_perf_pct einstellungen. Es verwendet das Durchsatzleistungsprofil als Basis für das mssql Profil. Sie müssen den Parameter C-States manuell entsprechend der Dokumentation konfigurieren, die von Linux oder Ihrem Systemverteiler bereitgestellt wird.

Empfehlungen zu Datenträgereinstellungen

In der folgenden Tabelle finden Sie Empfehlungen für die Datenträgereinstellungen:

Einstellung	value	Weitere Informationen
Datenträger readahead	4096	Dokumentation zum Befehl blockdev
sysctl-Einstellungen	kernel.sched_min_granularity_ns = 15000000 kernel.sched_wakeup_granularity_ns = 2000000 vm.dirty_ratio = 80 vm.dirty_background_ratio = 3 vm.swappiness = 1	Dokumentation zum Befehl sysctl

Beschreibung

• vm.swappiness: Dieser Parameter steuert die relative Gewichtung, die dem Austausch des Laufzeitprozessspeichers im Verhältnis zum Dateisystemcache gegeben wird. Der Standardwert für diesen Parameter ist 60, der den Austausch von Laufzeitprozessspeicherseiten im Vergleich zum Entfernen von Dateisystemcacheseiten mit einem Verhältnis von 60:140 angibt. Das Festlegen des Werts auf 1 gibt eine starke Einstellung an, die Laufzeitprozessspeicher im physischen Speicher auf Kosten des Dateisystemcaches beizubehalten. Da SQL Server den Pufferpool als Daten-Cache verwendet und es dringend vorzieht, den Dateisystem-Cache für eine zuverlässige Wiederherstellung zu umgehen, kann eine aggressive Swappiness-Konfiguration vorteilhaft für hochleistungsfähige und dedizierte SQL Server sein.

  Weitere Informationen finden Sie in der Dokumentation zu /proc/sys/vm/ - #swappiness.

• vm.dirty_* Schreibzugriffe auf SQL Server-Dateien werden nicht zwischengespeichert, um die Anforderungen an Datenintegrität zu erfüllen. Diese Parameter ermöglichen eine effiziente asynchrone Schreibleistung und senken die E/A-Speicherauswirkung von Cacheschreibvorgängen unter Linux, indem ermöglicht wird, dass der Umfang für das Zwischenspeichern eine ausreichende Größe aufweist und Leervorgänge gedrosselt werden.

• kernel.sched_*: Diese Parameterwerte stellen die aktuelle Empfehlung zum Optimieren des CfS-Algorithmus (Completely Fair Scheduling) im Linux-Kernel dar. Sie verbessern den Durchsatz von Netzwerk- und Speicher-E/A-Aufrufen im Hinblick auf prozessübergreifende Vor- und Wiederaufnahme von Threads.

Mithilfe des mssql TuneD-Profils werden die vm.swappiness, vm.dirty_* und kernel.sched_* Einstellungen konfiguriert. Sie müssen die Datenträgereinstellung readahead mithilfe des blockdev Befehls für jedes Gerät manuell konfigurieren.

Einstellung des Kernels für automatisches NUMA-Balancing bei Multinode NUMA-Systemen

Wenn Sie SQL Server auf einem Multinode NUMA-System installieren, ist die folgende kernel.numa_balancing Kerneleinstellung standardmäßig aktiviert. Damit SQL Server auf einem NUMA-System mit maximaler Effizienz arbeiten kann, deaktivieren Sie den automatischen NUMA-Balancing auf einem Multinode-NUMA-System:

sysctl -w kernel.numa_balancing=0

Mithilfe des TuneD-Profils mssql wird die Einstellung kernel.numa_balancing konfiguriert.

Kerneleinstellungen für virtuelle Adressräume

Die Standardeinstellung für vm.max_map_count (65536) ist für eine SQL Server-Installation möglicherweise nicht hoch genug. Ändern Sie aus diesem Grund für eine SQL Server-Bereitstellung den Wert vm.max_map_count mindestens in 262.144, und lesen Sie den Abschnitt Empfohlene Linux-Einstellungen für ein TuneD-Profil mssql, um weitere Informationen zu Optimierungen für diese Kernelparameter zu erhalten. Der Höchstwert für vm.max_map_count ist 2147483647.

sysctl -w vm.max_map_count=1600000

Mithilfe des TuneD-Profils mssql wird die Einstellung vm.max_map_count konfiguriert.

Lassen Sie die Option „Transparent Huge Pages“ aktiviert.

Die meisten Linux-Installationen haben diese Option standardmäßig aktiviert. Lassen Sie diese Konfigurationsoption aktiviert, um eine konsistente Leistung zu erzielen. Wenn in SQL Server-Bereitstellungen jedoch hohe Speicherauslagerungsaktivitäten mit mehreren Instanzen auftreten oder die SQL Server-Ausführung mit anderen speicherintensiven Anwendungen auf dem Server erfolgt, testen Sie die Leistung Ihrer Anwendung, nachdem Sie den folgenden Befehl ausgeführt haben.

echo madvise > /sys/kernel/mm/transparent_hugepage/enabled

Alternativ können Sie das TuneD-Profil mssql um die folgende Zeile ergänzen:

vm.transparent_hugepages=madvise

Und stellen Sie sicher, dass das mssql Profil nach der Änderung aktiv ist:

tuned-adm off
tuned-adm profile mssql

Mithilfe des TuneD-Profils mssql wird die Einstellung transparent_hugepage konfiguriert.

Empfehlungen für Netzwerkeinstellungen

Neben Speicher- und CPU-Empfehlungen haben Sie auch netzwerkspezifische Empfehlungen. Die folgenden Empfehlungen werden zur Orientierung angegeben. Nicht alle Einstellungen in den folgenden Beispielen sind für verschiedene Netzwerkadapter verfügbar. Wenden Sie sich an die jeweiligen Netzwerkkartenanbieter, um weitere Informationen zu den einzelnen Optionen zu erhalten. Testen und konfigurieren Sie diese in Entwicklungsumgebungen, bevor Sie sie in Produktionsumgebungen anwenden. Die folgenden Optionen werden anhand von Beispielen erläutert. Die verwendeten Befehle sind vom Typ und Hersteller des Netzwerkadapters abhängig.

1. Konfigurieren Sie die Netzwerkport-Puffergröße. Im Beispiel heißt eth0die NIC , die eine Intel-basierte NIC ist. Für Intel-basierte Netzwerkkarten wird eine Puffergröße von 4 KB (4.096 Byte) empfohlen. Überprüfen Sie die vorab festgelegten Höchstwerte, und konfigurieren Sie diese anhand des folgenden Beispiels:

   Überprüfen Sie die voreingestellten Höchstwerte mit dem folgenden Befehl. Ersetzen Sie eth0 durch den Namen Ihrer Netzwerkkarte:

   ethtool -g eth0
   

   Legen Sie sowohl die Puffergröße für rx (Empfangen) als auch für tx (Übertragen) auf 4 KB fest:

   ethtool -G eth0 rx 4096 tx 4096
   

   Überprüfen Sie, ob der Wert ordnungsgemäß konfiguriert ist:

   ethtool -g eth0
   

2. Aktivieren von Großrahmen. Stellen Sie sicher, dass alle Netzwerkswitches, Router und alle anderen wichtigen Bestandteile des Netzwerkpaketpfads zwischen den Clients und der SQL Server-Instanz Großrahmen unterstützen, bevor Sie Großrahmen aktivieren. Nur dann kann die Aktivierung von Jumbo-Frames die Leistung verbessern. Nachdem Jumbo-Frames aktiviert wurden, stellen Sie eine Verbindung mit SQL Server her, und ändern Sie die Netzwerkpaketgröße auf 8060 mithilfe von sp_configure, wie im folgenden Beispiel gezeigt:

   # command to set jumbo frame to 9014 for a Intel NIC named eth0 is
   ifconfig eth0 mtu 9014
   # verify the setting using the command:
   ip addr | grep 9014
   

   EXECUTE sp_configure 'network packet size', '8060';
   GO
   
   RECONFIGURE WITH OVERRIDE;
   GO
   

3. Legen Sie standardmäßig den Port für adaptive RX/TX IRQ-Zusammenführung fest, was bedeutet, dass die Unterbrechungsübermittlung angepasst wird, um die Latenz zu verbessern, wenn die Paketrate niedrig ist, und verbessern Sie den Durchsatz, wenn die Paketrate hoch ist. Diese Einstellung ist möglicherweise nicht in Ihrer Netzwerkinfrastruktur verfügbar. Überprüfen Sie daher die vorhandene Netzwerkinfrastruktur, und vergewissern Sie sich, dass diese Einstellung unterstützt wird. Das Beispiel ist für die NIC mit dem Namen eth0, die eine Intel-basierte Netzwerkkarte ist:

   1. Legen Sie den Port für die adaptive RX/TX-IRQ-Zusammenführung fest:

      ethtool -C eth0 adaptive-rx on
      ethtool -C eth0 adaptive-tx on
      

   2. Bestätigen Sie die Einstellung:

      ethtool -c eth0
      

   Hinweis

   Deaktivieren Sie für vorhersehbares Verhalten in Hochleistungsumgebungen, z. B. in Umgebungen zum Benchmarking, die adaptive RX/TX-IRQ-Koaleszenz, und stellen Sie dann gezielt die RX/TX-Unterbrechungskoaleszenz ein. Die folgenden Beispielbefehle deaktivieren die RX/TX-IRQ-Zusammenführung und legen dann die speziellen Werte fest:

   Deaktivieren Sie die adaptive RX/TX-IRQ-Zusammenführung:

   ethtool -C eth0 adaptive-rx off
   ethtool -C eth0 adaptive-tx off
   

   Bestätigen Sie die Änderung:

   ethtool -c eth0
   

   Legen Sie die Parameter rx-usecs und irq fest. rx-usecs gibt an, wie viele Mikrosekunden nach dem Empfang von mindestens einem Paket vergehen, bevor ein Interrupt generiert wird. Der Parameter irq gibt die entsprechenden Verzögerungen beim Aktualisieren des Status an, wenn der Interrupt deaktiviert ist. Für auf Intel basierende Netzwerkkarten können Sie die folgenden Einstellungen verwenden:

   ethtool -C eth0 rx-usecs 100 tx-frames-irq 512
   

   Bestätigen Sie die Änderung:

   ethtool -c eth0
   

4. Aktivieren Sie die empfangsseitige Skalierung (RSS) und kombinieren Sie standardmäßig die RX- und TX-Seite von RSS-Warteschlangen. Bei der Arbeit mit dem Microsoft-Support gibt es bestimmte Szenarien, in denen das Deaktivieren von RSS auch die Leistung verbessert. Testen Sie diese Einstellung in Testumgebungen, bevor Sie sie in Produktionsumgebungen anwenden. Das folgende Beispiel gilt für Intel-Netzwerkadapter.

   Rufen Sie die vorab festgelegten Höchstwerte ab:

   ethtool -l eth0
   

   Kombinieren Sie die Warteschlangen mit dem Wert, der im vorab festgelegten Höchstwert „Combined“ (Kombiniert) gemeldet wird. In diesem Beispiel ist der Wert auf 8 festgelegt:

   ethtool -L eth0 combined 8
   

   Überprüfen Sie die Einstellung:

   ethtool -l eth0
   

5. Verwenden Sie die IRQ-Affinität des NIC-Ports. Um die erwartete Leistung durch Optimierung der IRQ-Affinität zu erzielen, sollten Sie einige wichtige Parameter berücksichtigen, wie die Linux-bezogene Behandlung der Servertopologie, den NIC-Treiber-Stack, die Standardeinstellungen und die irqbalance Einstellung. Optimierung der Einstellungen für die IRQ-Affinität des NIC-Ports erfolgt unter Berücksichtigung der Servertopologie, durch Deaktivierung des irqbalance und Verwendung von NIC-herstellerspezifischen Einstellungen.

   Die Konfiguration wird anhand des folgenden Beispiel für die spezifische Netzwerkinfrastruktur von Mellanox erläutert. Unter Leistungsoptimierungstools für Mellanox-Netzwerkadapter finden Sie weitere Informationen und können auch das Mellanox-Tool mlnx herunterladen. Die Befehle weichen je nach Umgebung ab. Wenden Sie sich an den jeweiligen NIC-Anbieter, um weitere Informationen zu erhalten.

   Deaktivieren Sie irqbalance, oder rufen Sie eine Momentaufnahme der IRQ-Einstellungen ab, und erzwingen Sie das Beenden des Daemons:

   systemctl disable irqbalance.service
   

   Oder:

   irqbalance --oneshot
   

   Stellen Sie sicher, dass die common_irq_affinity.sh ausführbar ist:

   chmod +x common_irq_affinity.sh
   

   Zeigen Sie die IRQ-Affinität für den Mellanox-NIC-Port (z. B. eth0) an:

   ./show_irq_affinity.sh eth0
   

   Optimieren Sie die optimale Durchsatzleistung mit einem Mellanox-Tool:

   ./mlnx_tune -p HIGH_THROUGHPUT
   

   Legen Sie die Hardwareaffinität auf den NUMA-Knoten fest, der die Netzwerkkarte und ihren Port physisch hostet:

   ./set_irq_affinity_bynode.sh `\cat /sys/class/net/eth0/device/numa_node` eth0
   

   Überprüfen Sie die IRQ-Affinität:

   ./show_irq_affinity.sh eth0
   

   Hinzufügen von Optimierungen der IRQ-Zusammenführung

   ethtool -C eth0 adaptive-rx off
   ethtool -C eth0 adaptive-tx off
   ethtool -C eth0  rx-usecs 750 tx-frames-irq 2048
   

   Überprüfen Sie die Einstellungen:

   ethtool -c eth0
   

6. Nachdem Sie die vorherigen Änderungen vorgenommen haben, überprüfen Sie die Geschwindigkeit der NIC, um sicherzustellen, dass sie Ihren Erwartungen entspricht, indem Sie den folgenden Befehl verwenden:

   ethtool eth0 | grep -i Speed
   

Erweiterte Kernel- und Betriebssystemkonfiguration

• Verwenden Sie für die optimale Speicher-E/A-Leistung die Mehrfachwarteschlange-Planung von Linux für Blockgeräte. Diese Planungsmethode ermöglicht es der Blockschichtleistung, gut auf schnelle Festkörperlaufwerke (Solid State Drives, SSDs) und Multicore-Systeme zu skalieren. Überprüfen Sie die Dokumentation, um festzustellen, ob Ihre Linux-Verteilung sie standardmäßig aktiviert. In den meisten anderen Fällen können Sie den Kernel scsi_mod.use_blk_mq=y starten, um ihn zu aktivieren. Die Dokumentation für Ihre Linux-Verteilung enthält möglicherweise weitere Anleitungen zu dieser Einstellung. Diese Einstellung entspricht dem upstream-Linux-Kernel.

• Da Multipath-E/A häufig für SQL Server-Bereitstellungen verwendet wird, konfigurieren Sie das Multiqueue-Ziel (Device Mapper, DM) für die Verwendung der blk-mq Infrastruktur, indem Sie die dm_mod.use_blk_mq=y Kernelstartoption aktivieren. Der Standardwert lautet n (Deaktiviert). Diese Einstellung reduziert den Sperraufwand auf der DM-Ebene, wenn die zugrunde liegenden SCSI-Geräte blk-mq verwenden. Weitere Informationen zum Konfigurieren von E/A mit mehreren Pfaden finden Sie in der Dokumentation zu Ihrer Linux-Distribution.

Konfigurieren der Auslagerungsdatei

Stellen Sie sicher, dass Sie über eine ordnungsgemäß konfigurierte Auslagerungsdatei verfügen, damit keine Probleme mit dem Arbeitsspeicher auftreten. In der Linux-Dokumentation erhalten Sie Informationen über die Erstellung und ordnungsgemäße Größenanpassung von Auslagerungsdateien.

VMs und dynamischer Arbeitsspeicher

Wenn Sie SQL Server für Linux auf einer VM ausführen, stellen Sie sicher, dass Sie entsprechende Optionen auswählen, um dem für die VM reservierten Arbeitsspeicher gerecht zu werden. Verwenden Sie keine Features wie Hyper-V Dynamic Memory.

SQL Server-Konfiguration

Führen Sie die folgenden Konfigurationsaufgaben aus, nachdem Sie SQL Server unter Linux installiert haben, um die beste Leistung für Ihre Anwendung zu erzielen.

Bewährte Methoden

Verwenden von PROCESS AFFINITY für Knoten und/oder CPUs

Verwenden Sie ALTER SERVER CONFIGURATION, um PROCESS AFFINITY für alle NUMANODEs und CPUs festzulegen, die Sie für SQL Server (was normalerweise alle NODEs und CPUs umfasst) auf einem Linux-Betriebssystem verwenden. Die Prozessoraffinität hilft dabei, das Verhalten von Linux und SQL effizient zu planen. Die Verwendung der Option NUMANODE ist die einfachste Methode. Beachten Sie, dass Sie PROCESS AFFINITY auch dann verwenden sollten, wenn auf Ihrem Computer nur ein einzelner NUMA-Knoten vorhanden ist. Weitere Informationen zum Festlegen von PROCESS AFFINITY finden Sie im Artikel ALTER SERVER CONFIGURATION.

Konfigurieren mehrerer tempdb-Datendateien

Da die Installation von SQL Server für Linux keine Option zum Konfigurieren mehrerer tempdb-Dateien bietet, empfiehlt es sich, die tempdb-Datendateien erst nach der Installation zu erstellen. Weitere Informationen finden Sie im Artikel Empfehlungen zum Reduzieren von Konflikten bei der Zuweisung in tempdb-Datenbank für SQL Server.

Erweiterte Konfiguration

Die folgenden Empfehlungen stellen optionale Konfigurationseinstellungen dar, die Sie nach der Installation von SQL Server für Linux durchführen können. Diese Optionen basieren auf den Anforderungen Ihrer Workload und der Konfiguration Ihres Linux-Betriebssystems.

Festlegen eines Arbeitsspeicherlimits mithilfe von mssql-conf

Um sicherzustellen, dass genügend freier physischer Arbeitsspeicher für das Linux-Betriebssystem vorhanden ist, verwendet der SQL Server-Prozess standardmäßig nur 80% des physischen RAM. Bei einigen Systemen mit großen Mengen physischem RAM kann 20% eine erhebliche Zahl sein.

Bei einem System mit 1 TB RAM werden durch diese Standardeinstellung ca. 200 GB RAM freigelassen. In diesem Fall sollten Sie das Arbeitsspeicherlimit auf einen höheren Wert festlegen. Sie können diesen Wert mit dem Mssql-conf-Tool anpassen. Weitere Informationen finden Sie in der Einstellung "memory.memorylimitmb ", die den für SQL Server sichtbaren Speicher steuert (in Einheiten von MB).

Hinweis

Sie können auch eine Speichergrenze mithilfe der MSSQL_MEMORY_LIMIT_MB Umgebungsvariable konfigurieren. Diese Methode wird häufig beim Bereitstellen von Containern oder beim Automatisieren von SQL Server-Containern oder paketbasierten Bereitstellungen verwendet. Die MSSQL_MEMORY_LIMIT_MB Umgebungsvariable hat Vorrang vor der memory.memorylimitmb Einstellung.

Wenn Sie diese Einstellung ändern, achten Sie darauf, diesen Wert nicht zu hoch festzulegen. Wenn nicht genügend Arbeitsspeicher frei ist, können Probleme mit dem Linux-Betriebssystem und anderen Linux-Anwendungen auftreten.

Konfigurieren von Speicherlimits mit cgroup v2

Ab SQL Server 2025 (17.x) und SQL Server 2022 (16.x) CU 20 erkennt und berücksichtigt SQL Server die Einschränkungen der Kontrollgruppe (cgroup) v2, was die Leistungsstabilität und Ressourcenisolation in Docker-, Kubernetes- und OpenShift-Umgebungen verbessert. Steuerungsgruppen ermöglichen eine differenzierte Steuerung im Linux-Kernel über Systemressourcen wie CPU und Arbeitsspeicher.

Mit cgroup v2-Unterstützung entschärft SQL Server Fehler außerhalb des Arbeitsspeichers (OOM), die zuvor in containerisierten Bereitstellungen beobachtet wurden, insbesondere auf Kubernetes-Clustern (z. B. AKS v1.25+), bei denen in Containerspezifikationen definierte Speichergrenzwerte nicht erzwungen wurden.

Cgroup-Version überprüfen

stat -fc %T /sys/fs/cgroup

Die Ergebnisse sind wie folgt:

Ergebnis	Beschreibung
cgroup2fs	Sie verwenden die cgroup v2
cgroup	Sie verwenden die cgroup v1

Wechseln zu cgroup v2

Der einfachste Weg ist die Auswahl einer Distribution, die cgroup v2 von Haus aus unterstützt.

Wenn Sie manuell wechseln müssen, fügen Sie der GRUB-Konfiguration die folgende Zeile hinzu:

systemd.unified_cgroup_hierarchy=1

Führen Sie dann den folgenden Befehl aus, um GRUB zu aktualisieren:

sudo update-grub

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Schnellstart: Bereitstellen eines SQL Server Linux-Containers in Kubernetes mithilfe von Helmdiagrammen
• Linux Kernel cgroup v2-Dokumentation
• Steuerelementgruppe v2

Richtlinien zum Festlegen von Speichergrenzwerten

Beachten Sie beim Festlegen von Speichergrenzwerten für SQL Server unter Linux die folgenden Richtlinien:

• Verwenden Sie cgroup, um den für den Container verfügbaren Gesamtspeicher zu begrenzen. Diese Einstellung richtet die obere Grenze für alle Prozesse innerhalb des Containers ein.

• Die Speichergrenze (ob festgelegt durch memorylimitmb oder die MSSQL_MEMORY_LIMIT_MB Umgebungsvariable) steuert den Gesamtspeicher, den SQL Server unter Linux über alle komponenten hinweg zuordnen kann, z. B. pufferpool, SQLPAL, SQL Server Agent, LibOS, PolyBase, Full-Text Search und alle anderen prozesse, die in SQL Server unter Linux geladen wurden.

• Die MSSQL_MEMORY_LIMIT_MB Umgebungsvariable hat Vorrang vor memorylimitmb der Definition in mssql.conf.

• memorylimitmb kann den tatsächlichen physischen Speicher des Hostsystems nicht überschreiten.

• Legen Sie memorylimitmb niedriger als der Hostsystemspeicher und die cgroup-Grenze (sofern vorhanden) fest, um sicherzustellen, dass genügend freier physischer Arbeitsspeicher für das Linux-Betriebssystem vorhanden ist. Wenn Sie memorylimitmb nicht explizit festlegen, verwendet SQL Server 80 % des niedrigeren Wertes zwischen dem gesamten Systemspeicher und der cgroup-Grenze (sofern vorhanden).

• Die max_server_memory Serverkonfigurationsoption beschränkt nur die Größe des SQL Server-Pufferpools und steuert nicht die allgemeine Speicherauslastung für SQL Server unter Linux. Legen Sie diesen Wert immer niedriger als memorylimitmb fest, um sicherzustellen, dass genügend Arbeitsspeicher für andere Komponenten wie SQLPAL, SQL Server-Agent, LibOS, PolyBase, Full-Text Search und alle anderen in SQL Server unter Linux geladenen Prozesse verbleibt.

Zugehöriger Inhalt

• Exemplarische Vorgehensweise für die Leistungsfeatures von SQL Server für Linux
• Was ist SQL Server für Linux?