Najlepsze rozwiązania dotyczące wydajności i wytyczne dotyczące konfiguracji programu SQL Server w systemie Linux

Dotyczy:Program SQL Server w systemie Linux

Ten artykuł zawiera najlepsze rozwiązania i zalecenia dotyczące maksymalizacji wydajności aplikacji baz danych łączących się z programem SQL Server w systemie Linux. Te zalecenia dotyczą uruchamiania na platformie Linux. Wszystkie normalne zalecenia dotyczące programu SQL Server, takie jak projektowanie indeksów, nadal mają zastosowanie.

Poniższe wytyczne zawierają zalecenia dotyczące konfigurowania zarówno programu SQL Server, jak i systemu operacyjnego Linux. Rozważ użycie tych ustawień konfiguracji, aby uzyskać najlepszą wydajność instalacji programu SQL Server.

• zalecenie dotyczące konfiguracji usługi Storage
• Ustawienia jądra i CPU do wysokiej wydajności
• Konfiguracja programu SQL Server

Zalecenie dotyczące konfiguracji magazynu

Podsystem przechowywania danych, dzienników transakcji i innych powiązanych plików (takich jak pliki punktu kontrolnego dla OLTP w pamięci) powinien być w stanie bezproblemowo zarządzać zarówno średnim, jak i szczytowym obciążeniem.

Użyj podsystemu przechowywania z odpowiednimi IOPS, przepustowością i nadmiarowością.

W środowiskach lokalnych dostawca pamięci masowej zwykle obsługuje odpowiednią konfigurację sprzętowej macierzy RAID z rozstrzeleniem na wielu dyskach w celu zapewnienia odpowiednich operacji we/wy na sekundę, przepływności i nadmiarowości. Jednak ta obsługa może się różnić u różnych dostawców pamięci masowej i różnych ofertach pamięci masowej z różnymi architekturami.

W przypadku programu SQL Server w systemie Linux wdrożonego na maszynach wirtualnych platformy Azure rozważ użycie programowej macierzy RAID, aby zapewnić odpowiednie wymagania dotyczące liczby operacji we/wy na sekundę i przepływności. Podczas konfigurowania programu SQL Server na maszynach wirtualnych platformy Azure o podobnych wymaganiach dotyczących przechowywania, zobacz Konfigurowanie magazynu dla programu SQL Server na maszynach wirtualnych platformy Azure.

W poniższym przykładzie pokazano, jak utworzyć programową macierz RAID w systemie Linux na maszynie wirtualnej platformy Azure. Należy pamiętać, że należy użyć odpowiedniej liczby dysków danych dla wymaganej przepustowości i liczby operacji we/wy na sekundę dla woluminów na podstawie danych, dziennika transakcji i wymagań dotyczących operacji we/wy zgodnie z wymogami tempdb. W poniższym przykładzie do maszyny wirtualnej dołączono osiem dysków danych; cztery do hostowania plików danych, dwa dla dzienników transakcji i dwa dla tempdb obciążenia.

Aby zlokalizować urządzenia (na przykład /dev/sdc) na potrzeby tworzenia raid, użyj polecenia lsblk.

# 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

Zalecenia dotyczące partycjonowania i konfiguracji dysku

W przypadku programu SQL Server użyj konfiguracji RAID. Wdrożona jednostka paska systemu plików (sunit) oraz szerokość paska są zgodne z geometrią RAID. Na przykład w poniższym przykładzie przedstawiono konfigurację opartą na systemie XFS dla woluminu dziennika.

# 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

Tablica dzienników jest sześciodyskową macierzą RAID-10 z paskiem o szerokości 64 KB. Jak widać:

• W przypadku sunit=16 blks, 16 * 4096 rozmiar bloku = 64 KB, pasuje do rozmiaru paska.
• Dla swidth=48 blks, swidth / sunit = 3, co jest liczbą dysków danych w tablicy, nie licząc dysków parzystości.

Zalecana konfiguracja systemu plików

Program SQL Server obsługuje systemy plików ext4 i XFS do hostowania bazy danych, dzienników transakcji i innych plików, takich jak pliki punktu kontrolnego dla olTP w pamięci w programie SQL Server. System plików XFS służy do hostowania plików dziennika transakcji i danych programu SQL Server.

Sformatuj wolumin za pomocą systemu plików XFS:

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

