Osvědčené postupy pro výkon: paměť SQL Serveru v Linuxu

Platí pro:SQL Server na Linuxu

Tento článek se zabývá konfigurací paměti pro SQL Server v Linuxu, včetně omezení paměti mssql-conf, nastavení řídicích skupin (cgroup), příkladů paměti kontejnerů Dockeru a aspektů odkládacího prostoru.

Nastavení limitu paměti pomocí mssql-conf

Aby se zajistilo, že pro operační systém Linux je dostatek volné fyzické paměti, SQL Server proces ve výchozím nastavení používá pouze 80 % fyzické paměti RAM. U některých systémů s velkým množstvím fyzické paměti RAM může být 20 procent významné číslo. Například v systému s 1 TB paměti RAM výchozí nastavení ponechá přibližně 200 GB paměti RAM nevyužité. V takovém případě můžete chtít nakonfigurovat limit paměti na vyšší hodnotu.

Tuto hodnotu můžete upravit pomocí nástroje mssql-conf nebo proměnné prostředí MSSQL_MEMORY_LIMIT_MB. Další informace najdete v nastavení memory.memorylimitmb , které řídí paměť viditelnou pro SQL Server (v jednotkách MB). Podrobné pokyny k určení velikosti najdete v tématu Pokyny k nastavení limitů paměti v Linuxu a v kontejnerech.

Podpora skupin ovládacích prvků (cgroup) v2

SQL Server zjistí a respektuje omezení kontrolní skupiny cgroup v2, počínaje SQL Serverem (verze 2025, 17.x) a SQL Serverem (verze 2022, 16.x) kumulativní aktualizací (CU) 20. Tato omezení poskytují jemně odstupňované řízení v jádru Linuxu nad prostředky procesoru a paměti a zlepšují izolaci prostředků v prostředích Docker, Kubernetes a OpenShift.

V dřívějších verzích můžou kontejnerizovaná nasazení v clusterech Kubernetes (například Azure Kubernetes Service v1.25+) zaznamenat chyby nedostatku paměti (OOM), protože SQL Server nevynucovala limity paměti definované ve specifikacích kontejnerů. Tento problém řeší podpora cgroup v2.

Kontrola verze cgroup

stat -fc %T /sys/fs/cgroup

Výsledky jsou následující:

Result Description
cgroup2fs Použijete cgroup v2.
cgroup Použijete cgroup v1.

Přepnutí na cgroup v2

Nejjednodušší cestou je volba distribuce, která podporuje cgroup v2.

Pokud potřebujete přepnout ručně, přidejte do konfigurace GRUB následující parametr:

systemd.unified_cgroup_hierarchy=1

Pak aktualizujte GRUB. Například na Ubuntu spusťte:

sudo update-grub

V Red Hat Enterprise Linuxu (RHEL) spusťte:

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

Hlášení o limitu CPU s cgroup v2

Když nakonfigurujete omezení procesoru pomocí cgroup v2, SQL Server v protokolu chyb nezobrazí nakonfigurovaný počet jader procesoru. Místo toho nadále hlásí celkový počet hostitelských procesorů.

Pokud chcete sladit SQL Server plánovače a plány dotazů (například rozhodnutí o paralelismu) se zamýšleným počtem procesorů definovaným v cgroup v2, použijte následující konfiguraci.

Konfigurace spřažení procesoru

Explicitně nastavte spřažení procesoru SQL Server tak, aby odpovídalo kvótě výkonu pro cgroup. V následujícím příkladu je kvóta cgroup čtyři procesory na osmijádrovém hostiteli.

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

Tato konfigurace zajišťuje, že SQL Server vytváří plánovače pouze pro zamýšlený počet procesorů. Další informace naleznete v ALTER SERVER CONFIGURATION a Použití PROCESS AFFINITY pro uzly a/nebo CPU.

Povolte příznak trasování 8002 pro použití měkkého spřažení ve vrstvě SQLPAL:

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

Ve výchozím nastavení jsou plánovače vázány na konkrétní procesory definované v maskě spřažení. Příznak trasování 8002 umožňuje plánovačům přesouvat se mezi procesory, což obecně zlepšuje výkon a zároveň respektuje přiřazení procesorů a omezení cgroup. Další informace naleznete v tématu DBCC TRACEON - Trace Flags.

Po povolení příznaku trasování restartujte SQL Server.

Očekávané chování

