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

Gilt für: SQL Server – 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

Normalerweise unterstützen Speicheranbieter in lokalen Umgebungen angemessene RAID-Konfigurationen für Hardware mit Striping für mehrere Datenträger, um für angemessene Werte für IOPS, Durchsatz und Redundanz zu sorgen. Dies kann für verschiedene Speicheranbieter und verschiedene Speicherangebote mit unterschiedlichen Architekturen jedoch variieren.

Für auf Azure-VMs bereitgestellte SQL Server für Linux-Instanzen sollten Sie die Verwendung von Software-RAID in Erwägung ziehen, um sicherzustellen, dass die entsprechenden Anforderungen an IOPS und Durchsatz erfüllt werden. Informationen zum Konfigurieren von SQL Server auf Azure-VMs mit ähnlichen Speicherbedingungen finden Sie unter Speicherkonfiguration für SQL Server-VMs.

Das folgende Beispiel zeigt die Erstellung von Software-RAID auf Azure-VMs unter Linux. Denken Sie daran, basierend auf den Anforderungen an Daten, Transaktionsprotokollen 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 Azure-VM angefügt: vier zum Hosten der Datendateien, zwei für die Transaktionsprotokolle und zwei für die 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

Für SQL Server sollten Sie eine RAID-Konfiguration verwenden. Die bereitgestellte Stripe-Dateisystemeinheit (sunit) und die Stripe-Breite müssen der RAID-Geometrie entsprechen. Dies ist beispielsweise ein XFS-basiertes Beispiel 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 Protokollarray ist eine RAID-10-Instanz mit 6 Datenträgern und Bereichsstreifen mit einer Größe von 64 KB. Offensichtlich gilt also Folgendes:

• Für sunit=16 blks entspricht die Bereichsstreifengröß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.

Empfehlungen für die Dateisystemkonfiguration

SQL Server unterstützt sowohl ext4- als auch XFS-Dateisysteme als Host für die Datenbank, Transaktionsprotokolle und weitere Dateien wie Prüfpunktdateien für In-Memory-OLTP in SQL Server. Microsoft empfiehlt die Verwendung des XFS-Dateisystems für das 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

Es ist möglich, das XFS-Dateisystem so zu konfigurieren, dass Groß-/Kleinbuchstaben keine Rolle spielen, wenn das XFS-Volume erstellt und formatiert wird. Dabei handelt es sich um keine häufig genutzte Konfiguration im Linux-Ökosystem. Aus Kompatibilitätsgründen ist die Verwendung jedoch möglich.

Sie können beispielsweise den folgenden Befehl ausführen: -n version=ci wird verwendet, um das XFS-Dateisystem so zu konfigurieren, dass Groß-/Kleinbuchstaben keine Rolle spielen.

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

Empfehlungen für das PMEM-Dateisystem

Für die Konfiguration des Dateisystems für PMEM-Geräte sollte die Blockzuordnung für das zugrunde liegende Dateisystem 2 MB betragen. Weitere Informationen zu diesem Artikel finden Sie unter Technische Überlegungen.

Dateieinschränkung öffnen

Ihre Produktionsumgebung erfordert möglicherweise mehr Verbindungen als das Standardlimit von 1.024 geöffneten Dateien. Sie können weiche und feste Grenzwerte von 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

Deaktivieren von Datum/Uhrzeit des letzten Zugriffs auf Dateisysteme für SQL Server-Daten- und -Protokolldateien