System plików XFS można skonfigurować tak, aby nie uwzględniał wielkości liter podczas tworzenia i formatowania woluminu XFS. Ta konfiguracja nie jest często używana w ekosystemie systemu Linux, ale może być używana ze względów zgodności.

Możesz na przykład uruchomić następujące polecenie. Użyj -n version=ci polecenia , aby skonfigurować system plików XFS tak, aby był niewrażliwy na wielkość liter.

mkfs.xfs /dev/md0 -f -n version=ci -L datavolume

Zalecenie dotyczące trwałego systemu plików pamięci

W przypadku konfiguracji systemu plików na urządzeniach pamięci trwałej ustaw alokację bloku dla bazowego systemu plików na 2 MB. Aby uzyskać więcej informacji, zobacz Zagadnienia techniczne.

Ograniczenie otwierania pliku

Środowisko produkcyjne może wymagać większej liczby połączeń niż domyślny limit otwartych plików 1024. Można ustawić miękkie i twarde limity na 1048 576. Na przykład w RHELzmodyfikuj plik /etc/security/limits.d/99-mssql-server.conf, aby mieć następujące wartości:

mssql - nofile 1048576

Notatka

To ustawienie nie ma zastosowania do usług programu SQL Server uruchomionych przez systemd. Aby uzyskać więcej informacji, zobacz Jak ustawić limity dla usług w RHEL i systemd.

Wyłącz ostatni dostęp do daty i godziny w systemach plików dla danych i plików dziennika programu SQL Server

Aby upewnić się, że dyski dołączone do systemu zostaną automatycznie ponownie zamontowane po restarcie, dodaj je do pliku /etc/fstab. Użyj identyfikatora UUID (uniwersalny unikatowy identyfikator) w /etc/fstab, aby odwoływać się do dysku, a nie tylko nazwy urządzenia (na przykład /dev/sdc1).

Użyj atrybutu noatime z dowolnym systemem plików, który przechowuje dane i pliki dziennika programu SQL Server. Zapoznaj się z dokumentacją systemu Linux, aby dowiedzieć się, jak ustawić ten atrybut. W poniższym przykładzie pokazano, jak włączyć noatime opcję dla woluminu zainstalowanego na maszynie wirtualnej platformy Azure.

Wpis punktu montowania w /etc/fstab:

UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" /data1 xfs rw,attr2,noatime 0 0

W poprzednim przykładzie identyfikator UUID reprezentuje urządzenie, które można znaleźć za pomocą blkid polecenia.

Możliwości podsystemu we/wy programu SQL Server i wymuszonych jednostkowych dostępów (FUA)

Niektóre wersje obsługiwanych dystrybucji systemu Linux zapewniają obsługę funkcji podsystemu we/wy FUA, która zapewnia trwałość danych. Program SQL Server używa funkcji FUA, aby zapewnić wysoce wydajne i niezawodne operacje we/wy dla obciążeń programu SQL Server. Aby uzyskać więcej informacji na temat obsługi FUA przez dystrybucję systemu Linux i jej wpływu na SQL Server, zobacz SQL Server na Linuksie: Forced Unit Access (FUA) Internals.

Systemy SUSE Linux Enterprise Server 12 SP5, Red Hat Enterprise Linux 8.0 i Ubuntu 18.04 wprowadziły obsługę funkcji FUA w podsystemie we/wy. Jeśli używasz programu SQL Server 2017 (14.x) CU 6 i nowszych wersji, należy użyć następującej konfiguracji w celu zapewnienia wysokiej wydajności i wydajnej implementacji I/O z użyciem FUA w SQL Server.

Użyj tej zalecanej konfiguracji, jeśli zostaną spełnione następujące warunki.

• SQL Server 2017 (14.x) CU 6 i nowsze wersje

• Dystrybucja i wersja systemu Linux, która obsługuje funkcje FUA (począwszy od systemu Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 lub Ubuntu 18.04)

• System plików XFS dla magazynu SQL Server na jądrze systemu Linux w wersji 4.18 lub nowszej.

• ext4 system plików do przechowywania programu SQL Server na jądrze systemu Linux w wersji 5.6 lub nowszej.

  Notatka

  Należy użyć systemu plików XFS do hostowania plików dziennika danych i transakcji programu SQL Server, gdy wersja jądra systemu Linux jest niższa niż 5.6. Począwszy od jądra w wersji 5.6, można wybrać między XFS i ext4 na podstawie określonych wymagań.

