Aanbevolen procedures voor prestaties: SQL Server geheugen in Linux

Van toepassing op:SQL Server op Linux

Dit artikel bevat informatie over de geheugenconfiguratie voor SQL Server on Linux, waaronder mssql-conf geheugenlimieten, instellingen voor besturingsgroep (cgroup) en voorbeelden van Docker-containergeheugen en overwegingen voor wisselruimte.

Een geheugenlimiet instellen met mssql-conf

Om ervoor te zorgen dat er voldoende fysiek geheugen beschikbaar is voor het Linux-besturingssysteem, gebruikt het SQL Server proces standaard slechts 80 procent van het fysieke RAM-geheugen. Voor sommige systemen met grote hoeveelheden fysiek RAM-geheugen kan 20 procent een aanzienlijk aantal zijn. Op een systeem met bijvoorbeeld 1 TB RAM blijft de standaardinstelling ongeveer 200 GB RAM-geheugen ongebruikt. In deze situatie wilt u de geheugenlimiet mogelijk configureren op een hogere waarde.

U kunt deze waarde aanpassen met behulp van het mssql-conf hulpprogramma of de MSSQL_MEMORY_LIMIT_MB omgevingsvariabele. Zie voor meer informatie de instelling memory.memorylimitmb waarmee het geheugen wordt beheerd dat zichtbaar is voor SQL Server (in eenheden van MB). Zie Richtlijnen voor het instellen van geheugenlimieten op Linux en in containers voor gedetailleerde richtlijnen voor dimensionering.

Ondersteuning voor controlegroep (cgroup) v2

SQL Server detecteert en voldoet aan beperkingen voor de controlegroep (cgroup) v2, te beginnen met SQL Server 2025 (17.x) en SQL Server 2022 (16.x) Cumulatieve update (CU) 20. Deze beperkingen bieden nauwkeurige controle in de Linux-kernel over CPU- en geheugenresources en verbeteren resource-isolatie in Docker-, Kubernetes- en OpenShift-omgevingen.

In eerdere versies kunnen in containers geplaatste implementaties op Kubernetes-clusters (bijvoorbeeld Azure Kubernetes Service v1.25+) fouten met onvoldoende geheugen (OOM) ondervinden omdat SQL Server geen geheugenlimieten heeft afgedwongen die zijn gedefinieerd in containerspecificaties. Ondersteuning voor cgroup v2 lost dit probleem op.

CGroup-versie controleren

stat -fc %T /sys/fs/cgroup

De resultaten zijn als volgt:

Overschakelen naar cgroup v2

Het eenvoudigste pad is het kiezen van een distributie die ondersteuning biedt voor cgroup v2.

Als u handmatig moet overschakelen, voegt u de volgende parameter toe aan uw GRUB-configuratie:

systemd.unified_cgroup_hierarchy=1

Werk GRUB vervolgens bij. Voer bijvoorbeeld in Ubuntu het volgende uit:

sudo update-grub

Voer op Red Hat Enterprise Linux (RHEL) de volgende opdracht uit:

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

CPU-limietrapportage met cgroup v2

Wanneer u CPU-limieten configureert met cgroup v2, wordt SQL Server het geconfigureerde aantal CPU-kernen niet weergegeven in het foutenlogboek. In plaats daarvan blijft het systeem het totale aantal host-CPU's rapporteren.

Als u SQL Server scheduler en queryplannen wilt uitlijnen (bijvoorbeeld beslissingen voor parallelle uitvoering) met het beoogde CPU-aantal dat is gedefinieerd in cgroup v2, past u de volgende configuratie toe.

Processoraffiniteit configureren

Stel expliciet SQL Server processoraffiniteit in zodat deze overeenkomt met het quotum voor cgroup-uitvoering. In het volgende voorbeeld is het cgroupquotum vier CPU's op een host met acht kernen:

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

Deze configuratie zorgt ervoor dat SQL Server alleen schedulers maakt voor het beoogde aantal CPU's. Zie ALTER SERVER CONFIGURATION en Gebruik PROCESS AFFINITY voor Node en/of CPU's voor meer informatie.

Traceringsvlag 8002 inschakelen (aanbevolen)

Schakel traceringsvlag 8002 in om zachte affiniteit te gebruiken op de SQLPAL-laag:

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