An das System angefügte Laufwerke müssen der Datei /etc/fstab hinzugefügt werden, um sicherzustellen, dass sie nach einem Neustart automatisch wieder eingebunden werden. Außerdem sollten Sie den UUID (Universally Unique Identifier) in /etc/fstab verwenden, um auf das Laufwerk und nicht nur auf den Gerätenamen zu verweisen (z. B. /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. Im nachstehenden Beispiel wird gezeigt, wie die Option noatime für ein in eine Azure-VM eingebundenes Volume aktiviert 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

• 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.

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 Red Hat Enterprise Linux-Benutzer*innen (RHEL) konfiguriert das TuneD-Profil für Durchsatz und Leistung einige Kernel- und CPU-Einstellungen automatisch (mit Ausnahme von C-Status). 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 kann das tuned-Paket manuell installiert werden. Es kann verwendet werden, um das mssql-Profil, wie im folgenden Abschnitt beschrieben, zu erstellen und zu konfigurieren.

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 ab 4.18 verwenden, kommentieren Sie die folgenden Optionen wie angezeigt; 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:

Wenn TuneD wie zuvor beschrieben verwendet wird, werden die Einstellungen für die CPU-Frequenzsteuerung sowie ENERGY_PERF_BIAS und min_perf_pct automatisch entsprechend konfiguriert. Dies liegt daran, dass das Profil für Durchsatz und Leistung als Basis für das mssql-Profil verwendet wird. C-Statusparameter müssen manuell entsprechend der von Linux oder dem Systemvertriebspartner bereitgestellten Dokumentation konfiguriert werden.

Empfehlungen zu Datenträgereinstellungen

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

BESCHREIBUNG

• vm.swappiness Dieser Parameter steuert die relative Gewichtung des Wechsels des Runtimeprozessarbeitsspeichers im Vergleich zum Dateisystemcache. Der Standardwert für diesen Parameter ist „60“, was angibt, dass das Auswechseln der Runtimeprozess-Arbeitsspeicherseiten im Verhältnis von 60:140 zum Entfernen der Dateisystemcache-Seiten steht. Das Festlegen des Werts „1“ stellt eine starke Präferenz zum Beibehalten des Runtimeprozessarbeitsspeichers im physischen Speicher auf Kosten des Dateisystemcaches dar. Da SQL Server den Pufferpool als Datenseitencache verwendet und es stark bevorzugt, für eine zuverlässige Wiederherstellung durch einen Hardware umgehenden Dateisystemcache zu schreiben, kann sich eine aggressive Swappiness-Konfiguration für leistungsstarke und dedizierte SQL Server-Instanzen als vorteilhaft erweisen. 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 sind die aktuelle Empfehlung für das Anpassen des Completely Fair Scheduling(CFS)-Algorithmus im Linux-Kernel, um den Durchsatz des Netzwerks und E/A-Speicheraufrufe zu optimieren. Dabei wird die vorzeitige Entfernung während Prozessen und die Wiederaufnahme von Threads berücksichtigt.

Mithilfe des TuneD-Profils mssql werden die Einstellungen vm.swappiness, vm.dirty_* und kernel.sched_* konfiguriert. Die readahead-Datenträgerkonfiguration mithilfe des blockdev-Befehls erfolgt pro Gerät und muss manuell ausgeführt werden.

Kernel-Einstellung für den automatischen NUMA-Ausgleich für NUMA-Systeme mit mehreren Knoten

Wenn Sie SQL Server auf einem NUMA-System mit mehreren Knoten installieren, ist die Kerneleinstellung kernel.numa_balancing standardmäßig aktiviert. Deaktivieren Sie den automatischen NUMA-Ausgleich für das NUMA-System mit mehreren Knoten, damit SQL Server auf diesem mit bestmöglicher Effizienz arbeiten kann:

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.

Bei den meisten Linux-Installationen sollte diese Option standardmäßig aktiviert sein. Es wird empfohlen, dies nicht zu ändern, damit die Leistung konstant gut bleibt. Bei hoher Arbeitsspeicherauslastung in SQL Server-Bereitstellungen mit mehreren Instanzen (z. B. bei SQL Server-Ausführung mit anderen anspruchsvollen Anwendungen auf dem Server) wird jedoch empfohlen, dass Sie die Leistung Ihrer Anwendungen nach Ausführung des folgenden Befehls testen:

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

Aktivieren Sie das Profil mssql außerdem nach der Änderung:

tuned-adm off
tuned-adm profile mssql

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

Empfehlungen für Netzwerkeinstellungen

Ebenso wie es Speicher- und CPU-Empfehlungen gibt, gibt es auch netzwerkspezifische Empfehlungen, die zur Referenz im Folgenden aufgeführt werden. Nicht alle Einstellungen in den folgenden Beispielen sind für verschiedene Netzwerkadapter verfügbar. Wenden Sie sich für weitere Informationen über die einzelnen Optionen an die jeweiligen Netzwerkkartenanbieter. 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 folgenden Beispiel hat die Netzwerkkarte den Namen eth0. Dabei handelt es sich um eine auf Intel basierende Netzwerkkarte. 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 vorab festgelegten 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 Sie 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 Leistung durch die Aktivierung von Großrahmen verbessert werden. Stellen Sie nach Aktivierung von Großrahmen eine Verbindung mit SQL Server her, und ändern Sie die Netzwerkpaketgröße wie unten gezeigt mit sp_configure in „8.060“:

   # 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
   

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

3. Standardmäßig wird empfohlen, den Port für die adaptive RX/TX-IRQ-Zusammenführung festzulegen, was bedeutet, dass die Interruptbereitstellung angepasst wird, um bei niedriger Paketrate die Latenz und bei hoher Paketrate den Durchsatz zu verbessern. Diese Einstellung ist möglicherweise nicht für alle verschiedenen Netzwerkinfrastrukturen verfügbar. Überprüfen Sie also, ob dies von der vorhandenen Netzwerkinfrastruktur unterstützt wird. Das folgende Beispiel handelt von der Netzwerkkarte mit dem Namen eth0, bei der es sich um eine auf Intel basierende Netzwerkkarte handelt:

   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

   Für ein vorhersagbares Verhalten bei Hochleistungsumgebungen (z. B. Umgebungen für Benchmarking) können Sie die adaptive RX/TX-Zusammenführung deaktivieren und dann spezifisch die RX/TX-Interruptzusammenführung festlegen. Die folgenden Beispielbefehle deaktivieren die RX/TX-IRQ-Zusammenführung und legen dann die Werte spezifisch 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 mindestens einem Paket empfangen werden, 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. Außerdem werden die Aktivierung der empfangsseitigen Skalierung (Receive-Side Scaling, RSS) und die Standardkombination der RX- und TX-Seiten von RSS-Warteschlangen empfohlen. Es gab spezifische Szenarien bei der Zusammenarbeit mit dem Microsoft-Support, in denen die Deaktivierung von RSS auch zu Leistungsverbesserungen führte. 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. Arbeiten mit der IRQ-Affinität von NIC-Ports: Damit Sie die gewünschte Leistung durch Optimierung der IRQ-Affinität erreichen können, müssen Sie einige wichtige Parameter wie die Linux-Verarbeitung der Servertopologie, den NIC-Treiberstapel, die Standardeinstellungen und die irqbalance-Einstellung berücksichtigen. Für die Optimierung der Einstellungen der IRQ-Affinität von NIC-Ports ist Wissen über die Servertopologie, die Deaktivierung von „irqbalance“ und die Verwendung von NIC-herstellerspezifischen Einstellungen erforderlich.

   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 für weitere Informationen an den jeweiligen Netzwerkkartenanbieter.

   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
   

   Anzeigen der IRQ-Affinität für den Mellanox-Netzwerkkartenport (z. B. eth0):

   ./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 obigen Änderungen vorgenommen haben, überprüfen Sie mithilfe des folgenden Befehls die Geschwindigkeit der Netzwerkkarte, um sicherzustellen, dass die erwartete Leistung erzielt wird:

   ethtool eth0 | grep -i Speed
   

Erweiterte Kernel- und Betriebssystemkonfiguration

• Um eine optimale Speicher-E/A-Leistung zu erzielen, verwenden Sie die Linux-Multiqueue-Planung für Blockgeräte. Hierdurch kann die Leistung der Blockebene anhand von schnellen Solid State Drives (SSDs) und Systemen mit mehreren Kernen problemlos skaliert werden. In der Dokumentation können Sie herausfinden, ob diese Option für Ihre Linux-Distribution standardmäßig aktiviert ist. In den meisten anderen Fällen wird die Option durch Starten des Kernels mit scsi_mod.use_blk_mq=y aktiviert. Möglicherweise finden Sie in der Dokumentation zur verwendeten Linux-Distribution aber auch weitere Anweisungen dazu. Dies ist mit dem Linux-Upstreamkernel konsistent.

• Da E/A mit mehreren Pfaden oft für SQL Server-Bereitstellungen verwendet wird, konfigurieren Sie das Ziel mit mehreren Warteschlangen für die Gerätezuordnung (Device Mapper, DM), sodass die blk-mq-Infrastruktur verwendet wird. Aktivieren Sie zu diesem Zweck die Kernelstartoption dm_mod.use_blk_mq=y. Der Standardwert lautet n (Deaktiviert). Diese Einstellung senkt 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 nach der Installation von SQL Server für Linux die folgenden Konfigurationsaufgaben aus, um eine optimale 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 jeden NUMANODE und/oder alle CPUs festzulegen, die Sie für SQL Server unter Linux (in der Regel alle Knoten und CPUs) 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 PROCESS AFFINITY .

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

Damit immer genügend physischer Speicherplatz für Linux vorhanden ist, verwendet der SQL Server-Prozess standardmäßig nur 80 Prozent des physischen Speichers. Bei großen Systemen können 20 Prozent einen beachtlichen Unterschied darstellen. 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. Weitere Informationen finden Sie in der Dokumentation zum Tool mssql-config und der Einstellung memory.memorylimitmb, die den für SQL Server sichtbaren Speicherplatz (in MB) steuert.

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.

Zugehöriger Inhalt

• Erste Schritte mit Leistungsfeatures
• Übersicht über SQL Server für Linux