Prawidłowe ustawienie parametru vm.swappiness w celu uzyskania optymalnej wydajności serwera

Pokażę, jak ustawić parametr vm.swappiness tak, aby usługi internetowe i bazodanowe na serwerach hostingowych reagowały szybciej i generowały mniej operacji wejścia/wyjścia. Dzięki jasnym instrukcjom, sensownym wartościom początkowym i monitorowaniu wykorzystasz w pełni dostępną pamięć RAM oraz zmniejszysz Opóźnienia i zapobiegasz niepotrzebnemu swappowaniu.

Punkty centralne

Poniższe punkty pozwolą ci szybko zapoznać się z ustawieniami, które można zastosować od razu.

• Zachowanie w grze Swappiness: Określa, jak wcześnie jądro przenosi pamięć RAM do obszaru swap.
• Odniesienie do obciążenia pracą: Dostosuj wartości do typu aplikacji, np. bazy danych lub strony internetowej.
• Przeprowadź test tymczasowy: Najpierw sprawdź na żywo, a dopiero potem ustal na stałe.
• Układ swapów: Należy uwzględnić wielkość, środki i priorytety.
• Monitoring: Monitorowanie i regulacja operacji wejścia/wyjścia, pamięci RAM oraz czasów odpowiedzi.

Czym jest vm.swappiness i jak działa

Parametr jądra vm.swappiness określa, jak intensywnie system Linux przenosi strony pamięci z pamięci RAM do obszaru wymiany. Aktualną wartość znajdziesz w pseudoplikowym systemie plików pod ścieżką /proc/sys/vm/swappiness i możesz ją zmienić w trakcie działania systemu lub na stałe. Wysoka wartość powoduje wcześniejsze przenoszenie danych do partycji swap, natomiast niska wartość sprawia, że zawartość dłużej pozostaje w pamięci RAM. Celem jest osiągnięcie dobrej równowagi między wykorzystaniem pamięci RAM, pamięcią podręczną stron oraz kontrolowanym zachowaniem partycji swap. Pamiętam, że pamięć RAM jest znacznie szybsza niż jakikolwiek dysk SSD, dlatego preferuję Pamięć robocza zdecydowanie przed swapem.

Dlaczego Swappiness ma znaczenie na serwerach hostingowych

Na serwerach internetowych i aplikacyjnych decydujące znaczenie ma ustawienie Swappiness o czasie reakcji i przepustowości. Agresywne przełączanie pamięci powoduje dodatkowe obciążenie operacji wejścia/wyjścia i spowalnia zapytania, zwłaszcza w przypadku obciążeń opartych na bazach danych. Z kolei zbyt niskie wartości niosą ze sobą ryzyko późniejszych zdarzeń OOM, które powodują nagłe zakończenie procesów. Dlatego oprócz pamięci RAM i obszaru wymiany oceniam również typowe szczyty obciążenia, pamięci podręczne i wzorce zapytań. Zmniejszenie opóźnień pozwala uniknąć zacięć i zapewnia zauważalną płynność transakcji płyn.

Zalecenia w zależności od obciążenia pracą

Jedna wartość rzadko pasuje do wszystkich scenariuszy, dlatego zaczynam od sprawdzonych w praktyce przedziałów, a następnie dostosowuję je na podstawie danych pomiarowych. Bazy danych korzystają z bardzo niskich ustawień, podczas gdy serwery czysto internetowe często tolerują nieco wyższe wartości. Systemy testowe lub deweloperskie mogą działać bliżej standardu, ponieważ wygoda odgrywa tu większą rolę. Poniższy schemat wykorzystuję jako pragmatyczny punkt wyjścia do Hosting-Obciążenia. Następnie monitoruję operacje wejścia/wyjścia, wykorzystanie pamięci wymiany oraz czasy odpowiedzi i dostosowuję ustawienia w zależności od potrzeb.

Obciążenie pracą	Zalecany poziom swappiness	Cel
Bazy danych (MySQL, PostgreSQL)	0–10	Utrzymywanie bufora w pamięci RAM, ograniczanie opóźnień
W czasie rzeczywistym/o niskim opóźnieniu	0–10	Unikanie szczytów obciążenia wejścia/wyjścia poprzez wykorzystanie pamięci wymiany
Serwer sieciowy z skrzynkami	10–20 (czasami 10–30)	Przenoszenie nieaktywnych stron, aktywne żądania w pamięci RAM
Rozwój/Testy	30–60	Komfort i stabilność przed opóźnieniem

