Swap Usage Server: Optymalizacja wydajności hostingu

Pokażę ci, jak kontrolować serwery wykorzystujące swap w ukierunkowany sposób, tak aby obciążenia hostingu nie zacinały się pod obciążeniem i nie Wykonanie problemy ze spustem. Wyjaśniam przyczyny, kluczowe dane, ustawienia podmiany, zalecenia dotyczące rozmiaru i praktyczne kroki dostrajania dla pamięć zamiana hostingu.

Punkty centralne

• Swappiness Redukcja: Unikaj agresywnego outsourcingu
• Rozmiar sprawdzić: Wyrównaj swap do pamięci RAM i obciążenia
• IO chronić: Umieszczenie dysku SSD, świadome korzystanie z Zswap/ZRAM
• Monitoring ustanowić: Błędy stron, kswapd, opóźnienie
• Obciążenia adapt: Równoważenie buforów pamięci podręcznej i DB

Co tak naprawdę robi swap - i kiedy spowalnia pracę

Swap rozszerza fizyczną pamięć RAM, przenosząc rzadko używane strony na SSD lub HDD i chroni procesy przed zabójcą OOM, co pomaga mi w sytuacjach awaryjnych. Bufor daje. Linux oportunistycznie odciąża, aby zapewnić aktywnym stronom więcej miejsca i zachować pamięć podręczną stron, ale zbyt duża aktywność zwiększa obciążenie pamięci podręcznej. IO-obciążenie. Gdy tylko system często przełącza się między pamięcią RAM a swapem, istnieje ryzyko thrashingu, a tym samym zauważalnego opóźnienia. Zwłaszcza w przypadku ciężkiego hostingu z PHP, bazą danych i Node.js, pamięć podręczna, pracownik PHP i bufor DB konkurują o pamięć. Dlatego też utrzymuję swap jako siatkę bezpieczeństwa, ale minimalizuję jego użycie podczas normalnej pracy.

Rozpoznawanie symptomów wysokiego użycia swapów

Najpierw sprawdzam darmowy -h i vmstat, ponieważ wysokie wskaźniki swap-in/swap-out wskazują na wąskie gardła. Jeśli wskaźniki pozostają niskie, a pamięć RAM jest wolna, system zwykle działa normalnie i używa wymiany tylko oportunistycznie. Jeśli jednak wskaźniki błędów stron i kolejka IO wzrosną, opóźnienie aplikacji wzrośnie, a żądania staną się wolniejsze. W dziennikach widzę wskazania zajętych pracowników i powolnych zapytań, które pojawiają się w tym samym czasie, co szczyty swapów. Aby uzyskać więcej informacji na temat pamięci wirtualnej, odsyłam do tego kompaktowego wprowadzenia do pamięć wirtualna, co pomaga mi w kategoryzacji.

Zalety i zagrożenia związane z hostingiem wymiany pamięci

Używam swapu do amortyzowania szczytów pamięci RAM i utrzymywania działania krytycznych usług, co w krótkim okresie może być bardzo przydatne. Awaria jest unikane. Oznacza to, że mniejsze instancje VPS mogą zarządzać mniejszą ilością pamięci RAM, co może obniżyć koszty w euro, o ile obciążenie IO pozostaje w granicach limitów. Jeśli jednak wymieniana jest zbyt duża ilość, SSD/NVMe wyraźnie ustępuje pamięci RAM, a żądania zatrzymują się. Ponadto kompresja (ZRAM) kosztuje czas procesora, który aplikacje wolałyby wykorzystać do rzeczywistej pracy. Swap nie jest więc dla mnie zamiennikiem, ale zabezpieczeniem, które aktywnie kontroluję.

Swappiness: najważniejsza śruba regulacyjna

Zmienna jądra vm.swappiness (0-100, domyślnie zwykle 60) kontroluje, jak wcześnie system odciąża strony, a ja zmniejszam go do 10 dla obciążeń hostingowych. Tymczasowo testuję z sysctl vm.swappiness=10, Piszę na stałe vm.swappiness=10 w /etc/sysctl.conf. Na hostach SSD skutkuje to mniejszą wymianą i większą ilością miejsca na pamięć podręczną stron. Następnie monitoruję IO, opóźnienia i zestawy robocze, aby potwierdzić efekt. Jeśli kluczowe liczby pozostają stabilne, zachowuję ustawienie i dokumentuję zmianę do późniejszych audytów.