• Podsystem magazynowania i/lub sprzęt, który obsługuje i jest skonfigurowany do obsługi funkcji FUA

Zalecana konfiguracja:

1. Włącz flagę śledzenia 3979 jako parametr uruchamiania.

2. Użyj mssql-conf, aby skonfigurować control.writethrough = 1 i control.alternatewritethrough = 0.

W przypadku prawie wszystkich innych konfiguracji, które nie spełniają poprzednich warunków, zalecana konfiguracja jest następująca:

1. Włącz flagę śledzenia 3982 jako parametr startowy (domyślny dla programu SQL Server w ekosystemie systemu Linux) i upewnij się, że flaga śledzenia 3979 nie jest włączona jako parametr uruchamiania.

2. Użyj mssql-conf, aby skonfigurować control.writethrough = 1 i control.alternatewritethrough = 1.

Obsługa fua dla kontenerów programu SQL Server wdrożonych na platformie Kubernetes

1. Program SQL Server musi używać utrwalonego zainstalowanego magazynu, a nie overlayfs.

2. Pamięć masowa musi używać systemów plików XFS lub ext4 i powinna obsługiwać FUA (ext4 nie obsługuje FUA w jądrze systemu Linux wcześniejszym niż wersja 5.6). Przed włączeniem tego ustawienia należy współpracować z dostawcą dystrybucji systemu Linux oraz dostawcą systemu przechowywania, aby upewnić się, że system operacyjny i system przechowywania obsługują opcje FUA. Na platformie Kubernetes można wykonać zapytanie dotyczące typu systemu plików przy użyciu następującego polecenia, gdzie <pvc-name> jest twoim PersistentVolumeClaim:

   kubectl describe pv <pvc-name>
   

   W danych wyjściowych wyszukaj fstype ustawioną na XFS.

3. Węzeł roboczy hostujący zasobniki programu SQL Server powinien używać dystrybucji i wersji systemu Linux obsługującej funkcje FUA (począwszy od systemu Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 lub Ubuntu 18.04).

Jeśli powyższe warunki zostaną spełnione, możesz użyć następujących zalecanych ustawień FUA.

1. Włącz flagę śledzenia 3979 jako parametr uruchamiania.

2. Użyj mssql-conf, aby skonfigurować control.writethrough = 1 i control.alternatewritethrough = 0.

Ustawienia jądra i procesora CPU w celu zapewnienia wysokiej wydajności

W poniższej sekcji opisano zalecane ustawienia systemu operacyjnego Linux związane z wysoką wydajnością i przepływnością instalacji programu SQL Server. Aby skonfigurować te ustawienia, zapoznaj się z dokumentacją dystrybucji systemu Linux. Można użyć TuneD zgodnie z opisem, aby skonfigurować wiele procesorów oraz konfiguracje jądra, opisane w następnej sekcji.

Użyj TuneD do konfiguracji ustawień jądra

W przypadku użytkowników systemu Red Hat Enterprise Linux (RHEL) profil TuneD wydajności przepustowości automatycznie konfiguruje niektóre ustawienia jądra i procesora (z wyjątkiem stanów C). Począwszy od wersji RHEL 8.0, profil TuneD o nazwie mssql został opracowany wspólnie z firmą Red Hat i oferuje bardziej precyzyjne strojenia wydajności związane z systemem Linux dla obciążeń serwera SQL Server. Ten profil zawiera profil wydajności RHEL, a jego definicje przedstawiamy w tym artykule do porównania z innymi dystrybucjami systemu Linux oraz z wydaniami RHEL bez tego profilu.

W przypadku systemów SUSE Linux Enterprise Server 12 SP5, Ubuntu 18.04 i Red Hat Enterprise Linux 7.x można ręcznie zainstalować tuned pakiet. Użyj go do utworzenia i skonfigurowania mssql profilu zgodnie z opisem w poniższej sekcji.

Proponowane ustawienia dla systemu Linux przy użyciu profilu TuneD mssql

W poniższym przykładzie przedstawiono konfigurację TuneD dla programu SQL Server w systemie 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

Jeśli używasz dystrybucji systemu Linux z wersjami jądra większymi niż 4.18, dodaj komentarz do poniższych opcji, jak pokazano; W przeciwnym razie usuń komentarz z poniższych opcji, jeśli używasz dystrybucji z wersjami jądra starszymi niż 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