Schedulers zijn standaard gebonden aan specifieke CPU's die zijn gedefinieerd in het affiniteitsmasker. Traceringsvlag 8002 maakt het mogelijk dat schedulers over CPU's heen worden verplaatst, wat over het algemeen de prestaties verbetert, terwijl affiniteit- en cgroup-beperkingen worden gerespecteerd. Zie DBCC TRACEON - Trace flagsvoor meer informatie.

Start SQL Server opnieuw nadat u de traceringsvlag hebt ingeschakeld.

Verwacht gedrag

Na opnieuw opstarten:

• SQL Server maakt alleen het aantal planners dat is gedefinieerd door de affiniteitsinstelling (bijvoorbeeld vier planners).

• De Linux-kernel blijft het quotum voor cpu-uitvoering van cgroup v2 afdwingen.

• Beslissingen over queryoptimalisatie en parallelle uitvoering zijn gebaseerd op het beoogde CPU-aantal, in plaats van de totale host-CPU's.

Zie de volgende bronnen voor meer informatie:

• Quickstart: Een SQL Server Linux-container implementeren in Kubernetes met behulp van Helm-grafieken
• Control Group v2 (Linux-kerneldocumentatie)

Richtlijnen voor het instellen van geheugenlimieten voor Linux en in containers

SQL Server on Linux heeft meerdere geheugenbesturingselementen die op verschillende niveaus werken. In de volgende tabel en het diagram ziet u hoe elk niveau het beschikbare geheugen beperkt, van host-RAM tot aan de buffergroep.

Houd rekening met de volgende richtlijnen bij het instellen van geheugenlimieten voor SQL Server in Linux:

• Gebruik in containerimplementaties cgroup om het totale geheugen te beperken dat beschikbaar is voor de container. Met deze instelling wordt de bovengrens voor alle processen in de container ingesteld.

• De geheugenlimiet (of deze is ingesteld door memorylimitmb of de MSSQL_MEMORY_LIMIT_MB omgevingsvariabele) bepaalt het totale geheugen dat SQL Server op Linux kan toewijzen aan alle onderdelen, zoals de buffergroep, SQLPAL, SQL Server Agent, LibOS, PolyBase, Full-Text Search en elk ander proces dat in SQL Server op Linux is geladen.

• De MSSQL_MEMORY_LIMIT_MB omgevingsvariabele heeft voorrang op memorylimitmb gedefinieerd in mssql.conf.

• memorylimitmb kan het werkelijke fysieke geheugen van het hostsysteem niet overschrijden.

• Stel memorylimitmb lager in dan het geheugen van het hostsysteem en de cgroup limiet (indien aanwezig) om ervoor te zorgen dat er voldoende vrij fysiek geheugen beschikbaar is voor het Linux-besturingssysteem. Als u niet expliciet memorylimitmbinstelt, gebruikt SQL Server 80 procent van de lagere waarde tussen het totale systeemgeheugen en de cgroup limiet (indien aanwezig).

• De max_server_memory serverconfiguratieoptie beperkt alleen de grootte van de SQL Server-buffergroep en bepaalt niet het totale geheugengebruik voor SQL Server op Linux. Stel deze waarde altijd lager in dan memorylimitmb om ervoor te zorgen dat er voldoende geheugen overblijft voor de andere onderdelen die in het vorige opsommingsteken worden beschreven.

Marge tussen SQL Server en de geheugenlimieten van containers

Wanneer u SQL Server uitvoert in een container met een geconfigureerde geheugenlimiet (bijvoorbeeld de cgroup instellingmemory.max), behoudt u de hoofdruimte tussen memory.memorylimitmb en de geheugenlimiet van de container. Deze marge biedt ruimte voor de overhead van het besturingssysteem en ondersteunende processen binnen de container.

• Voor de meeste implementaties reserveert u tussen 10 en 20% van het containergeheugen voor het besturingssysteem en niet-SQL Server processen en stelt u memory.memorylimitmb onder de resterende capaciteit in.

• Voor grote geheugenconfiguraties kan een buffer op basis van een percentage meer geheugen reserveren dan nodig is. Zo is 10 procent van een container van 256 GB ongeveer 25 GB, wat redelijk is voor overhead van het besturingssysteem. 10 procent van een container van 512 GB is echter ongeveer 51 GB, wat waarschijnlijk meer is dan het besturingssysteem vereist. In deze gevallen gebruikt u in plaats daarvan een vaste buffer, past u de juiste grootte toe voor de overhead van uw workload en besturingssysteem en wijst u de rest toe aan SQL Server.