Optymalny rozmiar wymiany dla popularnych serwerów

Dostosowuję rozmiar wymiany do pamięci RAM, obciążenia i ewentualnej hibernacji, ponieważ znajduję pliki, które są zbyt duże Pamięć a zbyt małe pliki zmniejszają bufor. W przypadku typowych serwerów hostingowych bez hibernacji planuję umiarkowane wartości i przedkładam więcej pamięci RAM nad ogromne wolumeny wymiany. W przypadku rzadkich instancji VPS, 1,5-2x RAM może mieć sens, dopóki nie będzie możliwa prawdziwa aktualizacja. Jeśli masz dużo pamięci RAM, często korzystasz z mniejszych, ale dostępnych obszarów wymiany, aby uniknąć awarii. Używam poniższej tabeli jako punktu wyjścia i dostosowuję ją do zmierzonych wartości:

Rozmiar pamięci RAM	Wymiana bez hibernacji	Zamiana z hibernacją
≤ 2 GB	2x RAM	3x RAM
2-8 GB	= RAM	2x RAM
8-64 GB	4–8 GB	1,5x RAM
> 64 GB	4 GB	Niezalecane

Umieszczanie swapów i zaawansowane techniki

Wolę pliki wymiany niż partycje, ponieważ mogę dynamicznie dostosowywać rozmiary i szybciej wprowadzać zmiany. na żywo go. Jeśli obszar wymiany znajduje się na oddzielnym dysku SSD, w mniejszym stopniu konkuruje z systemem operacyjnym o IO. W przypadku bardzo małych maszyn wirtualnych używam Zswap lub ZRAM jako testu w celu zmniejszenia IO, ale bacznie obserwuję wykorzystanie procesora. Ograniczam nadmierne zaangażowanie i ustawiam limity dla usług, aby żaden proces nie doprowadził maszyny do awarii. Ostatecznie liczy się wymierny efekt: mniejsze opóźnienia, cichsze IO i spójne czasy odpowiedzi.

Monitorowanie: które kluczowe dane naprawdę się liczą

Mierzę wykorzystanie pamięci RAM, pamięci podręcznej stron, swap in/out, aktywność kswapd i kolejki IO, ponieważ te wartości wysyłają mi sygnały na wczesnym etapie. Jeśli ruch wymiany wzrasta, koreluję to z opóźnieniami aplikacji i czasami zapytań. Sprawdzam również błędy strony mniejszej/większej, aby rozpoznać kosztowne dostępy do pamięci. Aby pomóc mi zrozumieć strategie buforowania, używam tego przewodnika do Wykorzystanie bufora i pamięci podręcznej. Interweniuję i zmieniam ustawienia tylko wtedy, gdy wskaźniki i dzienniki pokazują stałą presję.

Jak jądro wybiera strony: głębsze spojrzenie na Reclaim

Aby dostroić się w ukierunkowany sposób, rozumiem wewnętrzne listy: Linux rozróżnia anonimowe strony (sterty/stacki) i strony obsługiwane przez pliki (pamięć podręczna stron). Obie są dołączone do list LRU (aktywne/nieaktywne). Jeśli pamięć jest pod presją, jądro najpierw próbuje odrzucić nieaktywne strony oparte na plikach (szybko, ponieważ można je ponownie załadować z dysku). Jeśli zbyt wiele anonimowych stron jest aktywnych, musi przenieść je do swapu - jest to bardziej kosztowne. Wysoki vm.vfs_cache_pressure Przyspiesza odrzucanie ząbków/węzłów, co zwalnia miejsce, ale może prowadzić do większej liczby dostępów do plików na serwerach internetowych. Zwykle utrzymuję go na poziomie około 50-100 i obserwuję, jak zmienia się współczynnik trafień pamięci podręcznej i opóźnienia.