Sprawdź aktualną wartość

Zanim zmienię wartości, odczytuję stan i dokumentuję Linia bazowa. W tym celu używam polecenia `cat /proc/sys/vm/swappiness` lub `sysctl vm.swappiness` – oba sposoby zwracają wartość liczbową, np. 60. Równolegle sprawdzam zajętość pamięci RAM i partycji swap za pomocą polecenia `free -h`. Za pomocą polecenia `swapon –show` sprawdzam rozmiar, priorytet i nośnik aktywnych urządzeń swapowych. Te dane wyjściowe pomagają mi później ocenić skutki przydzielać być w stanie.

Najpierw przetestować tymczasowo, zamiast od razu wprowadzać stałe zmiany

Najpierw zainstaluję Swappiness na próbę, aby sprawdzić reakcje w rzeczywistych Obciążenie widać. Polecenie `sysctl vm.swappiness=10` działa natychmiast, ale jego efekt utrzymuje się tylko do momentu ponownego uruchomienia systemu. Podczas testów obserwuję `top` lub `htop`, sprawdzam `vmstat` i `iostat` oraz mierzę czasy odpowiedzi usług. Jeśli wskaźnik swapowania zmniejsza się, a opóźnienia pozostają stabilne, przechodzę do kolejnych kroków. Dopiero gdy wskaźniki są przekonujące, zapisuję wartość stały stały.

Skonfiguruj na stałe

Jeśli wartość testowa jest prawidłowa, wpisuję ją do pliku konfiguracyjnego sysctl i ponownie ładuję ustawienia. W pliku /etc/sysctl.conf dodaję wiersz vm.swappiness=10 i aktywuję go poleceniem sysctl -p. Uważam jednak za bardziej przejrzyste utworzenie osobnego pliku w katalogu /etc/sysctl.d/, na przykład 99-swappiness.conf, i załadowanie go za pomocą polecenia sysctl –system. Takie rozwiązanie pozwala na łatwe zarządzanie wersjami i włączenie go do procesów automatyzacji. Bardziej szczegółowy przegląd powiązanych parametrów zawiera ten artykuł na stronie sysctl tuning, który pomaga mi w uporządkowaniu zmian oraz Przejrzystość przynosi.

Rozmiar partycji swap, układ pamięci i nośniki danych

Swappiness nigdy nie działa w oderwaniu od innych czynników, dlatego oceniam wielkość i położenie Zamiana zawsze. Zbyt mała przestrzeń wymiany szybko się zapełnia, a zbyt duża wydłuża fazy wejścia/wyjścia w sytuacjach obciążenia. Na dyskach SSD lub NVMe przestrzeń wymiany działa szybciej niż na dyskach HDD, jednak pamięć RAM pozostaje o kilka rzędów wielkości przed nimi. Kilka urządzeń wymiany z priorytetami pomaga w pierwszym rzędzie wykorzystać najszybszy nośnik. Kto chce zgłębić zalety i wady, znajdzie w tym przeglądzie informacje na temat Swap w hostingu przydatne wskazówki do przemyślenia dla Praktyka.

Przebieg pracy w praktyce: krok po kroku

Zacznę od oceny aktualnego stanu: zanotuję aktualną wartość Swappiness, wykorzystanie pamięci RAM i partycji swap, obciążenie procesora oraz operacje wejścia/wyjścia i zapiszę to jako Odniesienie zapisuję. Następnie klasyfikuję obciążenie: głównie bazy danych, serwisy internetowe z pamięcią podręczną, obciążenia mieszane lub kontenerowe. Potem ustalam docelową wartość: dla baz danych 0–10, dla serwisów internetowych zazwyczaj 10–20, a w przypadku obciążeń mieszanych ostrożnie testuję. Ustawiam wartość tymczasowo, obserwuję kilka faz obciążenia i porównuję wskaźniki. Jeśli obraz się powtarza, ustalam wartość na stałe, dokumentuję zmianę i sprawdzam ją po aktualizacji jądra, sprzętu lub Zwolnienie-Zmiana ponownie.

Specjalne scenariusze: kontenery, maszyny wirtualne i chmura