Aby włączyć ten profil TuneD, zapisz te definicje w pliku tuned.conf w folderze /usr/lib/tuned/mssql i włącz profil przy użyciu następujących poleceń:

chmod +x /usr/lib/tuned/mssql/tuned.conf
tuned-adm profile mssql

Sprawdź, czy profil jest aktywny, za pomocą następującego polecenia:

tuned-adm active

Lub:

tuned-adm list

Zalecenie dotyczące ustawień procesora CPU

Poniższa tabela zawiera zalecenia dotyczące ustawień procesora CPU:

Ustawienie	Wartość	Więcej informacji
Zarządca częstotliwości CPU	wydajność	Zobacz polecenie cpupower
Uprzedzenie wydajności energetycznej	wydajność	Zobacz polecenie x86_energy_perf_policy
min_perf_pct	100	Zapoznaj się z dokumentacją dotyczącą Intel p-state
Stany C	Tylko C1	Zapoznaj się z dokumentacją systemową dotyczącą Linuksa lub innego systemu, aby upewnić się, że C-States są ustawione tylko na C1

Jeśli używasz usługi TuneD zgodnie z opisem, automatycznie konfiguruje on zarządcę częstotliwości procesora, ENERGY_PERF_BIAS i min_perf_pct ustawienia. Używa profilu przepustowości jako podstawy dla profilu mssql. Należy ręcznie skonfigurować parametr C-States zgodnie z dokumentacją dostarczoną przez system Linux lub dystrybutora systemu.

Zalecenia dotyczące ustawień dysku

Poniższa tabela zawiera zalecenia dotyczące ustawień dysku:

Ustawienie	Wartość	Więcej informacji
Dysk readahead	4096	Zobacz polecenie blockdev
ustawienia sysctl	kernel.sched_min_granularity_ns = 15000000 kernel.sched_wakeup_granularity_ns = 2000000 vm.dirty_ratio = 80 vm.dirty_background_ratio = 3 vm.swappiness = 1	Zobacz polecenie sysctl

Opis

• vm.swappiness: Ten parametr steruje względną wagą nadaną wymianie pamięci procesu uruchomieniowego w porównaniu z pamięcią podręczną systemu plików. Wartość domyślna tego parametru to 60, co wskazuje na zamianę stron pamięci procesu uruchomieniowego w porównaniu z usuwaniem stron pamięci podręcznej systemu plików w stosunku 60:140. Ustawienie wartości na 1 oznacza silną preferencję utrzymania pamięci procesu środowiska uruchomieniowego w pamięci fizycznej kosztem pamięci podręcznej systemu plików. Ponieważ SQL Server używa puli bufora jako pamięci podręcznej strony danych i zdecydowanie preferuje bezpośrednie zapisywanie do sprzętu fizycznego z pominięciem pamięci podręcznej systemu plików dla zapewnienia niezawodnego odzyskiwania, agresywne ustawienie swappiness może być korzystne dla wysokowydajnego i dedykowanego SQL Server.

  Dodatkowe informacje można znaleźć na stronie Documentation for /proc/sys/vm/ - #swappiness

• vm.dirty_*: dostęp do zapisu plików programu SQL Server odbywa się bez pamięci podręcznej, spełniając wymagania dotyczące integralności danych. Te parametry umożliwiają wydajność asynchronicznego zapisu i obniżają efekt operacji we/wy pamięci masowej zapisów buforowanych przez system Linux, umożliwiając wystarczająco duże buforowanie przy jednoczesnym kontrolowaniu opróżniania.

• kernel.sched_*: Te wartości parametrów reprezentują bieżące zalecenie dotyczące dostosowywania algorytmu całkowicie sprawiedliwego planowania (CFS) w jądrze systemu Linux. Zwiększają przepustowość wywołań we/wy sieci i pamięci masowej w kontekście wywłaszczania i wznawiania wątków międzyprocesowych.

Za pomocą profilu TuneD konfigurujesz ustawienia mssql, vm.swappiness i vm.dirty_*. Należy ręcznie skonfigurować ustawienie dysku readahead przy użyciu blockdev polecenia dla każdego urządzenia.

Ustawienie automatycznego równoważenia NUMA w jądrze dla wielowęzłowych systemów NUMA