Wpływam na ścieżki pisania poprzez vm.dirty_background_bytes/vm.dirty_bytes (lub warianty proporcji). Zbyt wysokie limity brudnej pamięci tylko odsuwają problem w czasie, a później generują duże zapisy zwrotne, które spowalniają odzyskiwanie swapów. Preferuję limity oparte na bajtach, ponieważ działają one bardziej precyzyjnie na dużych systemach RAM. Innym rozwiązaniem jest vm.min_free_kbytesJeśli ta wartość jest ustawiona zbyt nisko, odzyskiwanie działa w gorączkowych cyklach; zbyt wysoka, marnuje pamięć RAM. Zwykle pozostawiam tę wartość na domyślnym poziomie dystrybucji, chyba że konsekwentnie widzę „niskie wolne znaki wodne“ w dmesg.

PSI i kswapd: Prawidłowa interpretacja wskaźników wyprzedzających

Oprócz klasycznych wskaźników, używam Informacje dotyczące przeciążenia na stronie /proc/pressure/memory. Wysoki niektóre lub pełny Wartości powyżej kilku sekund pokazują mi, że zadania oczekują na pamięć. Jest to często pierwsza oznaka, zanim użytkownicy zauważą opóźnienia. W tym samym czasie patrzę na czas procesora CPU kswapdJeśli stale wzrasta powyżej kilku procent, Reclaim działa na gorąco. Z vmstat 1 Zwracam uwagę na si/Tak więc (swap-in/out) i r/b (kolejka run/block). Konsekwentnie wysoki Tak więc-wartości wraz z rosnącymi b-wtedy konsekwentnie interweniuję.

Cgroups v2 i systemd: Celowe ograniczenie swapów

W środowiskach z wieloma dzierżawcami lub kontenerami zapobiegam sytuacji, w której pojedyncza usługa pochłania wszystkie rezerwy. W cgroups v2 ustawiam memory.max (twardy limit), memory.high (miękkie ssanie) i memory.swap.max (limit wymiany). Pod systemd używam per usługa MemoryMax=, MemoryHigh= oraz MemorySwapMax= w nadpisaniach jednostek. Oznacza to, że PHP-FPM nie może doprowadzić całego systemu do swapu, podczas gdy bazy danych pozostają reaktywne. W przypadku serii, wąski memory.high plus umiarkowany MemorySwapMax=, zamiast ryzykować ciężkie OOM. Dokumentuję te limity dla każdej usługi i aktualizuję je w procesie przeglądu.

Twórz, powiększaj i nadawaj priorytety plikom wymiany w czysty sposób

W praktyce potrzebuję szybkich, powtarzalnych kroków:

• Utwórz plik wymiany: fallocate -l 8G /swapfile && chmod 600 /swapfile && mkswap /swapfile
• Aktywuj: swapon /swapfile; na stałe przez /etc/fstab z /swapfile none swap sw,pri=5 0 0
• Dostosuj rozmiar: swapoff /swapfile, fallocate -l 12G /swapfile, mkswap /swapfile, swapon /swapfile
• Wielokrotna wymiana: szybsza NVMe z wyższą wydajnością pri ustalać priorytety; z swapon --show --output=NAME,PRIO,SIZE,USED kontrola

Na bardzo słabych systemach IO wolę zmniejszyć rozmiar swapu lub umieścić go na szybszych nośnikach danych, niż pozwolić systemowi powoli „zamienić się na śmierć“.

Zswap i ZRAM: kiedy kompresja naprawdę pomaga

Zswap kompresuje strony do wymiany w puli opartej na pamięci RAM, a tym samym zmniejsza fizyczne IO. Chroni to dyski SSD, ale kosztuje czas procesora. W przypadku maszyn wirtualnych z kilkoma rdzeniami najpierw testuję lz4 (szybka, słabsza kompresja) i obserwuję, czy szczyty CPU rosną. Selektywnie zastępuję ZRAM klasycznym swapem w bardzo małych instancjach, aby pozostać prawie bez IO - planuję na to więcej CPU. Celowo utrzymuję małą kompresję (np. 25-50% RAM dla ZRAM), aby uniknąć tworzenia nowych wąskich gardeł. Gdy tylko obciążenia związane z procesorem zaczną się potykać, zmieniam tę optymalizację.

