Metodtips för prestanda: SQL Server minne i Linux

Gäller för:SQL Server i Linux

Den här artikeln beskriver minneskonfiguration för SQL Server on Linux, inklusive mssql-conf minnesgränser, inställningar för kontrollgrupper (cgroup), Exempel på Docker-containerminne och överväganden för växlingsutrymme.

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 procent av det fysiska RAM-minnet som standard. För vissa system med stora mängder fysiskt RAM-minne kan 20 procent vara ett betydande antal. I ett system med 1 TB RAM-minne lämnar standardinställningen till exempel cirka 200 GB RAM-minne oanvänt. I det här fallet kanske du vill konfigurera minnesgränsen till ett högre värde.

Du kan justera det här värdet med hjälp av mssql-conf verktyget eller MSSQL_MEMORY_LIMIT_MB miljövariabeln. Mer information finns i inställningen memory.memorylimitmb som styr minnet som är synligt för SQL Server (i mb-enheter). Detaljerade riktlinjer för storleksändring finns i Riktlinjer för att ange minnesgränser för Linux och i containrar.

Stöd för kontrollgrupp (cgroup) v2

SQL Server identifierar och respekterar kontrollgruppsbegränsningar (cgroup) v2, från och med SQL Server 2025 (17.x) och SQL Server 2022 (16.x) Kumulativ uppdatering (CU) 20. Dessa begränsningar ger detaljerad kontroll i Linux-kerneln över processor- och minnesresurser och förbättrar resursisolering i Docker-, Kubernetes- och OpenShift-miljöer.

I tidigare versioner kan containerbaserade distributioner på Kubernetes-kluster (till exempel Azure Kubernetes Service v1.25+) uppleva minnesfel (OOM) eftersom SQL Server inte framtvingade minnesgränser som definierats i containerspecifikationer. Stöd för cgroup v2 åtgärdar det här problemet.

Kontrollera cgroup-versionen

stat -fc %T /sys/fs/cgroup

Resultatet är följande:

Växla till cgroup v2

Den enklaste sökvägen är att välja en distribution som stöder cgroup v2 direkt.

Om du behöver växla manuellt lägger du till följande parameter i GRUB-konfigurationen:

systemd.unified_cgroup_hierarchy=1

Uppdatera sedan GRUB. Kör till exempel på Ubuntu:

sudo update-grub

På Red Hat Enterprise Linux (RHEL) kör du:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Cpu-gränsrapportering med cgroup v2

När du konfigurerar CPU-gränser med cgroup v2 visar SQL Server inte det konfigurerade antalet processorkärnor i felloggen. I stället fortsätter den att rapportera det totala antalet värd-PROCESSORer.

Använd följande konfiguration för att justera SQL Server schemaläggare och frågeplaner (till exempel parallellitetsbeslut) med det avsedda CPU-antalet som definieras i cgroup v2.

Konfigurera processortillhörighet

Ange uttryckligen SQL Server processortillhörighet så att den matchar cgroup-körningskvoten. I följande exempel är cgroup-kvoten fyra processorer på en värd med åtta kärnor:

ALTER SERVER CONFIGURATION
SET PROCESS AFFINITY CPU = 0 TO 3;

Den här konfigurationen säkerställer att SQL Server endast skapar schemaläggare för det avsedda antalet processorer. Mer information finns i ALTER SERVER CONFIGURATION och Använda PROCESSTILLHÖRIGHET för noder och/eller processorer.

Aktivera spårningsflagga 8002 (rekommenderas)

Aktivera spårningsflagga 8002 för att använda mjuk affinitet på SQLPAL-lagret:

sudo /opt/mssql/bin/mssql-conf traceflag 8002 on

Schemaläggare är som standard bundna till specifika processorer som definierats i tillhörighetsmasken. Spårningsflagga 8002 gör det möjligt för schemaläggare att flytta över CPU:er i stället, vilket i allmänhet förbättrar prestandan samtidigt som affinitets- och cgroup-begränsningarna respekteras. Mer information finns i DBCC TRACEON – Trace Flags.

Starta om SQL Server när spårningsflaggan har aktiverats.