Jeśli zainstalujesz program SQL Server w systemie NUMA z wieloma węzłami, następujące kernel.numa_balancing ustawienie jądra jest domyślnie włączone. Aby umożliwić SQL Server działanie z maksymalną wydajnością w systemie NUMA z wieloma węzłami, wyłącz automatyczne równoważenie NUMA:

sysctl -w kernel.numa_balancing=0

Za pomocą profilu mssql TuneD konfiguruje opcję kernel.numa_balancing.

Ustawienia jądra dla wirtualnej przestrzeni adresowej

Ustawienie domyślne vm.max_map_count (czyli 65536) może nie być wystarczająco wysokie w przypadku instalacji programu SQL Server. Z tego powodu, dla wdrażania SQL Server, zmień wartość vm.max_map_count na co najmniej 262144, a następnie zapoznaj się z sekcją dotyczącą proponowanych ustawień Linux przy użyciu profilu TuneD mssql, aby dokonać dalszego dostrajania tych parametrów jądra. Maksymalna wartość vm.max_map_count jest 2147483647.

sysctl -w vm.max_map_count=1600000

Za pomocą profilu mssql TuneD konfiguruje opcję vm.max_map_count.

Pozostaw włączone przezroczyste ogromne strony (THP)

Większość instalacji systemu Linux ma tę opcję domyślnie włączoną. Aby zapewnić najbardziej spójne doświadczenie wydajnościowe, pozostaw tę opcję konfiguracji włączoną. Jeśli jednak w wdrożeniach programu SQL Server występuje duże obciążenie stronicowania pamięci z wieloma wystąpieniami lub wykonywanie programu SQL Server z innymi aplikacjami wymagającymi pamięci na serwerze, przetestuj wydajność aplikacji po wykonaniu następującego polecenia:

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

Lub zmodyfikuj profil mssql TuneD za pomocą wiersza:

vm.transparent_hugepages=madvise

Upewnij się, że mssql profil jest aktywny po modyfikacji:

tuned-adm off
tuned-adm profile mssql

Za pomocą profilu mssql TuneD konfiguruje opcję transparent_hugepage.

Zalecenia dotyczące ustawień sieci

Oprócz zaleceń dotyczących pamięci i CPU masz również zalecenia dotyczące sieci. Poniższe zalecenia są podane do wglądu. Nie wszystkie ustawienia w poniższych przykładach są dostępne we wszystkich kartach sieciowych. Skonsultuj się z dostawcą interfejsów sieciowych, aby zasięgnąć porady w sprawie każdej z opcji. Przetestuj i skonfiguruj je w środowiskach deweloperskich przed zastosowaniem ich w środowiskach produkcyjnych. Poniższe opcje zostały wyjaśnione przy użyciu przykładów, a używane polecenia są specyficzne dla typu karty sieciowej i dostawcy.

1. Konfigurowanie rozmiaru buforu portów sieciowych. W tym przykładzie karta sieciowa nosi nazwę eth0, która jest kartą sieciową opartą na intelu. W przypadku karty sieciowej firmy Intel zalecany rozmiar buforu to 4 KB (4096). Sprawdź wstępne wartości maksymalne, a następnie skonfiguruj je przy użyciu następującego przykładu:

   Sprawdź wstępnie ustawione wartości maksymalne za pomocą następującego polecenia. Zastąp eth0 nazwą karty sieciowej:

   ethtool -g eth0
   

   Ustaw rozmiar buforu rx (odbieranie) i tx (transmisji) na 4 KB:

   ethtool -G eth0 rx 4096 tx 4096
   

   Sprawdź, czy wartość jest prawidłowo skonfigurowana:

   ethtool -g eth0
   