THP i fragmentacja: ukryte hamulce opóźnień

Transparent Huge Pages (THP) może pomóc w przypadku maszyn JVM lub baz danych, ale może również obciążać odzyskiwanie i wymianę w mieszanych środowiskach hostingowych. Używam THP na madvise, tak, aby korzystały z niej tylko te obciążenia, które wyraźnie jej używają. W przypadku zauważalnej fragmentacji pamięci, planuję kroczące restarty usług intensywnie korzystających z pamięci, aby wyczyścić sterty, które zostały wystrzelone. W przypadku MySQL/MariaDB sprawdzam również, czy pula buforów InnoDB jest wystarczająco duża w stosunku do całkowitej pamięci, aby Linux page cache nie głodował - zduplikowane cache kosztują RAM i niepotrzebnie zwiększają swap.

NUMA i hosty wielogniazdowe

NUMA odgrywa rolę na większych hostach bare-metal. Niezrównoważony dostęp do pamięci zwiększa opóźnienia i przyspiesza odzyskiwanie. Rozdzielam obciążenia pomiędzy numactl --interleave=all lub przypiąć określone usługi do węzła. Utrzymuję krytyczne usługi, które wyzwalają wiele dostępów do pamięci podręcznej stron (np. Nginx) w pobliżu ścieżek danych; hermetyzuję zadania wsadowe wymagające dużej ilości pamięci i w razie potrzeby nadaję im ściślejsze limity cgroup, aby przepełnienia NUMA nie zepchnęły całego systemu na swap.

Diagnostyka procesów: kto tak naprawdę wymienia?

Kiedy wskaźniki systemowe włączają alarm, identyfikuję przyczyny na poziomie procesu: smem -knr pokazuje mi PSS/USS (realistyczne udziały pamięci), pmap -x rozkład segmentów. W /proc//status Sprawdzam VmRSS, VmSwap oraz oom_score_adj. Wysoki VmSwap-wartości dla wzorców nieprzyjaznych LRU (wiele anonimowych, mało używanych stron) są kandydatami do ograniczeń lub optymalizacji kodu. Używam również pidstat -r 1, aby zobaczyć wskaźniki błędów na proces i porównać je z opóźnieniami aplikacji.

Runbooki, SLO i poziomy eskalacji

Definiuję wyraźne wartości graniczne dla każdej klasy hosta, np.: kswapd-CPU < 5% w średniej 5-minutowej, główne błędy < 50/rdzeń podczas normalnej pracy, pamięć PSI niektóre < 10% powyżej 60s. Jeśli dwie metryki są uszkodzone w tym samym czasie, interweniuję w następującej kolejności: sprawdzam swappiness, tymczasowo dławię pracowników/bufory, dostosowuję rozmieszczenie i priorytety swapów, (de)aktywuję kompresję, w razie potrzeby zwiększam pamięć RAM. Te runbooki są częścią mojej reakcji na incydenty, dzięki czemu zespoły mogą działać w powtarzalny sposób i Opóźnienie pozostaje pod kontrolą.

Rozwiązywanie problemów: typowe przyczyny i szybkie rozwiązania

Jeśli szybkość wymiany wzrasta, najpierw sprawdzam usługi wymagające dużej ilości pamięci i ograniczam je za pomocą cgroups lub ustawienia usługi. Następnie sprawdzam, czy nie ma zbyt wielu pracowników PHP, zbyt dużych buforów DB lub zbyt małej pamięci podręcznej stron. Zmniejszam swappiness, porządkuję tymczasowe cache i przenoszę rotacje logów z godzin szczytu. Jeśli kolejka IO pozostaje stale wysoka, przenoszę swap lub zmniejszam go, aby zminimalizować konkurencję IO. Jeśli to nie wystarczy, zwiększam pamięć RAM i mierzę ponownie, aż opóźnienie pozostanie stabilne na niskim poziomie.