W kontenerach i maszynach wirtualnych zwiększam wartość parametru „swappiness” zarówno na poziomie hosta, jak i gościa wspólnie . Systemy orkiestracji, takie jak Kubernetes, zazwyczaj korzystają z bardzo niskich ustawień na węzłach roboczych, aby ograniczyć opóźnienia w podach. W maszynach wirtualnych ustalam wewnętrznie odpowiednie wartości, zwracając jednak uwagę, aby hiperwizor nie działał w sposób sprzeczny. W elastycznych konfiguracjach chmurowych konserwatywne wartości pomagają wyrównać szczyty obciążenia, dopóki skalowanie nie zacznie działać. Staram się unikać sytuacji, w której pojedynczy kontener, poprzez intensywne korzystanie z pamięci wymiany, obciąża całą Platforma hamuje.

Monitorowanie i rozwiązywanie problemów

Typowe sygnały ostrzegawcze wskazujące na nieodpowiednią wartość swappiness to dla mnie wysokie obciążenie wejścia/wyjścia przy wciąż wolnej pamięci RAM, wahające się czasy odpowiedzi oraz powolne zapytania do bazy danych. Takie wzorce sprawdzam za pomocą narzędzi vmstat, iostat, sar oraz metryk z mojego stosu obserwowalności. Jeśli system wykazuje intensywne wykorzystanie pamięci wymiany pomimo wolnej pamięci RAM, zazwyczaj obniżam wartość swappiness. Jeśli zauważę logi OOM lub przerwania działania przy ograniczonej ilości pamięci RAM, umiarkowanie podnoszę wartość swappiness lub dostosowuję konfigurację pamięci wymiany. Poniższa tabela przedstawia symptomy wskazujące na prawdopodobną Przyczyna i wyznacza wstępny kierunek.

Objaw	Prawdopodobna przyczyna	Następny krok
Wysoka przepustowość wejścia/wyjścia przy wolnej pamięci RAM	Zbyt wysoki poziom swappinessu	Obniżyć wartość, zmierzyć efekt
Zdarzenia OOM pod obciążeniem	Zbyt niski wskaźnik swappiness lub zbyt mała ilość pamięci swap	Zwiększyć wartość, sprawdzić rozmiar swapu
Zapytania o niskiej wydajności pomimo rezerwy mocy procesora	Bufor bazy danych został przeniesiony do pamięci zewnętrznej	Wartość w zakresie 0–10, analiza bufora DB
Szczyty obciążenia bez wąskiego gardła procesora	Szczyty obciążenia we/wy spowodowane operacjami swapowania	Zmniejszyć wartość Swappiness, sprawdzić trafienia w pamięci podręcznej

Zrozumienie wskaźników o wysokim stopniu szczegółowości

Aby obiektywnie ocenić współczynnik swappiness, przyglądam się dokładniej licznikom jądra. W pliku /proc/vmstat wartości pswpin i pswpout wskazują liczbę stron wczytanych i wyrzuconych z pamięci. pgscan_kswapd_* i pgsteal_* pokazują, jak agresywnie działa moduł odzyskiwania pamięci. Jeśli pojawia się dużo wpisu pgmajfault (Major Page Faults), oznacza to, że dochodzi do ponownego ładowania danych, które obciąża operacje wejścia/wyjścia. Sprawdzam te wartości wielokrotnie lub za pomocą poleceń `sar -B` i `sar -W`, żeby zobaczyć średnie wartości, a nie tylko chwilowe odczyty. Za pomocą polecenia vmstat 1 rozpoznaję si/so (Swap in/out) i mogę przypisać skoki do rzeczywistych zdarzeń. Dodatkowo katalog /proc/pressure/memory dostarcza oceny, w jakim stopniu zadania są ograniczane z powodu presji pamięciowej blok (PSI). Jeśli wartości te wzrosną częściowo lub całkowicie, mam wyraźną wskazówkę, że proces odzyskiwania jest zbyt agresywny lub że współczynnik swappiness jest nieodpowiedni.

Swappiness 0 vs. 1: co tak naprawdę robi jądro

Często uważa się, że wartość Swappiness=0 całkowicie wyłącza swapowanie. Nie jest to do końca prawdą. Wartość 0 sygnalizuje jądru, aby w miarę możliwości unikało swapowania i korzystało z niego tylko w przypadku rzeczywistego niedoboru pamięci. W praktyce wartość z przedziału 1–10 wystarcza, aby uzyskać bardzo powściągliwe zachowanie, podczas gdy wartość 0 w niektórych wersjach jądra może sporadycznie prowadzić do opóźnionych, ale za to intensywnych faz odzyskiwania pamięci. W przypadku usług, dla których opóźnienia mają kluczowe znaczenie, zazwyczaj ustawiam wartość 1–5 i obserwuję, czy wartości pswpout/pswpin pozostają praktycznie na poziomie zerowym. Jeśli przy wartości 0 podczas okresów wzmożonego obciążenia występują zdarzenia OOM, nieznacznie zwiększam tę wartość, aby jądro wcześniej łagodnie zmniejszało obciążenie, zamiast reagować gwałtownie. włamać się.

