Metodtips för prestanda och konfigurationsriktlinjer för SQL Server i Linux

Artikel
03/05/2025

gäller för:SQL Server – Linux

Den här artikeln innehåller metodtips och rekommendationer för att maximera prestanda för databasprogram som ansluter till SQL Server i Linux. De här rekommendationerna är specifika för körning på Linux-plattformen. Alla vanliga SQL Server-rekommendationer, till exempel indexdesign, gäller fortfarande.

Följande riktlinjer innehåller rekommendationer för att konfigurera både SQL Server och Linux-operativsystemet (OS). Överväg att använda de här konfigurationsinställningarna för att få bästa möjliga prestanda för en SQL Server-installation.

Rekommendation för lagringskonfiguration
Kernel- och CPU-inställningar för högpresterande
SQL Server-konfiguration

Rekommendation för lagringskonfiguration

Lagringsundersystemet som är värd för data, transaktionsloggar och andra associerade filer (till exempel kontrollpunktsfiler för minnesintern OLTP) bör kunna hantera både genomsnittlig och högsta arbetsbelastning korrekt.

Använda lagringsundersystem med lämplig IOPS, dataflöde och redundans

I lokala miljöer stöder lagringsleverantören normalt lämplig RAID-maskinvarukonfiguration med stripning över flera diskar för att säkerställa lämplig IOPS, dataflöde och redundans. Detta kan dock skilja sig åt mellan olika lagringsleverantörer och olika lagringserbjudanden med olika arkitekturer.

För SQL Server på Linux som distribueras på virtuella Azure-datorer bör du överväga att använda programvaru-RAID för att säkerställa att lämpliga krav för IOPS och dataflöde uppnås. När du konfigurerar SQL Server på virtuella Azure-datorer med liknande lagringsöverväganden kan du läsa Konfigurera lagring för SQL Server på virtuella Azure-datorer.

I följande exempel visas hur du skapar raid-programvara i Linux på virtuella Azure-datorer. Tänk på att du bör använda lämpligt antal datadiskar för det dataflöde som krävs och IOPS för volymer baserat på data, transaktionslogg och tempdb I/O-krav. I följande exempel kopplades åtta datadiskar till den virtuella Azure-datorn. 4 som värd för datafiler, 2 för transaktionsloggar och 2 för tempdb arbetsbelastning.

Om du vill hitta enheterna (till exempel /dev/sdc) för att skapa RAID använder du kommandot lsblk.

# 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

Rekommendationer för diskpartitionering och konfiguration

För SQL Server bör du använda en RAID-konfiguration. Den distribuerade filsystemstripenheten (sunit) och stripebredden ska matcha RAID-geometrin. Det här är till exempel ett XFS-baserat exempel för en loggvolym.

# 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

Loggmatrisen är en 6-enhets RAID-10 med en 64 KB-rand. Som du ser:

Storleken för sunit=16 blks, där 16 * 4096 i blockstorlek är lika med 64 KB, stämmer överens med randstorleken.
För swidth=48 blks, swidthoch / sunit = 3, vilket är antalet dataenheter i matrisen, exklusive paritetsenheter.

konfigurationsrekommendering för filsystem

SQL Server stöder både ext4- och XFS-filsystem som värd för databasen, transaktionsloggar och ytterligare filer, till exempel kontrollpunktsfiler för minnesintern OLTP i SQL Server. Microsoft rekommenderar att du använder XFS-filsystemet som värd för SQL Server-data och transaktionsloggfiler.

Formatera volymen med XFS-filsystemet:

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

Det går att konfigurera XFS-filsystemet så att det är skiftlägesokänsligt när du skapar och formaterar XFS-volymen. Det är inte den konfiguration som används ofta i Linux-ekosystemet, men kan användas av kompatibilitetsskäl.

Du kan till exempel köra följande kommando. -n version=ci används för att konfigurera XFS-filsystemet så att det är skiftlägesokänsligt.

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

Rekommendation för beständigt minnefilsystem

För filsystemkonfigurationen på enheter med beständigt minne ska blockallokeringen för det underliggande filsystemet vara 2 MB. Mer information om den här artikeln finns i artikeln Tekniska överväganden.

Begränsning av öppna filer

