Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy:Program SQL Server w systemie Linux
W tym artykule opisano zalecenia dotyczące konfiguracji systemu operacyjnego i sprzętu w celu zmaksymalizowania wydajności SQL Server on Linux, w tym ustawień magazynu, jądra, procesora CPU i sieci.
Note
Informacje na temat konfiguracji pamięci i limitów pamięci kontenera można znaleźć w artykule Najlepsze rozwiązania w zakresie wydajności: pamięć SQL Server w systemie Linux.
- zalecenie dotyczące konfiguracji usługi Storage
- Ustawienia jądra i CPU do wysokiej wydajności
- Konfiguracja usługi SQL Server
Zalecenie dotyczące konfiguracji magazynu
Podsystem magazynowania hostujący dane, dzienniki transakcji i inne skojarzone pliki (takie jak pliki punktu kontrolnego dla olTP w pamięci) powinien bezpiecznie zarządzać obciążeniami średnimi i szczytowymi.
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 wdrożeń SQL Server on Linux na Azure Virtual Machines rozważ użycie programowej macierzy RAID, aby zapewnić odpowiednią liczbę operacji wejścia/wyjścia na sekundę (IOPS) i przepustowość. Aby zapoznać się z zagadnieniami dotyczącymi magazynu podczas konfigurowania SQL Server na maszynach wirtualnych Azure, zobacz Konfigurowanie magazynu dla SQL Server na maszynach wirtualnych Azure.
W poniższym przykładzie pokazano, jak utworzyć programową macierz RAID w systemie Linux na maszynie wirtualnej platformy Azure. Użyj odpowiedniej liczby dysków danych, aby zapewnić wymaganą przepustowość i wartości IOPS dla woluminów na podstawie wymagań dotyczących danych, dziennika transakcji i operacji we/wy tempdb. W poniższym przykładzie do maszyny wirtualnej jest dołączonych 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 macierzy RAID, użyj lsblk polecenia .
# 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 widzisz:
- 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 SQL Server danych i plików dziennika transakcji.
Sformatuj wolumin przy użyciu 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.
Na przykład uruchom 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 1024 liczby połączeń niż domyślny limit otwartych plików (1024). Można ustawić miękkie i twarde limity na 1048576 (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
Note
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 system automatycznie ponownie montuje dyski po ponownym uruchomieniu, 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 obsługiwane dystrybucje systemu Linux implementują wymuszony dostęp jednostkowy (FUA) na poziomie podsystemu We/Wy w celu zapewnienia trwałości danych. Program SQL Server wykorzystuje tę funkcję, aby zapewnić wydajną i niezawodną wydajność we/wy dla obciążeń systemu Linux. Aby uzyskać więcej informacji na temat obsługi FUA w dystrybucjach Linuksa i jego wpływu na SQL Server, zobacz SQL Server on Linux: Forced Unit Access (FUA) Internals.
Obsługa protokołu FUA w podsystemie we/wy została wprowadzona w systemach SUSE Linux Enterprise Server 12 SP5, Red Hat Enterprise Linux 8.0 i Ubuntu 18.04. W programie SQL Server 2017 (14.x) CU 6 i nowszych wersjach użyj następującej konfiguracji, aby umożliwić wysoką wydajność i wydajną operację we/wy z funkcją FUA w programie SQL Server.
Użyj tej zalecanej konfiguracji, jeśli spełnione są 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)
Note
Począwszy od SQL Server 2025 (17.x), system SUSE Linux Enterprise Server (SLES) nie jest obsługiwany.
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.
Note
Użyj 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 sprzęt, który obsługuje i jest skonfigurowany do obsługi funkcji FUA
Zalecana konfiguracja:
Włącz flagę śledzenia 3979 jako parametr uruchamiania.
Użyj
mssql-conf, aby skonfigurowaćcontrol.writethrough = 1icontrol.alternatewritethrough = 0.
W przypadku prawie wszystkich innych konfiguracji, które nie spełniają poprzednich warunków, użyj następującej zalecanej konfiguracji:
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 = 1icontrol.alternatewritethrough = 1.
Obsługa fua dla kontenerów programu SQL Server wdrożonych na platformie Kubernetes
Program SQL Server musi używać trwałej zamontowanej pamięci, a nie
overlayfs.Magazyn musi używać systemów plików XFS lub ext4 i powinien obsługiwać FUA (ext4 nie obsługuje FUA w jądrze Linux wcześniejszych niż wersja 5.6). Przed włączeniem tego ustawienia skontaktuj się z dostawcą dystrybucji systemu Linux i magazynu, aby upewnić się, że podsystem operacyjny i magazyn obsługuje 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 twoimPersistentVolumeClaim:kubectl describe pv <pvc-name>W danych wyjściowych wyszukaj
fstypeustawioną 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, użyj następujących zalecanych ustawień FUA:
Włącz flagę śledzenia 3979 jako parametr uruchamiania.
Użyj
mssql-conf, aby skonfigurowaćcontrol.writethrough = 1icontrol.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, możesz używać profilu TuneD o nazwie mssql, który oferuje bardziej szczegółowe ustawienia dostrajania wydajności systemu Linux dla obciążeń SQL Server. Ten profil jest oparty na profilu wydajności przepływności RHEL.
mssql Ponieważ profil uwidacznia wszystkie jego ustawienia, możesz przejrzeć i dostosować je do innych dystrybucji systemu Linux lub wydań systemu RHEL, które nie zawierają 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.
Note
Począwszy od SQL Server 2025 (17.x), system SUSE Linux Enterprise Server (SLES) nie jest obsługiwany.
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 następujących 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, używając 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 | Value | 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 | Value | Więcej informacji |
|---|---|---|
Dysk readahead |
4096 | Zobacz polecenie blockdev |
| ustawienia sysctl | kernel.sched_min_granularity_ns = 15000000kernel.sched_wakeup_granularity_ns = 2000000vm.dirty_ratio = 80vm.dirty_background_ratio = 3vm.swappiness = 1 |
Zobacz polecenie sysctl |
Description
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źć w dokumentacji /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 jądra dla automatycznego równoważenia NUMA w wielowęzłowych systemach 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
Domyślne ustawienie to vm.max_map_count65536 (65 536), które może nie być wystarczająco wysokie w przypadku instalacji SQL Server. Z tego powodu zmień vm.max_map_count wartość na co najmniej 262144 (262 144) dla wdrożenia SQL Server. Aby uzyskać dalsze dostrajanie tych parametrów jądra, zobacz sekcję Proponowane ustawienia systemu Linux przy użyciu profilu TuneD mssql . Wartość maksymalna to vm.max_map_count2147483647 (2,147,483,647).
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 magazynu i procesora CPU należy wziąć pod uwagę następujące zalecenia dotyczące sieci. Różne karty sieciowe oferują różne ustawienia. Zapoznaj się z dostawcami kart interfejsu sieciowego, aby uzyskać wskazówki dotyczące każdej z tych opcji. Przetestuj i skonfiguruj te ustawienia w środowiskach deweloperskich przed ich zastosowaniem do środowisk 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 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
eth0nazwą karty sieciowej:ethtool -g eth0Ustaw rozmiar buforu
rx(odbieranie) itx(transmisji) na 4 KB:ethtool -G eth0 rx 4096 tx 4096Sprawdź, czy wartość jest prawidłowo skonfigurowana:
ethtool -g eth0Włą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 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 9014EXECUTE sp_configure 'network packet size', '8060'; GO RECONFIGURE WITH OVERRIDE; GOKonfigurowanie adaptacyjnego łączenia środowiska IRQ. 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:Ustaw port na potrzeby adaptacyjnego łączenia RX/TX IRQ:
ethtool -C eth0 adaptive-rx on ethtool -C eth0 adaptive-tx onPotwierdź ustawienie:
ethtool -c eth0Note
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 offPotwierdź zmianę:
ethtool -c eth0Ustaw parametry
rx-usecsiirq.rx-usecsOkreśla liczbę mikrosekund po odebraniu co najmniej jednego pakietu przed wygenerowaniem przerwania. Parametrirqokreśla odpowiednie opóźnienia w aktualizowaniu stanu, gdy przerwanie jest wyłączone. W przypadku kart sieciowych opartych na technologii Intel można użyć następujących ustawień:ethtool -C eth0 rx-usecs 100 tx-frames-irq 512Potwierdź zmianę:
ethtool -c eth0Włą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 eth0Połą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 8Sprawdź ustawienie:
ethtool -l eth0Skonfiguruj 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
irqbalanceustawienie. Ustawienia koligacji irQ portów karty sieciowej można zoptymalizować przy użyciu wiedzy o topologii serwera, wyłączającirqbalancei 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.serviceLub:
irqbalance --oneshotUpewnij się, że
common_irq_affinity.shjest wykonywalny:chmod +x common_irq_affinity.shWyświetlanie koligacji IRQ dla portu karty sieciowej Mellanox (na przykład
eth0):./show_irq_affinity.sh eth0Zoptymalizuj wydajność przepustowości za pomocą narzędzia Mellanox:
./mlnx_tune -p HIGH_THROUGHPUTUstaw powiązanie sprzętowe na węzeł NUMA, na którym fizycznie znajduje się karta sieciowa i jej port:
./set_irq_affinity_bynode.sh `\cat /sys/class/net/eth0/device/numa_node` eth0Sprawdź koligację IRQ:
./show_irq_affinity.sh eth0Dodaj optymalizacje koalescencji IRQ.
ethtool -C eth0 adaptive-rx off ethtool -C eth0 adaptive-tx off ethtool -C eth0 rx-usecs 750 tx-frames-irq 2048Zweryfikuj ustawienia:
ethtool -c eth0Sprawdź szybkość karty sieciowej. 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=ypolecenia , 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.Ze względu na to, że wielościeżkowe we/wy są często używane w przypadku wdrożeń SQL Server, należy skonfigurować obiekt docelowy wielościeżkowego mapowania (DM) do korzystania z
blk-mqinfrastruktury, włączając opcję rozruchudm_mod.use_blk_mq=yjądra. Wartość domyślna ton(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, zobacz 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. Jeśli planujesz uruchamiać kontenery, włącz miejsce wymiany na poziomie hosta.
Maszyny wirtualne i pamięć dynamiczna
Jeśli używasz SQL Server on Linux na maszynie wirtualnej, upewnij się, że wybrano opcje, które 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 praktyki
Poniższe rozwiązania dotyczą wszystkich wdrożeń SQL Server on Linux.
Użyj koligacji procesu dla węzła i procesorów
Użyj ALTER SERVER CONFIGURATION, aby ustawić PROCESS AFFINITY dla wszystkich elementów NUMANODE i procesorów CPU używanych przez program SQL Server (co zazwyczaj dotyczy wszystkich elementów NODE i procesorów CPU) w systemie Linux. Koligacja procesora pomaga zachować wydajne zachowanie planowania systemu Linux i SQL. Użycie opcji NUMANODE jest najprostszą metodą. Należy użyć PROCESS AFFINITY nawet wtedy, gdy na komputerze istnieje tylko jeden węzeł NUMA. Aby uzyskać więcej informacji o tym, jak ustawić PROCESS AFFINITY, zobacz artykuł ALTER SERVER CONFIGURATION.
Konfigurowanie wielu plików danych tempdb
Ponieważ instalacja SQL Server on Linux nie oferuje opcji skonfigurowania wielu plików, rozważ utworzenie wielu tempdbtempdb plików danych po instalacji. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące zmniejszenia rywalizacji o alokację w bazie danych tempdb programu SQL Server.
Konfiguracja zaawansowana
Informacje o opcjach konfiguracji pamięci, w tym limitach pamięci mssql-conf, ustawieniach cgroup, przykładach konfiguracji pamięci kontenerów Docker oraz zagadnieniach dotyczących przestrzeni wymiany, można znaleźć tutaj: Najlepsze praktyki dotyczące wydajności: pamięć programu SQL Server w systemie Linux.