Jak efektywnie korzystać z Zswap i ZRAM

Oprócz klasycznego swapowania na dysku, w zależności od profilu korzystam z Zswap lub ZRAM. Zswap kompresuje strony wyrzucone do pamięci swapowej i początkowo przechowuje je w pamięci RAM, a dopiero w razie potrzeby przenosi je na nośnik danych. Zmniejsza to liczbę operacji wejścia/wyjścia i wyrównuje opóźnienia, ale obciąża procesor. Na hostach z dużą rezerwą mocy obliczeniowej procesora jest to bardziej dochodowy Kompromis. ZRAM udostępnia skompresowaną pamięć wymiany bezpośrednio w pamięci RAM – idealne rozwiązanie w przypadku obciążeń o charakterze impulsowym lub bardzo małych maszyn wirtualnych, w których wolę korzystać ze skompresowanej pamięci RAM niż z powolnych operacji we/wy. Ważne: Świadomie wybieram jedną z tych koncepcji i ustalam priorytety tak, aby najszybsza ścieżka była obsługiwana jako pierwsza. Swappiness pozostaje przy tym narzędziem sterującym: nawet przy użyciu Zswap/ZRAM chcę unikać niepotrzebnych fal odzyskiwania pamięci.

Pamięć podręczna stron, vfs_cache_pressure i trafienia w pamięci podręcznej

Wskaźnik „Swappiness” współdziała z pamięcią podręczną stron (Page Cache), która przechowuje pliki i i-węzły w pamięci RAM. Za pomocą parametru vm.vfs_cache_pressure kontroluję, jak agresywnie jądro opróżnia te pamięci podręczne w przypadku stron anonimowych. Zbyt wysokie wartości powodują zbyt szybkie usuwanie pamięci podręcznych metadanych, co spowalnia serwery WWW. Zazwyczaj zaczynam od wartości 50–100, mierzę współczynniki trafień w pamięci podręcznej i obserwuję, jak zmieniają się opóźnienia w przypadku zasobów statycznych i odpowiedzi API. Celem jest utrzymanie często wykorzystywanych treści w pamięci RAM bez zatykania pamięci roboczej rzadko używanymi stronami. Jeśli wskaźnik trafień pozostaje dobry, a operacje wejścia/wyjścia (I/O) są na niskim poziomie, oznacza to, że współdziałanie jest odpowiednie; w przeciwnym razie dostosowuję parametry swappiness i vfs_cache_pressure w pliku Tandem.

Unikanie zjawiska „dirty-writeback” i szczytów obciążenia we/wy

Ścieżki zapisu wpływają na opóźnienia w takim samym stopniu jak swap. Za pomocą parametrów vm.dirty_background_ratio/bytes i vm.dirty_ratio/bytes określam, jak duża część brudnej pamięci podręcznej zostanie zgromadzona, zanim jądro przystąpi do zapisu. Preferuję wartości typu *_bytes zamiast wartości procentowych, aby ustawić określone limity – szczególnie w konfiguracjach z dużą ilością pamięci RAM, gdzie wartości procentowe mogą generować ogromne fale zapisu zwrotnego. Cel: ciągłe, możliwe do zaplanowania zapisywanie zamiast sporadycznych szczytów obciążenia, które wraz z pamięcią wymiany powodują blokady operacji wejścia/wyjścia. Sprawdzam iostat oraz kolejki zapisu zwrotnego i utrzymuję wartości tak, aby dyski SSD/NVMe były stale obciążone, ale nie przejechany stać się.

NUMA, odzyskiwanie stref i duże hosty

W systemach z architekturą NUMA lokalizacja pamięci ma znaczenie. Jeśli opcja vm.zone_reclaim_mode jest włączona, jądro może bardziej agresywnie odzyskiwać pamięć w lokalnym węźle NUMA, co niepożądanie powoduje gwałtowne skoki w procesie odzyskiwania pamięci. W przypadku wielu obciążeń hostingowych wyłączam funkcję Zone Reclaim i pozostawiam rozmieszczenie pamięci harmonogramowi, aby uzyskać bardziej stabilne działanie. Dodatkowo sprawdzam opcję Transparent Huge Pages (THP): Bazy danych często lepiej reagują na ustawienie THP=never lub madvise, ponieważ nieplanowana defragmentacja i przydziały THP mogą powodować skoki opóźnień. Swappiness może być idealna – jeśli jednak THP lub zasady NUMA ingerują w ten proces, pozostają Zacinanie się.

