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

Artykuł
03/05/2025

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ą.

Zwykle w środowiskach lokalnych dostawca pamięci masowej obsługuje odpowiednią konfigurację sprzętowego RAID z naprzemiennym zapisem na wielu dyskach w celu zapewnienia odpowiednich wartości IOPS, przepustowości oraz nadmiarowości. Może się to jednak różnić między różnymi dostawcami magazynu i różnymi ofertami magazynu w różnych architekturach.

W przypadku programu SQL Server w systemie Linux wdrożonego na maszynach wirtualnych platformy Azure rozważ użycie programowej macierzy RAID w celu zapewnienia osiągnięcia odpowiednich wymagań dotyczących 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ć oprogramowanie RAID w systemie Linux na maszynach wirtualnych 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 platformy Azure dołączono osiem dysków danych; 4 do hostowania plików danych, 2 dla dzienników transakcji i 2 dla obciążenia tempdb.

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 należy użyć konfiguracji RAID. Wdrożona jednostka paska systemu plików (sunit) i szerokość paska powinny być zgodne z geometrią RAID. Na przykład jest to przykład oparty 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 logów to 6-dyskowy RAID-10 z rozmiarem paska 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.

Zalecenie dotyczące konfiguracji systemu plików

Program SQL Server obsługuje systemy plików ext4 i XFS do hostowania bazy danych, dzienników transakcji i dodatkowych plików, takich jak pliki punktu kontrolnego dla olTP w pamięci w programie SQL Server. Firma Microsoft zaleca używanie systemu plików XFS do hostowania plików dziennika danych i transakcji 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

