Najlepsze praktyki dotyczące wydajności: pamięć programu SQL Server w systemie Linux

Dotyczy:Program SQL Server w systemie Linux

W tym artykule omówiono konfigurację pamięci dla programu SQL Server w systemie Linux, w tym limity pamięci mssql-conf, ustawienia grup sterowania (cgroup), przykłady dotyczące pamięci kontenerów Docker oraz zagadnienia związane z przestrzenią wymiany.

Ustawianie limitu pamięci przy użyciu biblioteki mssql-conf

Aby zapewnić wystarczającą ilość wolnej pamięci fizycznej dla systemu operacyjnego Linux, proces SQL Server domyślnie używa tylko 80 procent fizycznej pamięci RAM. W przypadku niektórych systemów z dużą ilością fizycznej pamięci RAM 20 procent może być znaczną liczbą. Na przykład w systemie z 1 TB pamięci RAM domyślne ustawienie pozostawia około 200 GB nieużywanej pamięci RAM. W takiej sytuacji może być konieczne skonfigurowanie limitu pamięci na wyższą wartość.

Tę wartość można dostosować przy użyciu mssql-conf narzędzia lub zmiennej środowiskowej MSSQL_MEMORY_LIMIT_MB . Aby uzyskać więcej informacji, zobacz ustawienie memory.memorylimitmb , które kontroluje pamięć widoczną dla programu SQL Server (w jednostkach MB). Aby uzyskać szczegółowe wskazówki dotyczące określania rozmiaru, zobacz Wytyczne dotyczące ustawiania limitów pamięci w systemie Linux i w kontenerach.

Obsługa grupy kontrolnej (cgroup) w wersji 2

SQL Server wykrywa i honoruje ograniczenia grupy kontrolnej (cgroup) w wersji 2, rozpoczynając od SQL Server 2025 (17.x) oraz SQL Server 2022 (16.x) zaktualizowanego do wersji Cumulative Update (CU) 20. Te ograniczenia zapewniają szczegółową kontrolę w jądrze systemu Linux za pośrednictwem zasobów procesora i pamięci oraz usprawniają izolację zasobów w środowiskach Docker, Kubernetes i OpenShift.

W poprzednich wersjach wdrożenia konteneryzowane na klastrach Kubernetes (na przykład Azure Kubernetes Service 1.25+) mogły wystąpić błędy braku pamięci (OOM), ponieważ SQL Server nie wymuszał limitów pamięci zdefiniowanych w specyfikacjach kontenera. Obsługa cgroup w wersji 2 rozwiązuje ten problem.

Sprawdź wersję cgroup

stat -fc %T /sys/fs/cgroup

Wyniki są następujące:

Przełącz na cgroup v2

Najprostszą ścieżką jest wybranie dystrybucji, która od razu wspiera cgroup v2.

Jeśli musisz przełączyć się ręcznie, dodaj następujący parametr do konfiguracji GRUB:

systemd.unified_cgroup_hierarchy=1

Następnie zaktualizuj program GRUB. Na przykład w systemie Ubuntu uruchom polecenie:

sudo update-grub

W systemie Red Hat Enterprise Linux (RHEL) uruchom polecenie:

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

Raportowanie ograniczeń procesora CPU za pomocą cgroup v2

Podczas konfigurowania limitów procesora CPU przy użyciu cgroup v2 SQL Server nie wyświetla skonfigurowanej liczby rdzeni procesora CPU w dzienniku błędów. Zamiast tego nadal informuje o łącznej liczbie CPU hosta.

Aby dostosować planistę SQL Server oraz plany zapytań (na przykład decyzje dotyczące równoległości) do docelowej liczby procesorów zdefiniowanej w cgroup v2, zastosuj następującą konfigurację.

Konfigurowanie koligacji procesora

Jawnie ustaw koligację procesora SQL Server w celu dopasowania do limitu przydziału wykonywania grupy cgroup. W przykładzie poniżej przydział cgroup wynosi cztery CPU na ośmiordzeniowym hoście:

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

Ta konfiguracja gwarantuje, że SQL Server tworzy harmonogramy tylko dla zamierzonej liczby procesorów CPU. Aby uzyskać więcej informacji, zobacz ALTER SERVER CONFIGURATION i Użyj PROCESS AFFINITY dla węzła i/lub procesorów.

Włącz flagę śledzenia 8002 (zalecane)

Włącz flagę śledzenia 8002, aby używać miękkiej koligacji w warstwie SQLPAL.

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