Jednostki kontenerów i grup Cgroups

Dzięki Cgroups v2 mam do dyspozycji nie tylko parametr host-swappiness, ale także inne narzędzia: memory.high powoduje łagodne odzyskiwanie pamięci, memory.max ustanawia twarde limity, a memory.swap.max ogranicza wykorzystanie pamięci wymiany dla poszczególnych obciążeń. W ten sposób zapobiegam spowalnianiu hosta przez poszczególne kontenery korzystające z pamięci wymiany. Na węźle ustawiam niskie wartości swappiness, a krytycznym obciążeniom nadaję priorytet za pomocą memory.low, aby ich hotsety dłużej pozostawały w pamięci RAM. W Kubernetes zwracam uwagę na to, jak węzeł radzi sobie z pamięcią wymiany, i najpierw testuję zmiany w pulach nieprodukcyjnych. Ważne jest całościowe spojrzenie: parametry hosta, limity cgroup i orkiestrator muszą do siebie pasować, w przeciwnym razie obciążenie przenosi się jedynie z jednego poziomu na inne.

Wdrożenie, automatyzacja i nawrót

Wprowadzam zmiany dotyczące Swappiness w sposób kontrolowany, tak jak każdą optymalizację wydajności: najpierw na niewielkiej grupie niemal identycznych węzłów (Canary), a następnie stopniowo na szerszą skalę. Systemd-sysctl lub system zarządzania konfiguracją zapewniają powtarzalne wdrażanie tych wartości. Dokumentuję wartości początkowe i docelowe, daty i godziny, hosty, których to dotyczy, oraz Metryki. Na wypadek nawrotu planuję z wyprzedzeniem odpowiednią zmianę (np. sysctl vm.swappiness=60) i zachowuję poprzednie pliki sysctl. W oknach serwisowych celowo mierzę typowe scenariusze obciążenia, aby nie pomylić zmian z wahaniami o porze dnia lub ruchem sieciowym. Tylko w ten sposób decyzje pozostają rzetelne i spójne w zespole zrozumiały.

Częste nieporozumienia i antywzorce

• „Swappiness=0 wyłącza pamięć wymiany“: Nie, jądro nadal korzysta z pamięci wymiany – ale bardzo oszczędnie.
• „Im więcej swapów, tym większe bezpieczeństwo“: Zbyt duża ilość pamięci wymiany wydłuża fazy obciążenia i maskuje wąskie gardła pamięci RAM, zamiast je eliminować.
• „Dzięki NVMe swapowanie nie ma znaczenia“: NVMe jest szybkie, ale o kilka rzędów wielkości wolniejsze od pamięci RAM. Opóźnienia są nadal odczuwalne.
• „Jedna wartość dla wszystkich serwerów“: Obciążenia są bardzo zróżnicowane. Bez pomiarów optymalizacja sprowadza się do przypadku.
• „Swappiness rozwiązuje każdy problem z opóźnieniami“: Często problemy wynikają z trafień w pamięci podręcznej, operacji writeback, THP, planów zapytań lub ścieżek sieciowych.

Podsumowanie dla szybkiego startu

Zazwyczaj ustawiam wartość vm.swappiness na 10–20 dla serwerów WWW i na 0–10 dla baz danych, testuję efekt i obserwuję operacje wejścia/wyjścia, opóźnienia oraz Zamiana-udział. Ostateczną wartość zapisuję za pomocą sysctl w pliku /etc/sysctl.d/ i dbam o to, by zmiany były przejrzyste. Równolegle dbam o odpowiednią konfigurację partycji swap: odpowiedni rozmiar, szybki nośnik, sensowne priorytety. W przypadku obciążenia pamięci zwracam dodatkowo uwagę na pamięć podręczną stron (Page Cache) i jej zachowanie; dobrym punktem wyjścia jest ten przegląd dotyczący Usuwanie danych z pamięci podręcznej stron, który pomaga mi w analizie przyczyn oraz Kontekst istnieje. Dzięki takiemu podejściu uzyskuję niezawodne czasy odpowiedzi, zapobiegam nagłym wzrostom obciążenia pamięci wymiany i efektywnie wykorzystuję dostępną pamięć RAM.