Produktionsmiljön kan kräva fler anslutningar än standardgränsen för öppna filer på 1 024. Du kan ange mjuka och hårda gränser på 1 048 576. I RHEL-redigerar du till exempel filen /etc/security/limits.d/99-mssql-server.conf så att den har följande värden:

mssql - nofile 1048576

Not

Den här inställningen gäller inte för SQL Server-tjänster som startas av systemd. För mer information, se Hur du anger gränser för tjänster i RHEL och systemd.

Inaktivera senast använda datum/tid på filsystem för SQL Server-data och loggfiler

För att säkerställa att de enheter som är anslutna till systemet återmonterar automatiskt efter en omstart lägger du till dem i /etc/fstab-filen. Du bör också använda UUID (Universally Unique Identifier) i /etc/fstab för att referera till enheten i stället för bara enhetsnamnet (till exempel /dev/sdc1).

Använd attributet noatime med alla filsystem som lagrar SQL Server-data och loggfiler. Se Linux-dokumentationen om hur du anger det här attributet. Ett exempel på hur du aktiverar noatime alternativ för en volym monterad i Azure Virtual Machine följer.

Monteringspunktsposten i /etc/fstab:

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

I föregående exempel representerar UUID den enhet som du kan hitta med hjälp av kommandot blkid.

SQL Server och kapacitet för tvingad enhetsåtkomst (FUA) i I/O-subsystemet

Vissa versioner av Linux-distributioner som stöds har stöd för FUA I/O-undersystem, vilket ger datahållbarhet. SQL Server använder FUA-funktionen för att tillhandahålla mycket effektiv och tillförlitlig I/O för SQL Server-arbetsbelastningar. Mer information om FUA-stöd för Linux-distribution och dess effekt på SQL Server finns i SQL Server On Linux: Forced Unit Access (FUA) Internals.

SUSE Linux Enterprise Server 12 SP5, Red Hat Enterprise Linux 8.0 och Ubuntu 18.04 introducerade stöd för FUA-funktioner i I/O-undersystemet. Om du använder SQL Server 2017 (14.x) CU 6 och senare versioner bör du använda följande konfiguration för högpresterande och effektiv I/O-implementering med FUA av SQL Server.

Använd den här rekommenderade konfigurationen om följande villkor uppfylls.

SQL Server 2017 (14.x) CU 6 och senare versioner
Linux-distribution och -version som stöder FUA-funktioner (från och med Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 eller Ubuntu 18.04)
XFS-filsystem för SQL Server-lagring
Lagringsundersystem och/eller maskinvara som stöder och är konfigurerad för FUA-kapacitet

Rekommenderad konfiguration:

Aktivera Spårningsflagga 3979 som startparameter.
Använd mssql-conf för att konfigurera control.writethrough = 1 och control.alternatewritethrough = 0.

För nästan alla andra konfigurationer som inte uppfyller de tidigare villkoren är den rekommenderade konfigurationen följande:

Aktivera Spårningsflagga 3982 som startparameter (som är standard för SQL Server i Linux-ekosystemet) och kontrollera att Spårningsflagga 3979 inte är aktiverad som en startparameter.
Använd mssql-conf för att konfigurera control.writethrough = 1 och control.alternatewritethrough = 1.

FUA-stöd för SQL Server-containrar som distribueras i Kubernetes

SQL Server måste använda bevarad monterad lagring och inte overlayfs.
Lagringen måste använda XFS-filsystemet och bör ha stöd för FUA. Innan du aktiverar den här inställningen bör du arbeta med din Linux-distributions- och lagringsleverantör för att säkerställa att delsystemet för operativsystem och lagring stöder FUA-alternativ. På Kubernetes kan du fråga efter filsystemtypen med hjälp av följande kommando, där <pvc-name> är din PersistentVolumeClaim:
```
kubectl describe pv <pvc-name>
```
Leta i utdata efter fstype som är inställd på XFS.
Arbetsnoden som är värd för SQL Server-poddarna ska använda en Linux-distribution och -version som stöder FUA-kapacitet (från och med Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 eller Ubuntu 18.04).

Om ovanstående villkor uppfylls kan du använda följande rekommenderade FUA-inställningar.

Aktivera Spårningsflagga 3979 som startparameter.
Använd mssql-conf för att konfigurera control.writethrough = 1 och control.alternatewritethrough = 0.

Kernel- och CPU-inställningar för höga prestanda