2. Włącz jumbo frames. Przed włączeniem ramek jumbo sprawdź, czy wszystkie przełączniki sieciowe, routery i wszystkie inne istotne elementy w ścieżce pakietów sieciowych między klientami i programem SQL Server obsługują ramki jumbo. Tylko wtedy włączenie ramek jumbo może poprawić wydajność. Po włączeniu ramek jumbo połącz się z programem SQL Server i zmień rozmiar pakietu sieciowego na 8060 przy użyciu polecenia sp_configure, jak pokazano w poniższym przykładzie:

   # 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. Domyślnie ustaw port na potrzeby adaptacyjnego łączenia RX/TX IRQ, co oznacza, że dostarczanie przerwań jest dostosowywane w celu zwiększenia opóźnienia, gdy szybkość pakietów jest niska i poprawia przepływność, gdy szybkość pakietów jest wysoka. To ustawienie może nie być dostępne w całej infrastrukturze sieci, dlatego przejrzyj istniejącą infrastrukturę sieci i upewnij się, że to ustawienie jest obsługiwane. Przykład dotyczy karty sieciowej o nazwie eth0, która jest kartą sieciową opartą na intelu:

   1. Ustaw port na potrzeby adaptacyjnego łączenia RX/TX IRQ:

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

   2. Potwierdź ustawienie:

      ethtool -c eth0
      

   Notatka

   Aby zapewnić przewidywalne działanie w środowiskach o wysokiej wydajności, takich jak środowiska testów porównawczych, wyłącz adaptacyjne łączenie RX/TX IRQ, a następnie w szczególności ustaw łączenie przerwań RX/TX. Zobacz przykładowe polecenia, aby wyłączyć koalescencję IRQ RX/TX, a następnie precyzyjnie ustawić wartości.

   Wyłącz adaptacyjną koalescencję IRQ RX/TX:

   ethtool -C eth0 adaptive-rx off
   ethtool -C eth0 adaptive-tx off
   

   Potwierdź zmianę:

   ethtool -c eth0
   

   Ustaw parametry rx-usecs i irq. rx-usecs Określa liczbę mikrosekund po odebraniu co najmniej jednego pakietu przed wygenerowaniem przerwania. Parametr irq określa odpowiednie opóźnienia w aktualizowaniu stanu, gdy przerwanie jest wyłączone. W przypadku bazowych kart sieciowych firmy Intel można użyć następujących ustawień:

   ethtool -C eth0 rx-usecs 100 tx-frames-irq 512
   

   Potwierdź zmianę:

   ethtool -c eth0
   

4. Włącz skalowanie po stronie odbierającej (RSS) i domyślnie połącz RX i TX kolejek RSS. Podczas pracy z pomocą techniczną firmy Microsoft istnieją konkretne scenariusze, w których wyłączenie funkcji RSS zwiększa również wydajność. Przetestuj to ustawienie w środowiskach testowych przed zastosowaniem go w środowiskach produkcyjnych. Poniższy przykład dotyczy kart sieciowych firmy Intel.

   Pobierz wstępnie ustawione wartości maksymalne:

   ethtool -l eth0
   

   Połącz kolejki z wartością zgłoszoną jako wstępnie ustawiona wartość maksymalna "Połączono". W tym przykładzie wartość jest ustawiona na wartość 8:

   ethtool -L eth0 combined 8
   

   Sprawdź ustawienie:

   ethtool -l eth0
   

5. Praca z koligacją IRQ portu karty sieciowej. Aby osiągnąć oczekiwaną wydajność przez dostosowanie przydziału IRQ, należy wziąć pod uwagę kilka ważnych parametrów, takich jak obsługa topologii serwera przez Linux, stos sterowników kart sieciowych, ustawienia domyślne i irqbalance ustawienie. Optymalizacje ustawień koligacji IRQ portów karty sieciowej są wykonywane z uwzględnieniem topologii serwera, wyłączając irqbalance, i używając ustawień specyficznych dla dostawcy karty sieciowej.

   Poniższy przykład infrastruktury sieciowej specyficznej dla systemu Mellanox pomaga wyjaśnić konfigurację. Aby uzyskać więcej informacji i pobrać narzędzia Mellanox mlnx, zobacz narzędzia do dostrajania wydajności dla kart sieciowych Mellanox. Polecenia zmieniają się w zależności od środowiska. Aby uzyskać dalsze wskazówki, skontaktuj się z dostawcą karty sieciowej.

   Wyłącz irqbalancelub pobierz migawkę ustawień środowiska IRQ i wymuś zamknięcie demona:

   systemctl disable irqbalance.service
   

   Lub:

   irqbalance --oneshot
   

   Upewnij się, że common_irq_affinity.sh jest wykonywalny:

   chmod +x common_irq_affinity.sh
   

   Wyświetlanie koligacji IRQ dla portu karty sieciowej Mellanox (na przykład eth0):

   ./show_irq_affinity.sh eth0
   

   Zoptymalizuj wydajność przepustowości za pomocą narzędzia Mellanox:

   ./mlnx_tune -p HIGH_THROUGHPUT
   

   Ustaw koligację sprzętową na węzeł NUMA, który fizycznie hostuje kartę sieciową i jej port.

   ./set_irq_affinity_bynode.sh `\cat /sys/class/net/eth0/device/numa_node` eth0
   

   Sprawdź koligację IRQ:

   ./show_irq_affinity.sh eth0
   

   Dodawanie optymalizacji łączenia środowiska IRQ

   ethtool -C eth0 adaptive-rx off
   ethtool -C eth0 adaptive-tx off
   ethtool -C eth0  rx-usecs 750 tx-frames-irq 2048
   

   Sprawdź ustawienia:

   ethtool -c eth0
   