Tuning dla PHP, baz danych i Node.js

W przypadku PHP maksymalizuję trafienia pełnostronicowe lub OPcache, aby mniej pamięci RAM było używane do wielokrotnej kompilacji, a tym samym Czas reakcji spadki. W MySQL/MariaDB równoważę pulę buforów i pamięć podręczną zapytań z pamięcią podręczną stron, aby uniknąć podwójnego buforowania. W przypadku Node.js ustawiam limity dla sterty i monitoruję odśmiecanie, tak aby Pętla zdarzeń nie słabnie. Zapobiegam również fragmentacji pamięci poprzez wdrożenia, które regularnie restartują usługi i wykrywają wycieki. Krótkie, dogłębne spojrzenie na Fragmentacja pamięci pomaga szybciej wykrywać takie problemy.

Kontenery i stosy hostingowe: praktyczne przykłady

W środowiskach kontenerowych ustawiam twardy limit pamięci na kapsułę lub usługę i zezwalam tylko na umiarkowaną ilość wymiany. W przypadku PHP-FPM obliczam pamięć na pracownika (RSS) plus zapas na pamięć podręczną strony. Przykład: 512 MB RAM, 30 MB/worker realnego zużycia - wtedy 8-10 workerów jest realistyczne, a nie 20. Dla Node.js ustawiam --max-old-space-size Celowo poniżej fizycznego limitu, aby GC nie był pod presją, a jądro nie agresywnie wymieniało anonimową pamięć. W przypadku baz danych planuję stałe budżety, oddzielam je od warstwy internetowej tam, gdzie to możliwe i daję systemowi operacyjnemu wystarczająco dużo miejsca na pamięć podręczną plików.

Koszty, sprzęt i kiedy zaktualizować pamięć RAM

Obliczam równoważne wartości w euro: Jeśli drukowanie swapów tworzy stałe opóźnienie, dodatkowa pamięć RAM szybko uzasadnia cenę i tworzy rzeczywiste opóźnienie. Wydajność. NVMe zmniejsza opóźnienia we/wy, ale nie zastępuje pamięci lotnej. Zanim rozbuduję sprzęt, optymalizuję swappiness, bufory i liczbę pracowników, aby zwiększyć wydajność. Jeśli wykorzystanie pozostaje wysokie, planuję skok pamięci RAM w rozsądnych etapach, zamiast po prostu zwiększać swap. Taka sekwencja zapobiega złym inwestycjom i daje mi jasne punkty pomiarowe do późniejszych porównań.

Sprawdzenie: wymiana serwera w ciągu 15 minut

Zaczynam od free -h, vmstat 1 i sprawdzić Zamiana-ruch, błędy stron i kolejki IO. Następnie ustawiłem vm.swappiness=10, obciążenie sysctl i obserwuję kluczowe dane przez pięć minut. Jeśli pasuje, zapisuję ustawienie i dokumentuję bieżący stan. W następnym kroku poprawiam liczbę pracowników i bufory DB, które wypierają pamięć podręczną stron. Na koniec tworzę alarmy, które ostrzegają mnie przed wartościami odstającymi, zanim zauważą je użytkownicy.

Krótkie podsumowanie

Używam Swap jako uprzęży bezpieczeństwa, ale utrzymuję jej użycie na niskim poziomie, aby Opóźnienie nie eksploduje i nie występują żadne problemy z wydajnością. Największą dźwignią pozostaje rozsądna wymiana, w połączeniu z rozmiarem wymiany, który pasuje do pamięci RAM i obciążenia. Monitoruję kswapd, błędy stron i kolejkę IO, porównuję wartości z dziennikami aplikacji i działam wcześnie. W przypadku mniejszych serwerów VPS zamiana pamięci hostingu łagodzi presję w krótkim okresie, podczas gdy prawdziwa ulga przychodzi wraz z większą ilością pamięci RAM. Postępowanie zgodnie z tą sekwencją zapewni responsywność serwerów, skróci przestoje i ochroni budżety.