Domyślnie harmonogramy są powiązane z określonymi procesorami zdefiniowanymi w masce koligacji. Zamiast tego flaga śledzenia 8002 umożliwia planerom przechodzenie między procesorami, co zwykle poprawia wydajność, jednocześnie przestrzegając ograniczeń koligacji i cgroup. Aby uzyskać więcej informacji, zobacz DBCC TRACEON — Trace Flags.

Uruchom ponownie SQL Server po włączeniu flagi śledzenia.

Oczekiwane zachowanie

Po ponownym uruchomieniu:

• SQL Server tworzy tylko liczbę harmonogramów zdefiniowanych przez ustawienie koligacji (na przykład cztery harmonogramy).

• Jądro systemu Linux nadal wymusza limit przydziału wykonywania procesora cgroup w wersji 2.

• Decyzje dotyczące optymalizacji zapytań i równoległości są oparte na zamierzonej liczbie procesorów CPU, a nie na łącznej liczbie procesorów CPU hosta.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Szybki start: wdrożenie kontenera SQL Server na Linuxie na platformie Kubernetes przy użyciu Helm Charts
• Grupa kontrolna w wersji 2 (dokumentacja jądra systemu Linux)

Wskazówki dotyczące ustawiania limitów pamięci w systemie Linux i w kontenerach

SQL Server on Linux ma wiele kontrolek pamięci, które działają na różnych poziomach. W poniższej tabeli i diagramie pokazano, jak każdy poziom zawęża dostępną pamięć, od pamięci RAM hosta do puli buforów.

Podczas ustawiania limitów pamięci dla programu SQL Server w systemie Linux należy wziąć pod uwagę następujące wskazówki:

• W przypadku wdrożeń kontenerów użyj polecenia cgroup , aby ograniczyć ogólną ilość pamięci dostępnej dla kontenera. To ustawienie ustanawia górną granicę dla wszystkich procesów wewnątrz kontenera.

• Limit pamięci (ustawiony przez memorylimitmb lub MSSQL_MEMORY_LIMIT_MB zmienną środowiskową) kontroluje całkowitą ilość pamięci, którą SQL Server w systemie Linux może przydzielić we wszystkich swoich składnikach, takich jak pula buforowa, SQLPAL, SQL Server Agent, LibOS, PolyBase, Full-Text Search i dowolny inny proces załadowany w SQL Server w systemie Linux.

• Zmienna MSSQL_MEMORY_LIMIT_MB środowiskowa ma pierwszeństwo przed memorylimitmb zdefiniowaną w pliku mssql.conf.

• memorylimitmb nie może przekroczyć rzeczywistej pamięci fizycznej systemu hosta.

• Ustaw wartość memorylimitmb na poziomie niższym niż pamięć hosta i limit cgroup (jeśli jest ustawiony), aby zapewnić wystarczającą ilość wolnej pamięci fizycznej dla systemu operacyjnego Linux. Jeśli jawnie nie ustawisz wartości memorylimitmb, program SQL Server użyje 80% mniejszej z wartości: całkowitej pamięci systemowej i limitu cgroup (jeśli jest ustawiony).

• Opcja konfiguracji serwera max_server_memory ogranicza tylko rozmiar puli programu SQL Server i nie zarządza ogólnym użyciem pamięci dla programu SQL Server w systemie Linux. Zawsze ustawiaj tę wartość niższą niż memorylimitmb w celu zapewnienia wystarczającej ilości pamięci dla innych składników opisanych w poprzednim punkcie.

Zapas pamięci między programem SQL Server a limitami pamięci kontenera

Gdy uruchamiasz program SQL Server w kontenerze ze skonfigurowanym limitem pamięci (na przykład przy użyciu ustawienia cgroupmemory.max), zachowaj zapas między memory.memorylimitmb a limitem pamięci kontenera. Ten nakład pracy zapewnia obciążenie systemu operacyjnego i procesy pomocnicze wewnątrz kontenera.

• W przypadku większości wdrożeń należy zarezerwować od 10 do 20 procent pamięci kontenera dla systemu operacyjnego i procesów innych niż SQL Server i ustawić memory.memorylimitmb poniżej pozostałej pojemności.

• W przypadku dużych konfiguracji pamięci bufor oparty na procentach może zarezerwować więcej pamięci niż jest to konieczne. Na przykład 10 procent kontenera o rozmiarze 256 GB wynosi około 25 GB, co jest uzasadnione w przypadku obciążeń związanych z systemem operacyjnym. Jednak 10 procent kontenera 512 GB wynosi około 51 GB, co jest prawdopodobnie więcej niż wymaga system operacyjny. W takich przypadkach należy zamiast tego użyć buforu o stałym rozmiarze, odpowiednio dobranego do obciążenia i narzutu systemu operacyjnego, a pozostałą część przydzielić do SQL Server.