6. Po wprowadzeniu powyższych zmian sprawdź szybkość karty sieciowej, aby upewnić się, że spełnia ona oczekiwania, używając następującego polecenia:

   ethtool eth0 | grep -i Speed
   

Zaawansowana konfiguracja jądra i systemu operacyjnego

• Aby uzyskać najlepszą wydajność operacji we/wy magazynu, należy użyć planowania wielokolejkowego systemu Linux dla urządzeń blokowych. Ta metoda planowania umożliwia wydajne skalowanie warstw blokowych przy użyciu szybkich dysków półprzewodnikowych (SSD) i systemów wielordzeniowych. Zapoznaj się z dokumentacją, aby sprawdzić, czy dystrybucja systemu Linux domyślnie ją włącza. W większości innych przypadków można uruchomić jądro za pomocą scsi_mod.use_blk_mq=y polecenia , aby je włączyć. Dokumentacja dystrybucji systemu Linux może zawierać dalsze wskazówki dotyczące tego ustawienia. To ustawienie jest zgodne z nadrzędnym jądrem systemu Linux.

• Ponieważ wielościeżkowe operacje we/wy są często używane w przypadku wdrożeń programu SQL Server, należy skonfigurować obiekt docelowy wielościeżkowego mapowania urządzenia (DM) pod kątem korzystania z blk-mq infrastruktury, włączając opcję rozruchu dm_mod.use_blk_mq=y jądra. Wartość domyślna to n (wyłączone). To ustawienie zmniejsza obciążenie blokowania w warstwie DM, gdy bazowe urządzenia SCSI używają blk-mq. Aby uzyskać więcej informacji na temat konfigurowania wielościeżkowego we/wy, zapoznaj się z dokumentacją dystrybucji systemu Linux.

Konfigurowanie pliku swapfile

Upewnij się, że masz prawidłowo skonfigurowany plik swapfile, aby uniknąć problemów z brakiem pamięci. Zapoznaj się z dokumentacją systemu Linux, aby dowiedzieć się, jak utworzyć i prawidłowo określić rozmiar pliku swap.

Maszyny wirtualne i pamięć dynamiczna

Jeśli używasz programu SQL Server w systemie Linux na maszynie wirtualnej, upewnij się, że wybrano opcje, aby naprawić ilość pamięci zarezerwowanej dla maszyny wirtualnej. Nie używaj funkcji takich jak pamięć dynamiczna Hyper-V.

Konfiguracja programu SQL Server

Wykonaj następujące zadania konfiguracyjne po zainstalowaniu programu SQL Server w systemie Linux, aby uzyskać najlepszą wydajność aplikacji.

Najlepsze rozwiązania

Używanie KOLIGACJI PROCESU dla węzłów i/lub procesorów CPU

Służy ALTER SERVER CONFIGURATION do ustawiania PROCESS AFFINITY dla wszystkich węzłów i procesorów, z których korzystasz w programie SQL Server (co zwykle dotyczy wszystkich węzłów i procesorów) w systemie operacyjnym Linux. Koligacja procesora pomaga zachować wydajne zachowanie systemu Linux i planowania SQL. Użycie opcji NUMANODE jest najprostszą metodą. Użyj PROCESS AFFINITY, nawet jeśli masz tylko jeden węzeł NUMA na komputerze. Aby uzyskać więcej informacji na temat ustawiania PROCESS AFFINITY, zobacz artykuł ALTER SERVER CONFIGURATION.

Konfigurowanie wielu plików danych tempdb

Ponieważ instalacja programu SQL Server w systemie Linux nie oferuje opcji skonfigurowania wielu plików tempdb, zalecamy utworzenie wielu plików tempdb danych po instalacji. Aby uzyskać więcej informacji, zobacz wskazówki zawarte w artykule Zalecenia dotyczące zmniejszenia konfliktów przydziału w bazie danych tempdb programu SQL Server.