I följande avsnitt beskrivs de rekommenderade inställningarna för Linux-operativsystem relaterade till höga prestanda och dataflöde för en SQL Server-installation. Se dokumentationen för Linux-distributionen för processen för att konfigurera de här inställningarna. Du kan använda TuneD- enligt beskrivningen för att konfigurera många processorer och kernelkonfigurationer som beskrivs i nästa avsnitt.

Använd TuneD- för att konfigurera kernelinställningar

För Red Hat Enterprise Linux-användare (RHEL) konfigurerar TuneD- dataflödesprestandaprofil vissa kernel- och CPU-inställningar automatiskt (förutom C-tillstånd). Från och med RHEL 8.0 utvecklades en TuneD-profil med namnet mssql i samarbete med Red Hat och erbjuder finare prestandarelaterade justeringar i Linux för SQL Server-arbetsbelastningar. Den här profilen innehåller RHEL-dataflödesprestandaprofilen och vi presenterar dess definitioner i den här artikeln för din granskning med andra Linux-distributioner och RHEL-versioner utan den här profilen.

För SUSE Linux Enterprise Server 12 SP5, Ubuntu 18.04 och Red Hat Enterprise Linux 7.x kan tuned-paketet installeras manuellt. Den kan användas för att skapa och konfigurera mssql profil enligt beskrivningen i följande avsnitt.

Föreslagna Linux-inställningar med hjälp av en TuneD `mssql`-profil

I följande exempel finns en TuneD-konfiguration för SQL Server i Linux.

