Najlepsze rozwiązania dotyczące wydajności: magazyn, jądro, procesor CPU i sieć dla SQL Server on Linux

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

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:

  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, użyj następującej zalecanej konfiguracji:

  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ć trwałej zamontowanej pamięci, a nie overlayfs.

  2. 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 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, użyj 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, 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 = 15000000
kernel.sched_wakeup_granularity_ns = 2000000
vm.dirty_ratio = 80
vm.dirty_background_ratio = 3
vm.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.

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

    Potwierdź ustawienie:

    ethtool -c eth0
    

    Note

    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 kart sieciowych opartych na technologii 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. Skonfiguruj 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. Ustawienia koligacji irQ portów karty sieciowej można zoptymalizować przy użyciu wiedzy o topologii serwera, wyłączając irqbalancei 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 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` eth0
    

    Sprawdź koligację IRQ:

    ./show_irq_affinity.sh eth0
    

    Dodaj optymalizacje koalescencji IRQ.

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

    Zweryfikuj ustawienia:

    ethtool -c eth0
    
  6. Sprawdź 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=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.

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