Konfiguracja zaawansowana

Poniższe zalecenia to opcjonalne ustawienia konfiguracji, które można wybrać po zainstalowaniu programu SQL Server w systemie Linux. Te opcje są oparte na wymaganiach dotyczących obciążenia i konfiguracji systemu operacyjnego Linux.

Ustawianie limitu pamięci za pomocą narzędzia mssql-conf

Aby zapewnić wystarczającą ilość wolnej pamięci fizycznej dla systemu operacyjnego Linux, proces programu SQL Server domyślnie używa tylko 80% fizycznej pamięci RAM. W przypadku niektórych systemów z dużą ilością fizycznej pamięci RAM 20% może być znaczną liczbą.

Na przykład w systemie z 1 TB pamięci RAM domyślne ustawienie pozostawi 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ć za pomocą narzędzia mssql-conf . Aby uzyskać więcej informacji, zobacz ustawienie memory.memorylimitmb , które kontroluje pamięć widoczną dla programu SQL Server (w jednostkach MB).

Notatka

Limit pamięci można również skonfigurować przy użyciu zmiennej środowiskowej MSSQL_MEMORY_LIMIT_MB . Ta metoda jest często używana podczas wdrażania kontenerów lub automatyzowania wdrożeń opartych na kontenerach lub pakietach programu SQL Server. Zmienna MSSQL_MEMORY_LIMIT_MB środowiskowa ma pierwszeństwo przed ustawieniem memory.memorylimitmb .

Podczas zmieniania tego ustawienia należy zachować ostrożność, aby nie ustawiać tej wartości zbyt wysoko. Jeśli nie pozostawisz wystarczającej ilości pamięci, możesz napotkać problemy z systemem operacyjnym Linux i innymi aplikacjami systemu Linux.

Konfigurowanie limitów pamięci za pomocą grupy kontrolnej (cgroup) w wersji 2

Począwszy od programu SQL Server 2025 (17.x) i programu SQL Server 2022 (16.x) CU 20, program SQL Server wykrywa i honoruje ograniczenia grupy kontrolnej (cgroup) w wersji 2, zwiększając stabilność wydajności i izolację zasobów w środowiskach Docker, Kubernetes i OpenShift. Grupy kontrolek umożliwiają precyzyjną kontrolę w jądrze systemu Linux nad zasobami systemowymi, takimi jak procesor CPU i pamięć.

Dzięki obsłudze cgroup w wersji 2 program SQL Server ogranicza błędy braku pamięci (OOM) zaobserwowane wcześniej we wdrożeniach konteneryzowanych, szczególnie w klastrach Kubernetes (na przykład AKS w wersji 1.25 lub nowszej), gdzie limity pamięci zdefiniowane w specyfikacji kontenera nie były wymuszane.

Sprawdź wersję cgroup

stat -fc %T /sys/fs/cgroup

Wyniki są następujące:

Wynik	Opis
cgroup2fs	Używasz cgroup v2
cgroup	Używasz cgroup w wersji 1

Przełącz na cgroup w wersji 2

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 wiersz do konfiguracji GRUB:

systemd.unified_cgroup_hierarchy=1

Następnie uruchom następujące polecenie, aby zaktualizować program GRUB:

sudo update-grub

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

• Szybkie rozpoczęcie: wdrażanie kontenera z systemem Linux programu SQL Server na platformie Kubernetes przy użyciu wykresów Helm
• Dokumentacja jądra Linux cgroup v2
• Grupa kontrolna w wersji 2

Wskazówki dotyczące ustawiania limitów pamięci

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

• 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 memorylimitmb niżej niż zarówno pamięć systemu hosta, jak i limit grupy cgroup (jeśli istnieje), aby pozostawała wystarczająca ilość wolnej pamięci fizycznej dla systemu operacyjnego Linux. Jeśli nie ustawisz jawnie memorylimitmb, program SQL Server używa 80% mniejszej z wartości między całkowitą pamięcią systemu a limitem cgroup (jeśli istnieje).

• 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, takich jak SQLPAL, SQL Server Agent, LibOS, PolyBase, Full-Text Search i dowolny inny proces załadowany w programie SQL Server w systemie Linux.

Powiązana zawartość

• Przewodnik dotyczący funkcji wydajności programu SQL Server w systemie Linux
• Co to jest program SQL Server w systemie Linux?