Konfigurowanie pamięci trwałej (PMEM) dla programu SQL Server w systemie Linux

Dotyczy:Program SQL Server w systemie Linux

Ten artykuł opisuje, jak skonfigurować trwałą pamięć (PMEM) dla SQL Server 2019 (15.x) oraz nowszych wersji na Linuksie.

Overview

SQL Server 2019 (15.x) dodaje trwałe wsparcie dla pamięci, aby przyspieszyć kilka operacji wymagających pamięci masowej.

W systemie plików świadomym PMEM, mapowanie pamięci (mmap()) daje aplikacjom w przestrzeni użytkownika bezpośredni dostęp do danych plików. Gdy dla pliku tworzona jest mapa pamięci, aplikacja może wydawać instrukcje ładowania/zapisu, które omijają warstwę pamięci.

Note

Ten bezpośredni dostęp nazywany jest metodą oświeconego dostępu do plików z perspektywy aplikacji rozszerzenia hosta, co jest sposobem interakcji SQL Server z systemem operacyjnym hosta, wykorzystując warstwę abstrakcji SQL Platform (SQLPAL).

Ten artykuł pokazuje, jak skonfigurować trwałą pamięć dla SQL Server on Linux.

Tworzenie przestrzeni nazw dla urządzeń PMEM

Konfigurowanie urządzeń

W systemie Linux użyj narzędzia ndctl.

  • Zainstaluj program ndctl , aby skonfigurować urządzenie PMEM z sekcji Instalowanie NDCTL.
  • Użyj ndctl, aby utworzyć przestrzeń nazw. Przestrzenie nazw są przeplatane między modułami NVDIMM PMEM i mogą umożliwiać różne typy dostępu użytkownika do obszarów pamięci na urządzeniu. fsdax jest domyślnym i żądanym trybem dla programu SQL Server.
ndctl create-namespace -f -e namespace0.0 --mode=fsdax --map=dev

Tryb ten fsdax przechowuje metadane na stronę w pamięci systemowej. Opcja ta --map=dev jest zalecana, ponieważ przechowuje metadane bezpośrednio w przestrzeni nazw. Przechowywanie metadanych w pamięci z jest --map=mem eksperymentalne.

Użyj ndctl, aby zweryfikować przestrzeń nazw.

Przykładowe dane wyjściowe są następujące:

# ndctl list -N
{
  "dev":"namespace0.0",
  "mode":"fsdax",
  "map":"dev",
  "size":4294967296,
  "sector_size":512,
  "blockdev":"pmem0",
  "numa_node":0
}

Tworzenie i instalowanie urządzenia PMEM

Na przykład z XFS:

mkfs.xfs -f /dev/pmem0
mount -o dax,noatime /dev/pmem0 /mnt/dax
xfs_io -c "extsize 2m" /mnt/dax

Na przykład z ext4:

mkfs.ext4 -b 4096 -E stride=512 -F /dev/pmem0
mount -o dax,noatime /dev/pmem0 /mnt/dax

Zagadnienia techniczne

  • Blokuj alokację 2 MB dla systemu XFS lub ext4, zgodnie z wcześniejszym opisem
  • Niezgodność między alokacją bloków a mmap powoduje ciche przełączenie na 4 KB
  • Rozmiary plików powinny mieć wielokrotność 2 MB (modulo 2 MB)
  • Nie wyłączaj przezroczystych ogromnych stron (THP) (domyślnie włączone w większości dystrybucji)

Po ndctl skonfigurowaniu, utworzeniu i zamontowaniu urządzenia możesz umieścić w nim pliki bazy danych lub utworzyć nową bazę danych.

Możesz przechowywać pliki danych SQL Server (.mdf, ) i tempdb pliki na urządzeniu PMEM w trybie za fsdax pomocą następującego .ndfpolecenia. Nie używaj tego trybu do przechowywania plików logów SQL Server (.ldf), ponieważ dziennik transakcyjny wymaga pamięci zapewniającej gwarancje sektorowe atomowe:

ndctl create-namespace -f -e namespace0.0 --mode=fsdax --map=dev

Przed ustawieniem opcji mapy w poprzednim poleceniu należy pamiętać o następujących kwestiach:

  • Aby uzyskać najlepszą wydajność podczas dostępu i aktualizacji tych wpisów strony NVDIMM dla tego urządzenia, użyj -map=mem
  • Jeśli pojemność NVDIMM jest zbyt duża (powyżej 512 GB), ustaw -map=dev, co wpływa na przepustowość I/O i obniża wydajność

Dla plików logów SQL Server na urządzeniach PMEM konfiguruj urządzenia PMEM tak, aby korzystały z tabeli translacji sektorowej/blokowej (BTT). Ta konfiguracja zapewnia atomowość sektorów, jaką pliki logów SQL Server wymagają dla tej technologii przechowywania danych. Przeprowadzaj weryfikację wydajności obciążenia. Porównaj wydajność logów SQL Server dla swojego obciążenia między tym rozwiązaniem a najlepszymi dyskami NVMe SSD, a następnie wybierz ten, który najlepiej odpowiada Twoim potrzebom.

ndctl create-namespace -f -e namespace0.0 --mode= sector

Wyłącz zachowanie wymuszonego opróżniania

Ponieważ urządzenia PMEM są bezpieczne O_DIRECT (bezpośrednie I/O), można wyłączyć wymuszone opróżnianie.

Note

System pamięci masowej może zapewnić, że wszelkie zapisy w buforze lub etapach są bezpieczne i trwałe, gwarantując, że zapisy na urządzeniu znajdują się na nośniku, który utrzymuje się mimo awarii systemu, resetów interfejsu i awarii zasilania, a sam nośnik jest sprzętowo redundantny.

  • Pliki bazy danych (.mdf i .ndf) i dziennika transakcji (.ldf) nie używają plików writethrough i alternatewritethrough domyślnie w programie SQL Server 2017 (14.x) CU 6 i nowszych wersjach, ponieważ używają wymuszonego zachowania opróżniania. Flaga śladu 3979 wyłącza wymuszone zachowanie wyczyszczenia plików baz danych i dzienników transakcyjnych oraz wykorzystuje logikę writethrough and alternatewritethrough .

  • Inne pliki, które SQL Server otwiera , FILE_FLAG_WRITE_THROUGHtakie jak migawki bazy danych, wewnętrzne migawki do sprawdzania spójności bazy danych (),DBCC CHECKDB pliki śledzenia profilera oraz rozszerzone pliki śledzenia zdarzeń, wykorzystują optymalizacje writethrough i alternatewritethrough .

Aby uzyskać więcej informacji na temat zmian wprowadzonych w programie SQL Server 2017 (14.x) CU 6, zobacz KB 4131496. Aby uzyskać więcej informacji na temat wymuszonego dostępu do jednostek - wewnętrznych (FUA), zobacz wewnętrzne FUA.

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.

Treści powiązane

  • Last updated on