• Dostosuj bufor na podstawie właściwości obciążenia, innych usług uruchomionych w kontenerze i konfiguracji hosta.

Unikaj konfigurowania limitów pamięci wyższej niż dostępna pamięć

Nie należy konfigurować memory.memorylimitmb na wartość większą niż dostępna pamięć fizyczna na hoście ani większą niż limit pamięci narzucony przez kontener. Jeśli tak, SQL Server może agresywnie zużywać pamięć, pozostawiając niewystarczającą pojemność systemu operacyjnego i procesów pomocniczych. Ta konfiguracja może spowodować:

• Zwiększona presja na pamięć.
• Zmniejszona stabilność systemu i nieoczekiwane przerwy w działaniu usługi.
• System operacyjny kończący działanie procesu sqlservr z powodu niewystarczającej ilości pamięci (OOM).

Skonfiguruj SQL Server limity pamięci poniżej efektywnej pamięci dostępnej dla hosta lub kontenera i pozostaw odpowiednie miejsce buforu dla systemu operacyjnego i usług środowiska uruchomieniowego.

Przykłady konfiguracji pamięci platformy Docker

Opcja docker run --memory ustawia cgroup limit pamięci dla kontenera. Ten limit to wymuszony przez jądro sztywny limit dla wszystkich procesów w kontenerze. MSSQL_MEMORY_LIMIT_MB (lub memory.memorylimitmb) określa, ile z tej pamięci może używać program SQL Server. Jak opisano w poprzednich wytycznych, zawsze ustawiaj MSSQL_MEMORY_LIMIT_MB niższą niż limit pamięci kontenera, aby pozostawić miejsca pracy dla systemu operacyjnego i procesów pomocniczych.

W poniższych przykładach użyto hosta z 16 GB pamięci RAM. Dostosuj wartości dla środowiska.

Niezalecane: brak limitu pamięci kontenera

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 kontener nie ma limitu cgroup. MSSQL_MEMORY_LIMIT_MBogranicza SQL Server, ale inne procesy wewnątrz kontenera mogą nadal zużywać nieograniczoną pamięć hosta.

Niezalecane: limit pamięci równy limitowi pamięci SQL Server

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

Oba limity są ustawione na 12 GB (--memory 12g = 12 288 MB). Nie ma miejsca na obciążenie systemu operacyjnego lub procesy pomocnicze, co może prowadzić do zabicia OOM.

Niezalecane: limit pamięci SQL Server przekracza limit kontenera

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) przekracza limit kontenera (12 GB). Ten scenariusz prowadzi do warunków OOM opisanych w temacie Unikanie konfigurowania limitów pamięci wyższej niż dostępna pamięć.

Zalecane: limit zasobów kontenera z zapasem dla systemu operacyjnego

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

Kontener jest ograniczony do 12 GB (--memory 12g), a SQL Server jest skonfigurowany do użycia do 10 GB (MSSQL_MEMORY_LIMIT_MB=10240). Pozostałe 2 GB (około 17 procent) zapewnia miejsce pracy dla systemu operacyjnego i innych procesów.

Zagadnienia dotyczące zamiany miejsca

Po uruchomieniu SQL Server w kontenerze włącz miejsce wymiany na poziomie hosta, aby ułatwić ochronę procesów systemu operacyjnego i procesów innych niż SQL Server. Należy jednak skonfigurować SQL Server do działania w ramach skonfigurowanych limitów pamięci i nie polegać na zamianie podczas normalnego działania.

• Postępuj zgodnie z wytycznymi dotyczącymi limitu pamięci, aby upewnić się, że SQL Server działa w pamięci fizycznej lub odpowiednim cgroup limicie pamięci.

• Jeśli pamięć swap jest włączona, traktuj ją jako zabezpieczenie na wypadek przejściowych niedoborów pamięci na hoście, a nie jako dodatkową pamięć dla stałych obciążeń programu SQL Server.

Treści powiązane

• Najlepsze rozwiązania dotyczące wydajności: magazyn, jądro, procesor CPU i sieć dla SQL Server on Linux
• Dynamiczne widoki zarządzania i funkcje związane z systemem Linux (Transact-SQL)
• Przewodnik dotyczący funkcji wydajności programu SQL Server w systemie Linux
• Co to jest program SQL Server w systemie Linux?