• Pas de buffer aan op basis van workloadkenmerken, andere services die in de container worden uitgevoerd en de hostconfiguratie.

Vermijd het configureren van geheugenlimieten die hoger zijn dan het beschikbare geheugen

Configureer niet memory.memorylimitmb hoger dan het beschikbare fysieke geheugen op de host of hoger dan de door de container afgedwongen geheugenlimiet. Als u dat wel doet, kan SQL Server agressief geheugen verbruiken, waardoor er onvoldoende capaciteit overblijft voor het besturingssysteem en ondersteunende processen. Deze configuratie kan leiden tot:

• Verhoogde geheugendruk.
• Verminderde systeemstabiliteit en onverwachte serviceonderbrekingen.
• Het besturingssysteem beëindigt het sqlservr proces vanwege onvoldoende geheugen (OOM).

Configureer SQL Server geheugenlimieten onder het effectieve geheugen dat beschikbaar is voor de host of container en laat voldoende bufferruimte over voor het besturingssysteem en runtimeservices.

Voorbeelden van Docker-geheugenconfiguratie

Met docker run --memory de optie wordt de cgroup geheugenlimiet voor de container ingesteld. Deze limiet is het door kernel afgedwongen harde plafond voor alle processen in de container. MSSQL_MEMORY_LIMIT_MB(of memory.memorylimitmb) bepaalt hoeveel van dat geheugen SQL Server kan gebruiken. Zoals beschreven in de vorige richtlijnen, moet u altijd een lagere limiet instellen MSSQL_MEMORY_LIMIT_MB dan de limiet voor het geheugen van de container om de hoofdruimte voor het besturingssysteem en hulpprocessen te verlaten.

In de volgende voorbeelden wordt een host met 16 GB RAM-geheugen gebruikt. Pas waarden aan voor uw omgeving.

Niet aanbevolen: geen geheugenlimiet voor containers

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

Zonder --memoryheeft de container geen cgroup plafond. MSSQL_MEMORY_LIMIT_MB beperkt SQL Server, maar andere processen in de container kunnen nog steeds onbeperkt hostgeheugen verbruiken.

Niet aanbevolen: geheugenlimiet gelijk aan SQL Server geheugenlimiet

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

Beide limieten zijn ingesteld op 12 GB (--memory 12g = 12.288 MB). Er blijft geen hoofdruimte over voor overhead- of hulpprocessen van het besturingssysteem, wat kan leiden tot OOM-kills.

Niet aanbevolen: SQL Server geheugenlimiet overschrijdt de containerlimiet

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) overschrijdt de containerlimiet (12 GB). Dit scenario leidt tot de OOM-voorwaarden die worden beschreven in Voorkomen dat geheugenlimieten hoger zijn dan het beschikbare geheugen.

Aanbevolen: containerlimiet met extra ruimte voor het besturingssysteem

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

De container is beperkt tot 12 GB (--memory 12g) en SQL Server is geconfigureerd voor gebruik van maximaal 10 GB (MSSQL_MEMORY_LIMIT_MB=10240). De resterende 2 GB (ongeveer 17 procent) biedt ruimte voor het besturingssysteem en andere processen.

Overwegingen bij swapruimte

Wanneer u SQL Server uitvoert in een container, schakelt u wisselruimte op hostniveau in om het besturingssysteem en niet-SQL Server processen te beveiligen. Configureer echter SQL Server om te werken binnen de geconfigureerde geheugenlimieten en vertrouw niet op wisselen tijdens normale bewerkingen.

• Volg de richtlijnen voor de geheugenlimiet om ervoor te zorgen dat SQL Server werkt binnen het fysieke geheugen of de toepasselijke cgroup geheugenlimiet.

• Als swap is ingeschakeld, beschouw dit dan als een vangnet voor tijdelijke geheugendruk op de host, niet als capaciteit voor constante SQL Server-workloads.

Verwante inhoud

• Best practices voor prestaties: Opslag, kernel, CPU en netwerk voor SQL Server on Linux
• Aan Linux gerelateerde dynamische beheerweergaven en -functies (Transact-SQL)
• overzicht van de prestatiefuncties van SQL Server op Linux
• Wat is SQL Server in Linux?