[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

Om du använder Linux-distributioner med kernelversioner som är större än 4.18 kommenterar du följande alternativ som visas. Annars avkommenterar du följande alternativ om du använder distributioner med kernelversioner tidigare än 4.18.

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

Om du vill aktivera den här TuneD-profilen sparar du dessa definitioner i en tuned.conf fil under mappen /usr/lib/tuned/mssql och aktiverar profilen med hjälp av följande kommandon:

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

Kontrollera att profilen är aktiv med följande kommando:

tuned-adm active

Eller:

tuned-adm list

Rekommendation för CPU-inställningar

Följande tabell innehåller rekommendationer för CPU-inställningar:

Inställning	Värde	Mer information
Cpu-frekvensregulator	prestanda	Se kommandot cpupower
ENERGY_PERF_BIAS	prestation	Se kommandot x86_energy_perf_policy
min_perf_pct	100	Se din dokumentation om Intel p-state
C-tillstånd	Endast C1	Se din Linux- eller systemdokumentation om hur du ser till att C-States endast är inställt på C1

Om du använder TuneD enligt beskrivningen tidigare konfigureras automatiskt processorfrekvensregulatorn, ENERGY_PERF_BIASoch min_perf_pct inställningar på lämpligt sätt på grund av att dataflödesprestandaprofilen används som bas för mssql profilen. C-States-parametern måste konfigureras manuellt enligt dokumentationen från Linux eller systemdistributören.

Rekommendationer för diskinställningar

Följande tabell innehåller rekommendationer för diskinställningar:

Inställning	Värde	Mer information
Disk `readahead`	4096	Se kommandot `blockdev`
sysctl inställningar	`kernel.sched_min_granularity_ns = 15000000` `kernel.sched_wakeup_granularity_ns = 2000000` `vm.dirty_ratio = 80` `vm.dirty_background_ratio = 3` `vm.swappiness = 1`	Se kommandot sysctl

Beskrivning

vm.swappiness: Den här parametern styr den relativa vikt som ges för att växla ut körningsprocessens minne jämfört med filsystemets cacheminne. Standardvärdet för den här parametern är 60, vilket anger att man byter minnessidor för körningsprocessen jämfört med att ta bort cachesidor i filsystemet med förhållandet 60:140. Att ange värdet 1 anger en stark inställning för att hålla körningsprocessens minne i fysiskt minne på bekostnad av filsystemets cacheminne. Eftersom SQL Server använder buffertminne som cache för datasidor och starkt föredrar att skriva direkt till fysisk hårdvara och kringgå filsystemcachen för tillförlitlig återställning, kan en aggressiv konfiguration av växlingsinställningar vara fördelaktig för en högpresterande och dedikerad SQL Server. Mer information finns i Dokumentation för /proc/sys/vm/ – #swappiness
vm.dirty_*: Skrivåtkomster för SQL Server-filer är icke-cachade och uppfyller kraven på dataintegritet. Dessa parametrar möjliggör effektiv asynkron skrivprestanda och sänker lagrings-I/O-effekten av Linux-cachelagring genom att tillåta tillräckligt stor cachelagring samtidigt som tömningsprocessen begränsas.
kernel.sched_*: Dessa parametervärden representerar den aktuella rekommendationen för att justera CFS-algoritmen (Fullständigt rättvis schemaläggning) i Linux-kerneln för att förbättra dataflödet för nätverks- och lagrings-I/O-anrop med avseende på preemption mellan processer och återupptagande av trådar.

Med mssql TuneD-profilen konfigureras inställningarna vm.swappiness, vm.dirty_* och kernel.sched_*. Konfigurationen av disk readahead med kommandot blockdev är per enhet och måste utföras manuellt.

Kernelinställning för automatisk NUMA-utjämning för NUMA-system med flera noder

Om du installerar SQL Server på ett NUMA-system med flera noder aktiveras följande kernel.numa_balancing kernelinställning som standard. Om du vill tillåta att SQL Server fungerar med maximal effektivitet i ett NUMA-system inaktiverar du automatisk NUMA-utjämning på ett NUMA-system med flera noder:

sysctl -w kernel.numa_balancing=0

Med mssql TuneD-profilen konfigureras alternativet kernel.numa_balancing.

Kernelinställningar för virtuellt adressutrymme

Standardinställningen för vm.max_map_count (som är 65536) kanske inte är tillräckligt hög för en SQL Server-installation. Därför bör du ändra värdet för vm.max_map_count till minst 262144 för en SQL Server-distribution och hänvisa till avsnittet om föreslagna Linux-inställningar med hjälp av en TuneD mssql-profil för ytterligare justeringar av dessa kärnparametrar. Det maximala värdet för vm.max_map_count är 2147483647.

sysctl -w vm.max_map_count=1600000

Med mssql TuneD-profilen konfigureras alternativet vm.max_map_count.

Behåll Transparenta enorma sidor (THP) aktiverade

De flesta Linux-installationer bör ha det här alternativet aktiverat som standard. Vi rekommenderar att du låter det här konfigurationsalternativet vara aktiverat för den mest konsekventa prestandaupplevelsen. Men om det finns hög minnesväxlingsaktivitet i SQL Server-distributioner med flera instanser, till exempel SQL Server-körning med andra minneskrävande program på servern, rekommenderar vi att du testar programmets prestanda när du har kört följande kommando:

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

Eller ändra mssql TuneD-profilen med raden:

vm.transparent_hugepages=madvise

Och gör mssql profilen aktiv efter ändringen:

tuned-adm off
tuned-adm profile mssql

Med mssql TuneD-profilen konfigureras alternativet transparent_hugepage.

Rekommendationer för nätverksinställningar

Precis som det finns lagrings- och CPU-rekommendationer finns det nätverksspecifika rekommendationer samt nedan som referens. Alla inställningar i följande exempel är inte tillgängliga för olika nätverkskort. Rådfråga och konsultera nätverkskortsleverantörer för vägledning vid vart och ett av dessa alternativ. Testa och konfigurera detta i utvecklingsmiljöer innan du tillämpar dem på produktionsmiljöer. Följande alternativ förklaras med exempel och de kommandon som används är specifika för nätverkskortstyp och leverantör.

Konfigurera buffertstorleken för nätverksporten. I exemplet nedan heter nätverkskortet eth0, som är ett Intel-baserat nätverkskort. För Intel-baserat nätverkskort är den rekommenderade buffertstorleken 4 KB (4 096). Kontrollera de förinställda maxinställningarna och konfigurera det sedan med hjälp av följande exempel:

Kontrollera de förinställda maxgränsen med följande kommando. Ersätt eth0 med ditt nätverkskortsnamn:
```
ethtool -g eth0
```
Ange buffertstorleken för både rx (mottagning) och tx (överföring) till 4 KB:
```
ethtool -G eth0 rx 4096 tx 4096
```
Kontrollera att värdet är korrekt konfigurerat:
```
ethtool -g eth0
```
Aktivera jumboramar. Innan du aktiverar jumboramar kontrollerar du att alla nätverksväxlar, routrar och allt annat som är viktigt i nätverkspaketsökvägen mellan klienterna och SQL Server stöder jumboramar. Först då kan du förbättra prestandan genom att möjliggöra jumboramar. När jumboramar har aktiverats ansluter du till SQL Server och ändrar storleken på nätverkspaketen till 8060 med hjälp av sp_configure enligt nedan:
```
# 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
```
Som standard rekommenderar vi att du ställer in porten för anpassningsbar RX/TX IRQ-sammankoppling, vilket innebär att avbrottsleveransen justeras för att förbättra svarstiden när paketfrekvensen är låg och förbättra dataflödet när paketfrekvensen är hög. Den här inställningen kanske inte är tillgänglig för alla olika nätverksinfrastrukturer, så granska den befintliga nätverksinfrastrukturen och bekräfta att detta stöds. Exemplet nedan är för nätverkskortet med namnet eth0, som är ett Intel-baserat nätverkskort:
1. Ange porten för anpassningsbar RX/TX IRQ-sammankoppling:
```
ethtool -C eth0 adaptive-rx on
ethtool -C eth0 adaptive-tx on
```
2. Bekräfta inställningen:
```
ethtool -c eth0
```
Notera

Om du vill ha ett förutsägbart beteende för miljöer med höga prestanda, till exempel miljöer för benchmarking, inaktiverar du den anpassningsbara RX/TX IRQ-sammankopplingen och anger sedan specifikt RX/TX-avbrottssamkopplingen. Se exempelkommandona för att inaktivera RX/TX IRQ-sammankoppling och ange sedan specifikt värdena:

Inaktivera adaptiv RX/TX IRQ-sammankoppling:
```
ethtool -C eth0 adaptive-rx off
ethtool -C eth0 adaptive-tx off
```
Bekräfta ändringen:
```
ethtool -c eth0
```
Ange parametrarna rx-usecs och irq. rx-usecs anger hur många mikrosekunder efter att minst ett paket har tagits emot innan ett avbrott genereras. Parametern irq anger motsvarande fördröjningar i uppdateringen av statusen när avbrottet inaktiveras. För Intel-baserade nätverkskort kan du använda följande inställningar:
```
ethtool -C eth0 rx-usecs 100 tx-frames-irq 512
```
Bekräfta ändringen:
```
ethtool -c eth0
```
Vi rekommenderar också att du aktiverar skalning på mottagarsidan (RSS) och som standard kombinerar du RX- och TX-sidan av RSS-köer. Det har förekommit specifika scenarier när du arbetar med Microsoft Support, där inaktivering av RSS också har förbättrat prestandan. Testa den här inställningen i testmiljöer innan du tillämpar den på produktionsmiljöer. Följande exempel är för Intel-nätverkskort.

Hämta de förinställda maxvärdena:
```
ethtool -l eth0
```
Kombinera köerna med det värde som rapporteras i det förinställda maxvärdet "Kombinerad". I det här exemplet är värdet inställt på 8:
```
ethtool -L eth0 combined 8
```
Kontrollera inställningen:
```
ethtool -l eth0
```
Arbeta med IRQ-fördelning för NIC-portar. För att uppnå förväntad prestanda genom att justera IRQ-tillhörigheten bör du överväga några viktiga parametrar som Linux-hantering av servertopologin, NIC-drivrutinsstacken, standardinställningarna och inställningen irqbalance. Optimeringar av INSTÄLLNINGARNA för NIC-port-IRQ-tillhörighet görs med kunskap om servertopologi, inaktivering av irqbalance och användning av NIC-leverantörsspecifika inställningar.

Följande exempel på Mellanox-specifik nätverksinfrastruktur hjälper till att förklara konfigurationen. För mer information och för att ladda ner Mellanox mlnx-verktygen, se Prestandajusteringsverktyg för Mellanox-nätverkskort. Kommandona ändras baserat på miljön. Kontakta nätverkskortets leverantör för ytterligare vägledning.

Inaktivera irqbalanceeller hämta en ögonblicksbild av IRQ-inställningarna och tvinga daemonen att avsluta:
```
systemctl disable irqbalance.service
```
Eller:
```
irqbalance --oneshot
```
Kontrollera att common_irq_affinity.sh är körbar:
```
chmod +x common_irq_affinity.sh
```
Visa IRQ-tillhörighet för Mellanox NIC-port (till exempel eth0):
```
./show_irq_affinity.sh eth0
```
Optimera för bästa dataflödesprestanda med ett Mellanox-verktyg:
```
./mlnx_tune -p HIGH_THROUGHPUT
```
Ange maskinvarutillhörighet till NUMA-noden som är värd för nätverkskortet fysiskt och dess port:
```
./set_irq_affinity_bynode.sh `\cat /sys/class/net/eth0/device/numa_node` eth0
```
Kontrollera IRQ-tillhörigheten:
```
./show_irq_affinity.sh eth0
```
Lägga till optimeringar för sammankoppling av IRQ
```
ethtool -C eth0 adaptive-rx off
ethtool -C eth0 adaptive-tx off
ethtool -C eth0  rx-usecs 750 tx-frames-irq 2048
```
Kontrollera inställningarna:
```
ethtool -c eth0
```
När ovanstående ändringar är klara kontrollerar du hastigheten på nätverkskortet för att säkerställa att det matchar förväntningarna med hjälp av följande kommando:
```
ethtool eth0 | grep -i Speed
```

Avancerad kernel- och OS-konfiguration

För bästa lagrings-I/O-prestanda använder du mångkösschemaläggning i Linux för blockenheter, vilket gör att blockskikts-prestanda kan skalas bra med snabba SSD-enheter och system med flera kärnor. Kontrollera dokumentationen om den är aktiverad som standard i Linux-distributionen. I de flesta andra fall kan du starta kerneln med scsi_mod.use_blk_mq=y, även om dokumentationen om Linux-distributionen som används kan ha ytterligare vägledning om den. Detta överensstämmer med den överordnade Linux-kerneln.
Eftersom multipath-I/O ofta används för SQL Server-distributioner konfigurerar du målet för enhetsmappning (DM) för flera köer för att använda blk-mq infrastruktur genom att aktivera alternativet dm_mod.use_blk_mq=y kernelstart. Standardvärdet är n (inaktiverat). Den här inställningen, när de underliggande SCSI-enheterna använder blk-mq, minskar låsningskostnaderna på DM-lagret. Mer information om hur du konfigurerar multipath-I/O finns i dokumentationen för Linux-distributionen.

Konfigurera växlingsfil

Se till att du har en korrekt konfigurerad växlingsfil för att undvika problem med slut på minne. I Linux-dokumentationen finns information om hur du skapar och korrekt storleksanpassar en växlingsfil.

Virtuella datorer och dynamiskt minne

Om du kör SQL Server på Linux på en virtuell dator kontrollerar du att du väljer alternativ för att åtgärda mängden minne som är reserverat för den virtuella datorn. Använd inte funktioner som Hyper-V dynamiskt minne.

SQL Server-konfiguration

Utför följande konfigurationsuppgifter när du har installerat SQL Server på Linux för att uppnå bästa prestanda för ditt program.

Metodtips

Använda PROCESSTILLHÖRIGHET för noder och/eller processorer

Använd ALTER SERVER CONFIGURATION för att ange PROCESS AFFINITY för alla NUMANODEoch/eller processorer som du använder för SQL Server (vilket vanligtvis är för alla NODE:er och processorer) i ett Linux-operativsystem. Processortillhörighet hjälper till att upprätthålla ett effektivt linux- och SQL-schemaläggningsbeteende. Att använda alternativet NUMANODE är den enklaste metoden. Använd PROCESS AFFINITY även om du bara har en enda NUMA-nod på datorn. Mer information om hur du anger PROCESS AFFINITYfinns i artikeln ALTER SERVER CONFIGURATION.

Konfigurera flera `tempdb` datafiler

Eftersom en SQL Server på Linux-installation inte erbjuder ett alternativ för att konfigurera flera tempdb filer rekommenderar vi att du skapar flera tempdb datafiler efter installationen. Mer information finns i vägledningen i artikeln Rekommendationer för att minska allokeringskonkurrationen i SQL Server tempdb-databasen.

Avancerad konfiguration

Följande rekommendationer är valfria konfigurationsinställningar som du kan välja att utföra efter installationen av SQL Server i Linux. De här valen baseras på kraven för din arbetsbelastning och konfiguration av ditt Linux-operativsystem.

Ange en minnesgräns med mssql-conf

För att säkerställa att det finns tillräckligt med ledigt fysiskt minne för Linux-operativsystemet använder SQL Server-processen endast 80% av det fysiska RAM-minnet som standard. För vissa system med stora mängder fysiskt RAM-minne kan 20% vara ett betydande antal. I ett system med 1 TB RAM-minne skulle standardinställningen till exempel lämna cirka 200 GB RAM-minne oanvänt. I det här fallet kanske du vill konfigurera minnesgränsen till ett högre värde. Se dokumentationen om verktyget mssql-conf och inställningen memory.memorylimitmb som styr minnet som är synligt för SQL Server (i mb-enheter).

När du ändrar den här inställningen bör du vara noga med att inte ange det här värdet för högt. Om du inte lämnar tillräckligt med minne kan det uppstå problem med Linux-operativsystemet och andra Linux-program.

Dela via

Metodtips för prestanda och konfigurationsriktlinjer för SQL Server i Linux

Rekommendation för lagringskonfiguration

Använda lagringsundersystem med lämplig IOPS, dataflöde och redundans

Rekommendationer för diskpartitionering och konfiguration

konfigurationsrekommendering för filsystem

Rekommendation för beständigt minnefilsystem

Begränsning av öppna filer

Inaktivera senast använda datum/tid på filsystem för SQL Server-data och loggfiler

SQL Server och kapacitet för tvingad enhetsåtkomst (FUA) i I/O-subsystemet

FUA-stöd för SQL Server-containrar som distribueras i Kubernetes

Kernel- och CPU-inställningar för höga prestanda

Använd TuneD- för att konfigurera kernelinställningar

Föreslagna Linux-inställningar med hjälp av en TuneD `mssql`-profil

Rekommendation för CPU-inställningar

Rekommendationer för diskinställningar

Beskrivning

Kernelinställning för automatisk NUMA-utjämning för NUMA-system med flera noder

Kernelinställningar för virtuellt adressutrymme

Behåll Transparenta enorma sidor (THP) aktiverade

Rekommendationer för nätverksinställningar

Avancerad kernel- och OS-konfiguration

Konfigurera växlingsfil

Virtuella datorer och dynamiskt minne

SQL Server-konfiguration

Metodtips

Använda PROCESSTILLHÖRIGHET för noder och/eller processorer

Konfigurera flera `tempdb` datafiler

Avancerad konfiguration

Ange en minnesgräns med mssql-conf

Feedback

Ytterligare resurser

Dela via

Metodtips för prestanda och konfigurationsriktlinjer för SQL Server i Linux

Rekommendation för lagringskonfiguration

Använda lagringsundersystem med lämplig IOPS, dataflöde och redundans

Rekommendationer för diskpartitionering och konfiguration

konfigurationsrekommendering för filsystem

Rekommendation för beständigt minnefilsystem

Begränsning av öppna filer

Inaktivera senast använda datum/tid på filsystem för SQL Server-data och loggfiler

SQL Server och kapacitet för tvingad enhetsåtkomst (FUA) i I/O-subsystemet

FUA-stöd för SQL Server-containrar som distribueras i Kubernetes

Kernel- och CPU-inställningar för höga prestanda

Använd TuneD- för att konfigurera kernelinställningar

Föreslagna Linux-inställningar med hjälp av en TuneD mssql-profil

Rekommendation för CPU-inställningar

Rekommendationer för diskinställningar

Beskrivning

Kernelinställning för automatisk NUMA-utjämning för NUMA-system med flera noder

Kernelinställningar för virtuellt adressutrymme

Behåll Transparenta enorma sidor (THP) aktiverade

Rekommendationer för nätverksinställningar

Avancerad kernel- och OS-konfiguration

Konfigurera växlingsfil

Virtuella datorer och dynamiskt minne

SQL Server-konfiguration

Metodtips

Använda PROCESSTILLHÖRIGHET för noder och/eller processorer

Konfigurera flera tempdb datafiler

Avancerad konfiguration

Ange en minnesgräns med mssql-conf

Relaterat innehåll

Feedback

Ytterligare resurser

Föreslagna Linux-inställningar med hjälp av en TuneD `mssql`-profil

Konfigurera flera `tempdb` datafiler