Po restartování:

  • SQL Server vytvoří pouze počet plánovačů definovaných nastavením spřažení (například čtyři plánovače).

  • Jádro Linuxu nadále vynucuje kvótu spouštění procesoru cgroup v2.

  • Rozhodnutí o optimalizaci dotazů a paralelismu jsou založená na zamýšleném počtu procesorů, nikoli na celkovém počtu procesorů hostitele.

Note

Protokol chyb SQL Server může i nadále zobrazovat celkový počet procesorů hostitele. Toto chování protokolování a zobrazení nemá vliv na skutečné využití procesoru, vytvoření plánovače nebo vynucení procesoru pomocí cgroup v2 nebo spřažení procesoru.

Další informace naleznete v následujících zdrojích:

Pokyny pro nastavení limitů paměti v Linuxu a v kontejnerech

SQL Server on Linux má více ovládacích prvků paměti, které pracují na různých úrovních. Následující tabulka a diagram ukazují, jak každá úroveň zužuje dostupnou paměť z paměti RAM hostitele do fondu vyrovnávací paměti.

Úroveň Nastavuje Description
Host Konfigurace hardwaru nebo virtuálního počítače Fyzická paměť RAM na serveru nebo virtuálním počítači
cgroup limit (docker run --memory, systemd, nebo manuál) Běhové prostředí kontejneru, systemd slice nebo ruční cgroup konfigurace Limit vynucený jádrem (memory.max) pro všechny procesy v cgroup. Volitelné pro Linux na fyzickém hardwaru.
proces SQL Server (memorylimitmb / MSSQL_MEMORY_LIMIT_MB) mssql-conf nebo proměnná prostředí Celková paměť napříč všemi komponentami SQL Server. Musí být nižší než limit cgroup (pokud je nastaven) nebo než paměť hostitele.
Fond vyrovnávacích pamětí (max_server_memory) sp_configure Mezipaměť pro 8KB datové stránky. Musí být nižší než memorylimitmb.
Prostoru Počítané (mezera mezi limity) Mezera mezi limitem cgroup (nebo pamětí hostitele) a memorylimitmbvyhrazenou pro režii operačního systému a pomocnými procesy.

Diagram znázorňující vnořené vrstvy ovládacích prvků paměti

Při nastavování limitů paměti pro SQL Server v Linuxu zvažte následující pokyny:

  • Při nasazení kontejnerů použijte cgroup k omezení celkového množství paměti dostupné pro kontejner. Toto nastavení vytvoří horní mez pro všechny procesy uvnitř kontejneru.

  • Limit paměti (ať už nastavený proměnnou prostředí memorylimitmb nebo proměnnou prostředí MSSQL_MEMORY_LIMIT_MB) řídí celkovou paměť, kterou může SQL Server v Linuxu přidělit napříč všemi jeho komponentami, jako je fond vyrovnávací paměti, SQLPAL, agent SQL Serveru, LibOS, PolyBase, Full-Text Search a jakýkoli jiný proces načtený v SQL Serveru na Linuxu.

  • Proměnná MSSQL_MEMORY_LIMIT_MB prostředí má přednost před memorylimitmb definovaným v mssql.conf.

  • memorylimitmb nemůže překročit skutečnou fyzickou paměť hostitelského systému.

  • Nastavte memorylimitmb nižší než paměť hostitelského systému a cgroup limit (pokud je k dispozici), abyste zajistili, že je pro operační systém Linux dostatek volné fyzické paměti. Pokud explicitně nenastavíte memorylimitmb, SQL Server použije 80 procent menší hodnoty mezi celkovou systémovou pamětí a limitem cgroup (pokud je k dispozici).

  • Možnost konfigurace serveru max_server_memory omezuje pouze velikost fondu vyrovnávací paměti SQL Serveru a neřídí celkové využití paměti pro SQL Server v Linuxu. Tuto hodnotu vždy nastavte na nižší hodnotu než memorylimitmb, aby byla zajištěna dostatečná paměť pro ostatní komponenty popsané v předchozí odrážce.

Hlavní prostor mezi limity paměti SQL Server a kontejneru

