Metodtips för prestanda: Lagring, kernel, PROCESSOR och nätverk för SQL Server on Linux

Gäller för:SQL Server i Linux

Den här artikeln beskriver rekommendationer för operativsystems- och maskinvarukonfiguration för att maximera prestanda för SQL Server on Linux, inklusive inställningar för lagring, kernel, CPU och nätverk.

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

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 hantera både genomsnittliga och högsta arbetsbelastningar 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 striping över flera diskar för att säkerställa lämplig IOPS, dataflöde och redundans. Det här stödet kan dock variera mellan olika lagringsleverantörer och olika lagringserbjudanden med olika arkitekturer.

För SQL Server på Linux som körs på Azure Virtual Machines bör du överväga att använda programvaru-RAID för att säkerställa lämpliga IOPS- och genomströmningsvärden. Lagringsöverväganden när du konfigurerar SQL Server på Azure virtuella datorer finns i Konfigurera lagring för SQL Server på Azure virtuella datorer.

I följande exempel visas hur du skapar raid-programvara i Linux på en virtuell Azure-dator. Använd 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 är åtta datadiskar anslutna till den virtuella datorn: fyra för att vara värd för datafiler, två för transaktionsloggar och två för tempdb arbetsbelastning.

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

# 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

Använd en RAID-konfiguration för SQL Server. Den distribuerade filesystemrandenheten (sunit) och randbredden matchar RAID-geometrin. I följande exempel visas till exempel en XFS-baserad konfiguration 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 RAID-10 med sex enheter 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.

Rekommenderad filsystemkonfiguration

SQL Server stöder både ext4- och XFS-filsystem som värd för databasen, transaktionsloggar och andra filer, till exempel kontrollpunktsfiler för minnesintern OLTP i SQL Server. Använd XFS-filsystemet för att vara värd för SQL Server data- och transaktionsloggfiler.

Formatera volymen med hjälp av XFS-filsystemet:

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

Du kan konfigurera XFS-filsystemet så att det är skiftlägesokänsligt när du skapar och formaterar XFS-volymen. Den här konfigurationen används inte ofta i Linux-ekosystemet, men du kan använda den av kompatibilitetsskäl.

Kör till exempel följande kommando. Använd -n version=ci 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 anger du blockallokeringen för det underliggande filsystemet till 2 MB. Mer information finns i Tekniska överväganden.

Begränsning av öppna filer

Produktionsmiljön kan kräva fler anslutningar än standardgränsen för 1024 öppna filer på (1 024). Du kan ange mjuka och hårda gränser till 1048576 (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

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

För att säkerställa att systemet automatiskt återmonterar enheterna efter omstart lägger du till dem i filen /etc/fstab. Använd 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. I följande exempel visas hur du aktiverar noatime alternativet för en volym monterad på en virtuell Azure-dator.

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 kommandot blkid .

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

Vissa Linux-distributioner som stöds implementerar åtkomst till tvingad enhet (FUA) på I/O-undersystemnivå för att säkerställa datahållbarhet. SQL Server utnyttjar den här funktionen för att tillhandahålla effektiva och tillförlitliga I/O-prestanda för Linux-arbetsbelastningar. Mer information om FUA-stöd för Linux-distributioner och dess effekt på SQL Server finns i SQL Server på Linux: Tvingad enhetsåtkomst (FUA) Internals.

Stöd för FUA i I/O-undersystemet introducerades i SUSE Linux Enterprise Server 12 SP5, Red Hat Enterprise Linux 8.0 och Ubuntu 18.04. I SQL Server 2017 (14.x) CU 6 och senare versioner använder du följande konfiguration för att aktivera högpresterande och effektiv I/O med FUA i 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)

  Note

  Från och med SQL Server 2025 (17.x) stöds inte SUSE Linux Enterprise Server (SLES).

• XFS-filsystem för SQL Server-lagring i Linux kernel 4.18 eller senare versioner.

• ext4-filsystem för SQL Server-lagring i Linux kernel 5.6 eller senare versioner.

  Note

  Använd XFS-filsystemet för att vara värd för SQL Server-data och transaktionsloggfiler när Linux-kernelversionen är lägre än 5.6. Från och med kernelversionen 5.6 kan du välja mellan XFS och ext4 baserat på dina specifika krav.

• Lagringsundersystem och maskinvara som stöder och är konfigurerad för FUA-kapacitet

Rekommenderad konfiguration:

1. Aktivera spårningsflagga 3979 som startparameter.

2. Använd mssql-conf för att konfigurera control.writethrough = 1 och control.alternatewritethrough = 0.