Istnieje możliwość skonfigurowania systemu plików XFS tak, aby nie uwzględniał wielkości liter podczas tworzenia i formatowania woluminu XFS. Nie jest to często używana konfiguracja 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. -n version=ci służy do konfigurowania systemu plików XFS tak, aby nie uwzględniał wielkości 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 alokacja bloku dla bazowego systemu plików powinna mieć wartość 2 MB. Aby uzyskać więcej informacji na temat tego artykułu, zapoznaj się z artykułem 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 poziomie 1 048 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/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 odinstalowane po ponownym uruchomieniu, dodaj je do pliku /etc/fstab. Należy również użyć identyfikatora UUID (uniwersalnego unikatowego identyfikatora) w /etc/fstab, aby odwoływać się do dysku, a nie tylko nazwy urządzenia (np. /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. Poniżej przedstawiono przykład włączania opcji noatime 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 programu SQL Server
Podsystem magazynowania i/lub sprzęt, który obsługuje i jest skonfigurowany do obsługi funkcji FUA

Zalecana konfiguracja:

Włącz flagę śledzenia 3979 jako parametr startowy.
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:

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.
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

Program SQL Server musi używać utrwalonego zainstalowanego magazynu, a nie overlayfs.
Pamięć masowa musi używać systemu plików XFS i powinna obsługiwać FUA. 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.
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.

Włącz flagę śledzenia 3979 jako parametr startowy.
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) TuneD profil wydajności przepływności konfiguruje niektóre ustawienia jądra i procesora CPU automatycznie (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 zainstalować ręcznie pakiet tuned. Może służyć do tworzenia i konfigurowania profilu mssql 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

Użycie TuneD zgodnie z wcześniejszym opisem automatycznie konfiguruje zarządcę częstotliwości procesora, ENERGY_PERF_BIASoraz ustawienia min_perf_pct w sposób odpowiedni, ponieważ profil wydajności przesyłu jest używany jako baza dla profilu mssql. Parametr C-States należy skonfigurować ręcznie 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 środowiska uruchomieniowego w porównaniu do pamięci podręcznej systemu plików. Wartość domyślna dla tego parametru to 60, co wskazuje na zamianę stron pamięci dynamicznej procesów uruchomieniowych w porównaniu do usuwania stron buforów pamięci systemu plików w proporcji 60:140. Ustawienie wartości 1 oznacza silną preferencję utrzymania pamięci procesów środowiska uruchomieniowego w pamięci fizycznej kosztem pamięci podręcznej systemu plików. Ponieważ SQL Server używa puli buforowej jako pamięci podręcznej stron danych i preferuje bezpośrednie zapisywanie do sprzętu fizycznego z pominięciem pamięci podręcznej systemu plików dla niezawodnego odzyskiwania, agresywna konfiguracja wymiany może być korzystna w kontekście wysokowydajnych i dedykowanych serwerów 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 w celu poprawy przepustowości wywołań sieciowych i magazynowania we/wy w odniesieniu do wywłaszczania międzyprocesowego oraz wznawiania wątków.

Za pomocą profilu mssql TuneD konfiguruje ustawienia vm.swappiness, vm.dirty_* i kernel.sched_*. Konfiguracja dysku readahead za pomocą polecenia blockdev jest przeznaczona dla każdego urządzenia i musi być wykonywana ręcznie.

Ustawienie jądra dla automatycznego równoważenia NUMA w systemach NUMA z wieloma węzłami

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

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 powinna mieć tę opcję domyślnie włączoną. Aby zapewnić jak najspójniejsze działanie, zalecamy pozostawienie tej opcji konfiguracji włączonej. Jeśli jednak w wdrożeniach programu SQL Server występuje duże działanie stronicowania pamięci z wieloma wystąpieniami, na przykład lub wykonywanie programu SQL Server z innymi aplikacjami wymagającymi pamięci na serwerze, zalecamy przetestowanie wydajności 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

Po modyfikacji należy uaktywnić profil mssql:

tuned-adm off
tuned-adm profile mssql

Za pomocą profilu mssql TuneD konfiguruje opcję transparent_hugepage.

Zalecenia dotyczące ustawień sieci

Podobnie jak w przypadku zaleceń dotyczących magazynu i procesora CPU, poniżej przedstawiono również zalecenia dotyczące sieci. 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.

Konfigurowanie rozmiaru buforu portów sieciowych. W poniższym przykładzie karta sieciowa nosi nazwę eth0, która jest kartą sieciową firmy Intel. 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
```
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. Dopiero wtedy włączając ramki jumbo, można poprawić wydajność. Po włączeniu ramek jumbo połącz się z programem SQL Server i zmień rozmiar pakietu sieciowego na 8060 przy użyciu sp_configure, jak pokazano poniżej:
```
# 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
```
Domyślnie zalecamy ustawienie portu 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 we wszystkich różnych infrastrukturach sieciowych, dlatego przejrzyj istniejącą infrastrukturę sieci i upewnij się, że jest to obsługiwane. Poniższy 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

W przypadku przewidywalnego zachowania w środowiskach o wysokiej wydajności, takich jak środowiska do porównywania porównawczego, wyłącz adaptacyjne łączenie RX/TX IRQ, a następnie ustaw w szczególności łą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 1 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
```
Zalecamy również włączenie skalowania po stronie odbierającej (RSS), a także domyślne połączenie stron RX i TX w ramach kolejek RSS. Podczas pracy z pomocą techniczną firmy Microsoft wystąpiły konkretne scenariusze, w których wyłączenie funkcji RSS również poprawiło 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
```
Zarządzanie koligacją IRQ portu karty sieciowej. Aby osiągnąć oczekiwaną wydajność przez dostosowanie przypisania IRQ, należy wziąć pod uwagę kilka ważnych parametrów, takich jak obsługa topologii serwera przez Linux, stos sterowników kart interfejsu sieciowego, ustawienia domyślne i konfiguracja irqbalance. Optymalizacje ustawień koligacji IRQ portów karty sieciowej są wykonywane przy użyciu wiedzy o topologii serwera, wyłączaniu irqbalance i używaniu 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
```
Po wykonaniu powyższych zmian sprawdź szybkość karty sieciowej, aby upewnić się, że jest zgodna z oczekiwaniami, 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, co pozwala na dobre skalowanie wydajności warstwy blokowej z szybkimi dyskami półprzewodnikowymi (SSD) i systemami wielordzeniowymi. Sprawdź dokumentację, czy jest ona domyślnie włączona w dystrybucji systemu Linux. W większości innych przypadków uruchomienie jądra przy użyciu scsi_mod.use_blk_mq=y włącza go, chociaż dokumentacja używanej dystrybucji systemu Linux może zawierać dalsze wskazówki na ten temat. Jest to zgodne z nadrzędnym jądrem systemu Linux.
Ponieważ wielościeżkowe operacje we/wy są często używane dla wdrożeń SQL Server, należy skonfigurować wielokolejkowy cel dla mapera urządzeń (DM) do korzystania z infrastruktury blk-mq, włączając opcję rozruchu jądra dm_mod.use_blk_mq=y. Wartość domyślna to n (wyłączone). To ustawienie, gdy bazowe urządzenia SCSI używają blk-mq, zmniejsza obciążenie związane z blokowaniem w warstwie DM. 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

Użyj ALTER SERVER CONFIGURATION, aby ustawić PROCESS AFFINITY dla wszystkich NUMANODEi/lub procesorów używanych w programie SQL Server (zazwyczaj dla wszystkich węzłów i CPU) w systemie 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ść. Zapoznaj się z dokumentacją narzędzia mssql-conf oraz ustawienia memory.memorylimitmb, które kontroluje pamięć widoczną dla programu SQL Server (w jednostkach MB).

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.

Udostępnij za pośrednictwem

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

Zalecenie dotyczące konfiguracji magazynu

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

Zalecenia dotyczące partycjonowania i konfiguracji dysku

Zalecenie dotyczące konfiguracji systemu plików

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

Ograniczenie otwierania pliku

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

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

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

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

Użyj TuneD do konfiguracji ustawień jądra

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

Zalecenie dotyczące ustawień procesora CPU

Zalecenia dotyczące ustawień dysku

Opis

Ustawienie jądra dla automatycznego równoważenia NUMA w systemach NUMA z wieloma węzłami

Ustawienia jądra dla wirtualnej przestrzeni adresowej

Pozostaw włączone przezroczyste ogromne strony (THP)

Zalecenia dotyczące ustawień sieci

Zaawansowana konfiguracja jądra i systemu operacyjnego

Konfigurowanie pliku swapfile

Maszyny wirtualne i pamięć dynamiczna

Konfiguracja programu SQL Server

Najlepsze rozwiązania

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

Konfigurowanie wielu plików danych `tempdb`

Konfiguracja zaawansowana

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

Opinia

Dodatkowe zasoby

Udostępnij za pośrednictwem

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

Zalecenie dotyczące konfiguracji magazynu

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

Zalecenia dotyczące partycjonowania i konfiguracji dysku

Zalecenie dotyczące konfiguracji systemu plików

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

Ograniczenie otwierania pliku

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

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

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

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

Użyj TuneD do konfiguracji ustawień jądra

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

Zalecenie dotyczące ustawień procesora CPU

Zalecenia dotyczące ustawień dysku

Opis

Ustawienie jądra dla automatycznego równoważenia NUMA w systemach NUMA z wieloma węzłami

Ustawienia jądra dla wirtualnej przestrzeni adresowej

Pozostaw włączone przezroczyste ogromne strony (THP)

Zalecenia dotyczące ustawień sieci

Zaawansowana konfiguracja jądra i systemu operacyjnego

Konfigurowanie pliku swapfile

Maszyny wirtualne i pamięć dynamiczna

Konfiguracja programu SQL Server

Najlepsze rozwiązania

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

Konfigurowanie wielu plików danych tempdb

Konfiguracja zaawansowana

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

Powiązana zawartość

Opinia

Dodatkowe zasoby

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

Konfigurowanie wielu plików danych `tempdb`