Förväntat beteende

Efter omstart:

• SQL Server skapar endast antalet schemaläggare som definieras av tillhörighetsinställningen (till exempel fyra schemaläggare).

• Linux-kerneln fortsätter att upprätthålla cgroup v2 CPU-kvoten.

• Beslut om frågeoptimering och parallellitet baseras på det avsedda antalet processorer i stället för de totala värd-PROCESSORerna.

Mer information finns i följande resurser:

• Snabbstart: Distribuera en SQL Server Linux-container till Kubernetes med hjälp av Helm-diagram
• Kontrollgrupp v2 (Linux Kernel-dokumentation)

Riktlinjer för att ange minnesgränser för Linux och i containrar

SQL Server on Linux har flera minneskontroller som fungerar på olika nivåer. Följande tabell och diagram visar hur varje nivå begränsar det tillgängliga minnet, från värd-RAM ned till buffertpoolen.

När du anger minnesgränser för SQL Server i Linux bör du tänka på följande riktlinjer:

• I containerdistributioner använder du cgroup för att begränsa det totala minnet som är tillgängligt för containern. Den här inställningen etablerar den övre gränsen för alla processer i containern.

• Minnesgränsen (oavsett om den anges av memorylimitmb eller MSSQL_MEMORY_LIMIT_MB miljövariabeln) styr det totala minne som SQL Server på Linux kan allokera över alla dess komponenter, till exempel buffertpoolen, SQLPAL, SQL Server Agent, LibOS, PolyBase, Full-Text Search och alla andra processer som läses in i SQL Server på Linux.

• Miljövariabeln MSSQL_MEMORY_LIMIT_MB har företräde framför memorylimitmb definierad i mssql.conf.

• memorylimitmb får inte överskrida värdsystemets faktiska fysiska minne.

• Ange memorylimitmb lägre än värdsystemminnet och cgroup gränsen (om det finns) för att säkerställa att det finns tillräckligt med ledigt fysiskt minne för Linux-operativsystemet. Om du inte uttryckligen anger memorylimitmbanvänder SQL Server 80 procent av det lägre värdet mellan det totala systemminnet och gränsen (om det cgroup finns).

• Konfigurationsalternativet max_server_memory server begränsar endast storleken på SQL Server-buffertpoolen och styr inte den totala minnesanvändningen för SQL Server i Linux. Ange alltid det här värdet lägre än memorylimitmb för att säkerställa att tillräckligt med minne finns kvar för de andra komponenterna som beskrivs i föregående punkt.

Utrymme mellan minnesgränser för SQL Server och containrar

När du kör SQL Server i en container med en konfigurerad minnesgräns (till exempel cgroup inställningen memory.max), underhåller du utrymme mellan memory.memorylimitmb och gränsen för containerminnet. Den här marginalen ger utrymme för operativsystemets overhead och hjälpprocesser i containern.

• För de flesta distributioner reserverar du mellan 10 och 20 procent av containerminnet för operativsystemet och icke-SQL Server processer och anger memory.memorylimitmb under den återstående kapaciteten.

• För stora minneskonfigurationer kan en procentbaserad buffert reservera mer minne än nödvändigt. Till exempel är 10 procent av en container på 256 GB cirka 25 GB, vilket är rimligt för operativsystemets omkostnader. 10 procent av en container på 512 GB är dock cirka 51 GB, vilket sannolikt är mer än vad operativsystemet kräver. I dessa fall använder du en fast buffert i stället, storleksanpassas korrekt för din arbetsbelastning och operativsystemomkostnader och allokerar resten till SQL Server.

• Justera bufferten baserat på arbetsbelastningens egenskaper, andra tjänster som körs i containern och värdkonfigurationen.

Undvik att konfigurera minnesgränser som är högre än tillgängligt minne

Konfigurera inte memory.memorylimitmb till ett värde som är högre än det tillgängliga fysiska minnet på värddatorn eller högre än den minnesgräns som containern upprätthåller. Om du gör det kan SQL Server aggressivt förbruka minne, vilket lämnar otillräcklig kapacitet för operativsystemet och stödjande processer. Den här konfigurationen kan resultera i:

• Ökat minnestryck.
• Minskad systemstabilitet och oväntade avbrott i tjänsten.
• Att operativsystemet avslutar processen sqlservr på grund av minnesbrist (OOM).

Konfigurera SQL Servers minnesgränser så att de ligger under det faktiskt tillgängliga minnet för värddatorn eller containern, och lämna tillräckligt med buffertutrymme för operativsystemet och körtidstjänster.

Exempel på Docker-minneskonfiguration

Alternativet docker run --memory anger cgroup minnesgränsen för containern. Den här gränsen är den övre hårda gräns som kärnan upprätthåller för alla processer i containern. MSSQL_MEMORY_LIMIT_MB(eller memory.memorylimitmb) styr hur mycket av minnet som SQL Server kan använda. Enligt beskrivningen i föregående riktlinjer anger MSSQL_MEMORY_LIMIT_MB du alltid lägre än gränsen för containerminne för att lämna utrymme för operativsystemet och hjälpprocesserna.

I följande exempel används en värd med 16 GB RAM-minne. Justera värden för din miljö.

Rekommenderas inte: ingen gräns för containerminne

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" \
   -e "MSSQL_MEMORY_LIMIT_MB=14336" \
   -p 1433:1433 \
   -d mcr.microsoft.com/mssql/server:2022-latest

Utan --memoryhar containern inget cgroup tak. MSSQL_MEMORY_LIMIT_MBbegränsar SQL Server, men andra processer i containern kan fortfarande förbruka obundet värdminne.

Rekommenderas inte: minnesgräns lika med SQL Server minnesgräns

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" \
   -e "MSSQL_MEMORY_LIMIT_MB=12288" \
   --memory 12g \
   -p 1433:1433 \
   -d mcr.microsoft.com/mssql/server:2022-latest

Båda gränserna är inställda på 12 GB (--memory 12g = 12 288 MB). Inget utrymme återstår för operativsystemomkostnader eller extra processer, vilket kan leda till OOM-avlivningar.

Rekommenderas inte: SQL Server minnesgränsen överskrider containergränsen

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" \
   -e "MSSQL_MEMORY_LIMIT_MB=14336" \
   --memory 12g \
   -p 1433:1433 \
   -d mcr.microsoft.com/mssql/server:2022-latest

MSSQL_MEMORY_LIMIT_MB (14 GB) överskrider containergränsen (12 GB). Det här scenariot leder till OOM-villkoren som beskrivs i Undvik att konfigurera minnesgränser som är högre än tillgängligt minne.

Rekommenderas: containergräns med utrymme för operativsystemet

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" \
   -e "MSSQL_MEMORY_LIMIT_MB=10240" \
   --memory 12g \
   -p 1433:1433 \
   -d mcr.microsoft.com/mssql/server:2022-latest

Containern är begränsad till 12 GB (--memory 12g) och SQL Server är konfigurerad att använda upp till 10 GB (MSSQL_MEMORY_LIMIT_MB=10240). Återstående 2 GB (cirka 17 procent) ger utrymme för operativsystemet och andra processer.

Överväganden för växlingsutrymme

När du kör SQL Server i en container aktiverar du växlingsutrymme på värdnivå för att skydda operativsystemet och icke-SQL Server processer. Konfigurera dock SQL Server att fungera inom dess konfigurerade minnesgränser och förlita dig inte på växling under normal drift.

• Följ riktlinjerna för minnesgräns för att säkerställa att SQL Server fungerar inom fysiskt minne eller den tillämpliga cgroup minnesgränsen.

• Om swap är aktiverat, betrakta det som ett skyddsnät vid tillfällig minnesbrist på värden, inte som kapacitet för SQL Server-arbetsbelastningar i normal drift.

Relaterat innehåll

• Metodtips för prestanda: Lagring, kernel, PROCESSOR och nätverk för SQL Server on Linux
• Linux-relaterade dynamiska hanteringsvyer och funktioner (Transact-SQL)
• genomgång av prestandafunktionerna i SQL Server på Linux
• Vad är SQL Server i Linux?