Använd följande rekommenderade konfiguration för nästan alla andra konfigurationer som inte uppfyller de tidigare villkoren:

1. Aktivera spårningsflagga 3982 som en startparameter (som är standard för SQL Server i Linux-ekosystemet) och se till att spårningsflagga 3979 inte är aktiverad som en startparameter.

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

1. SQL Server måste använda bevarad monterad lagring och inte overlayfs.

2. Lagringen måste använda XFS - eller ext4-filsystemen och bör ha stöd för FUA (ext4 stöder inte FUA på Linux-kerneln tidigare än version 5.6). Innan du aktiverar den här inställningen bör du samarbeta 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 efter den fstype som är inställd på XFS i utmatningen.

3. Arbetsnoden som är värd för SQL Server-poddarna bör 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 använder du följande rekommenderade FUA-inställningar:

1. Aktivera spårningsflagga 3979 som startparameter.

2. 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ödesprestandaprofilen automatiskt vissa kernel- och CPU-inställningar (förutom C-Tillstånd). Från och med RHEL 8.0 kan du använda en TuneD-profil med namnet mssql som erbjuder finare Prestandarelaterade justeringar i Linux för SQL Server arbetsbelastningar. Den här profilen bygger på RHEL-dataflödesprestandaprofilen. Eftersom profilen mssql visar alla inställningar kan du granska och anpassa dem för andra Linux-distributioner eller RHEL-versioner som inte innehåller den här profilen.

För SUSE Linux Enterprise Server 12 SP5, Ubuntu 18.04 och Red Hat Enterprise Linux 7.x kan du installera tuned paketet manuellt. Använd den för att skapa och konfigurera profilen mssql 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:

När du använder TuneD enligt beskrivningen konfigureras automatiskt cpu-frekvensguvernören, ENERGY_PERF_BIASoch min_perf_pct inställningarna. Den använder dataflödesprestandaprofilen som bas för profilen mssql . Du måste konfigurera C-States-parametern manuellt enligt dokumentationen från Linux eller systemdistributören.

Rekommendationer för diskinställningar

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

Description

• 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 du 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 till 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 buffertpoolen som en cache för datasidor och starkt föredrar att skriva direkt på fysisk maskinvara, vilket kringgår filsystemcachen för tillförlitlig återställning, kan en aggressiv swappiness-konfiguration 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. De förbättrar dataflödet för nätverks- och lagrings-I/O-anrop när det gäller preemption mellan processer och återupptagande av trådar.

Användning av TuneD-profilen konfigurerarmssqlvm.swappiness-vm.dirty_* och kernel.sched_* inställningarna. Du måste konfigurera diskinställningen readahead manuellt med hjälp blockdev av kommandot för varje enhet.

Kernel-inställning för automatisk NUMA-utjämning på NUMA-system med flera nod

Om du installerar SQL Server på ett NUMA-system med flera nod är följande kernel.numa_balancing kernelinställning aktiverad 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 nod:

sysctl -w kernel.numa_balancing=0

Med mssql TuneD-profilen konfigureras alternativet kernel.numa_balancing.

Kernelinställningar för virtuellt adressutrymme

Standardinställningen vm.max_map_count för är 65536 (65 536), som kanske inte är tillräckligt hög för en SQL Server installation. Därför ändrar du vm.max_map_count värdet till minst 262144 (262 144) för en SQL Server distribution. Ytterligare justering av dessa kernelparametrar finns i avsnittet Föreslagna Linux-inställningar med hjälp av en TuneD mssql-profil . Det maximala värdet för vm.max_map_count är 2147483647 (2 147 483 647).

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 har det här alternativet aktiverat som standard. Lämna det här konfigurationsalternativet aktiverat för den mest konsekventa prestandaupplevelsen. Men om det finns hög minnesväxlingsaktivitet i SQL Server-distributioner med flera instanser, eller SQL Server-körning med andra minneskrävande program på servern, testar du programmets prestanda efter att ha kört följande kommando:

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

Eller ändra mssql TuneD-profilen med raden:

vm.transparent_hugepages=madvise

Kontrollera att profilen mssql är aktiv efter ändringen:

tuned-adm off
tuned-adm profile mssql

Med mssql TuneD-profilen konfigureras alternativet transparent_hugepage.

Rekommendationer för nätverksinställningar

Tillsammans med rekommendationer för lagring och CPU bör du överväga följande nätverksspecifika rekommendationer. Olika nätverkskort erbjuder olika inställningar. Se NIC-leverantörer för vägledning för vart och ett av dessa alternativ. Testa och konfigurera de här inställningarna 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.