Když spustíte SQL Server v kontejneru s nakonfigurovaným limitem paměti (například pomocí nastavení cgroupmemory.max), udržujte rezervu mezi memory.memorylimitmb a limitem paměti kontejneru. Tato rezerva poskytuje prostor pro režii operačního systému a pomocné procesy uvnitř kontejneru.

  • U většiny nasazení si vyhraďte 10 až 20 procent paměti kontejneru pro operační systém a procesy, které nejsou SQL Server, a nastavte memory.memorylimitmb ji pod zbývající kapacitu.

  • U velkých konfigurací paměti může procentuální rezerva vyhradit více paměti, než je nutné. Například 10 procent kontejneru 256 GB je přibližně 25 GB, což je přiměřené pro režii operačního systému. 10 % kontejneru 512 GB je ale přibližně 51 GB, což je pravděpodobně větší než vyžaduje operační systém. V těchto případech místo toho použijte pevně stanovenou vyrovnávací paměť o velikosti odpovídající vaší pracovní zátěži a režii operačního systému a zbytek přidělte SQL Serveru.

  • Upravte vyrovnávací paměť na základě charakteristik úloh, dalších služeb spuštěných v kontejneru a konfigurace hostitele.

Note

Neexistuje žádná jediná doporučená hodnota rezervy, která by platila pro všechna prostředí. Ověřte nastavení paměti prostřednictvím testování, abyste zajistili stabilitu systému při zatížení ve špičce.

Vyhněte se konfiguraci limitů paměti vyšší než dostupná paměť

Nenakonfigurujte memory.memorylimitmb vyšší než dostupnou fyzickou paměť na hostiteli nebo vyšší, než je limit paměti vynucený kontejnerem. Pokud to uděláte, může SQL Server agresivně využívat paměť, takže pro operační systém a podpůrné procesy nezbude dostatečná kapacita. Výsledkem této konfigurace může být:

  • Zvýšený tlak na paměť.
  • Snížená stabilita systému a neočekávané přerušení služeb
  • Ukončení procesu sqlservr operačním systémem z důvodu nedostatku paměti (OOM).

Nastavte limity paměti serveru SQL Server na hodnotu nižší, než je skutečně dostupná paměť pro hostitele nebo kontejner, a ponechte dostatečnou rezervu paměti pro operační systém a služby běhového prostředí.

Příklady konfigurace paměti Dockeru

Tato docker run --memory možnost nastaví cgroup limit paměti pro kontejner. Tento limit je pevný limit vynucený jádrem pro všechny procesy v kontejneru. MSSQL_MEMORY_LIMIT_MB(nebomemory.memorylimitmb) určuje, kolik paměti SQL Server může používat. Jak je popsáno v předchozích pokynech, vždy nastavte MSSQL_MEMORY_LIMIT_MB nižší než limit paměti kontejneru, aby opustil hlavní prostor pro operační systém a pomocné procesy.

Následující příklady používají hostitele s 16 GB paměti RAM. Upravte hodnoty pro vaše prostředí.

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

Bez --memory nemá kontejner žádnou cgroup horní hranici. MSSQL_MEMORY_LIMIT_MB omezuje SQL Server, ale jiné procesy uvnitř kontejneru mohou stále využívat neomezenou paměť hostitele.

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

Obě omezení jsou nastavená na 12 GB (--memory 12g = 12 288 MB). Pro režii operačního systému ani pomocné procesy nezbývá žádná rezerva, což může vést k ukončování procesů kvůli nedostatku paměti (OOM).

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) překračuje limit kontejneru (12 GB). Tento scénář vede ke stavům OOM popsaným v části Vyhněte se nastavení limitů paměti vyšších, než je dostupná paměť.

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

Kontejner je omezený na 12 GB (--memory 12g) a SQL Server je nakonfigurované tak, aby používal až 10 GB (MSSQL_MEMORY_LIMIT_MB=10240). Zbývající 2 GB (přibližně 17 procent) poskytuje prostor pro operační systém a další procesy.

Aspekty odkládacího prostoru

Když spustíte SQL Server v kontejneru, povolte odkládací prostor na úrovni hostitelského systému, abyste pomohli chránit operační systém a procesy jiné než SQL Server. Nicméně nakonfigurujte SQL Server tak, aby pracoval v mezích nakonfigurovaných limitů paměti, a při běžném provozu nespoléhejte na odkládací prostor.

  • Postupujte podle pokynů k omezení paměti a ujistěte se, že SQL Server funguje v rámci fyzické paměti nebo příslušného cgroup limitu paměti.

  • Pokud je swap povolený, považujte ho za pojistku pro dočasný nedostatek paměti na hostiteli, nikoli za kapacitu pro trvale běžící úlohy SQL Serveru.

Important

Výkon serveru SQL Server se může výrazně snížit, pokud nedostatek paměti způsobí stránkování. Správné nastavení velikosti paměti je primárním mechanismem, který brání selháním souvisejícím s pamětí.