1. Konfigurera buffertstorleken för nätverksporten. I exemplet heter eth0nätverkskortet , 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 maxgränsen för förinställningen 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
   

2. 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 aktiveringen av jumbo frames förbättra prestandan. När du har aktiverat jumboramar ansluter du till SQL Server och ändrar nätverkspaketstorleken till 8060 med hjälp av sp_configure, enligt följande exempel:

   # 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. Konfigurera anpassningsbar IRQ-sammankoppling. Som standard anger du 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 i nätverksinfrastrukturen, så granska den befintliga nätverksinfrastrukturen och bekräfta att den här inställningen stöds. Exemplet är för nätverkskortet med namnet eth0, som är ett Intel-baserat nätverkskort:

   Ange porten för anpassningsbar RX/TX IRQ-sammankoppling:

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

   Bekräfta inställningen:

   ethtool -c eth0
   

   Note

   För förutsägbart beteende i 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
   

4. Aktivera skalning på mottagarsidan (RSS) och kombinera som standard RX- och TX-sidan av RSS-köer. Det finns specifika scenarier när du arbetar med Microsoft Support, där inaktivering av RSS också förbättrar 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
   

5. Konfigurera NIC-port-IRQ-tillhörighet. 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ällningar och irqbalance inställning. Du kan optimera inställningarna för NIC-port-IRQ-tillhörighet med hjälp av dina kunskaper om servertopologi, inaktivera irqbalanceoch använda 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 fysiskt är värd för nätverkskortet 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ägg till IRQ-sammankopplingsoptimeringar:

   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
   

6. Kontrollera NIC-hastigheten. När du har genomfört de föregående ändringarna kontrollerar du hastigheten på nätverkskortet för att säkerställa att det matchar dina förväntningar med hjälp av följande kommando:

   ethtool eth0 | grep -i Speed
   

Avancerad kernel- och OS-konfiguration

• För bästa I/O-prestanda för lagring, använd Linux multiqueue-schemaläggning för blockanordningar. Med den här schemaläggningsmetoden kan blocklagerprestandan skalas bra med snabba SSD-enheter (Solid State Drive) och system med flera kärnor. Kontrollera dokumentationen för att se om Linux-distributionen aktiverar den som standard. I de flesta andra fall kan du starta kerneln med scsi_mod.use_blk_mq=y för att aktivera den. Dokumentationen för din Linux-distribution kan ha ytterligare vägledning om den här inställningen. Den här inställningen är konsekvent med den överordnade Linux-kerneln.

• Eftersom multipath-I/O ofta används för SQL Server-installationer konfigurerar du Device Mapper-målet (DM) för multiqueue så att det använder blk-mq-infrastrukturen genom att aktivera kärnstartalternativet dm_mod.use_blk_mq=y. Standardvärdet är n (inaktiverat). Den här inställningen minskar låsningskostnaderna på DM-lagret när de underliggande SCSI-enheterna använder blk-mq. 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. Om du planerar att köra containrar aktiverar du växlingsutrymme på värdnivå.

Virtuella datorer och dynamiskt minne

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

Konfiguration av SQL Server

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

Bästa praxis

Följande metoder gäller för alla SQL Server on Linux distributioner.

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

Använd ALTER SERVER CONFIGURATION för att ange PROCESS AFFINITY för alla NUMANODEprocessorer och processorer som du använder för SQL Server (vilket vanligtvis gäller för alla NODEprocessorer och processorer) i ett Linux-operativsystem. Processortillhörighet hjälper till att upprätthålla ett effektivt schemaläggningsbeteende för Linux och SQL. 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 ALTER SERVER CONFIGURATION artikeln.

Konfigurera flera tempdb datafiler

Eftersom en SQL Server on Linux installation inte erbjuder ett alternativ för att konfigurera flera tempdb filer bör du överväga att skapa flera tempdb datafiler efter installationen. Mer information finns i rekommendationer för att minska allokeringskonkurrationen i SQL Server tempdb-databasen.

Avancerad konfiguration

Information om alternativ för minneskonfiguration, inklusive mssql-conf minnesgränser, cgroup-inställningar, Exempel på Docker-containerminne och överväganden för byte av utrymme finns i Metodtips för prestanda: SQL Server minne i Linux.

Relaterat innehåll

• Metodtips för prestanda: SQL Server minne i Linux
• Linux-relaterade dynamiska hanteringsvyer och funktioner (Transact-SQL)
• genomgång av prestandafunktionerna i SQL Server på Linux
• Vad är SQL Server i Linux?