Restartujesz serwer VPS, wszystko wstaje poprawnie, ale przez pierwsze 15 minut strony internetowe ładują się w nieskończoność, a konsola ledwo reaguje na wpisywane komendy. Brzmi znajomo? Problemem jest skokowy wzrost wskaźnika Load Average. Najczęstszym winowajcą w środowiskach hostingowych jest oprogramowanie antywirusowe – z naciskiem na popularnego, darmowego ClamAV.
Podczas startu systemu demon ClamAV ładuje do pamięci RAM potężne, ważące setki megabajtów bazy sygnatur wirusów. W tym artykule rozwiążemy ten problem, wdrażając nowoczesne limity zasobów (Cgroups v2) i odpowiednio konfigurując przestrzeń wymiany (SWAP).
Izolacja zasobów: Okiełznanie ClamAV
Zamiast pozwalać antywirusowi na „zjadanie” 100% procesora przy starcie, zamkniemy go w wirtualnej klatce za pomocą menedżera usług Systemd.
Najbezpieczniejszą metodą na nadpisanie domyślnej konfiguracji usługi jest użycie wbudowanego edytora systemowego. Wpisz w terminalu:
sudo systemctl edit clamav-daemonOtworzy się pusty plik (tzw. drop-in). Wklej w nim poniższe linie dokładnie pomiędzy wyznaczonymi komentarzami:
[Service]
IOSchedulingPriority=7
CPUSchedulingPolicy=idle
CPUQuota=20%
Nice=19
MemoryHigh=1G
MemoryMax=1.5GCo dokładnie oznaczają te parametry? (Wyjaśnienie):
IOSchedulingPriority=7 i Nice=19 – spychanie procesu na absolutny margines. System operacyjny obsłuży zadania ClamAV tylko wtedy, gdy żaden inny proces (np. Twój serwer WWW) nie będzie niczego potrzebował.
CPUSchedulingPolicy=idle – usługa dostanie czas procesora tylko wtedy, gdy serwer dosłownie „nudzi się” (stan bezczynności).
CPUQuota=20% – twardy kaganiec. Nawet jeśli serwer jest pusty, ClamAV nigdy nie przekroczy 20% użycia jednego rdzenia procesora.
Ważne (Nowość dla Cgroups v2): W starszych poradnikach zalecano przestarzały parametr MemoryLimit=256M. Dziś same bazy wirusów są na to zbyt ciężkie i system ubiłby antywirusa (błąd OOM Killer). Zamiast tego używamy MemoryHigh=1G (miękki limit – system zacznie agresywnie zrzucać pamięć antywirusa na dysk) oraz MemoryMax=1.5G (ostateczny limit bezpieczeństwa).
Zapisz zmiany i zrestartuj demona, aby nowe zasady weszły w życie:
sudo systemctl daemon-reload
sudo systemctl restart clamav-daemonKoło ratunkowe, czyli przestrzeń wymiany (SWAP)
Nawet z najlepszymi limitami, małe serwery VPS (np. z 2 GB RAM) mogą dostać zadyszki, gdy usługa próbuje załadować dużo danych. Musimy stworzyć tzw. SWAP – plik na dysku twardym, który udaje pamięć RAM. Jest on znacznie wolniejszy, ale ratuje serwer przed zawieszeniem.
Zalecam utworzenie pliku wymiany o wielkości równej ilości Twojego RAM-u. Użyjemy do tego polecenia dd (jest bezpieczniejsze niż szybsze fallocate, które potrafi sprawiać problemy na nowoczesnych systemach plików jak Btrfs czy ZFS):
sudo dd if=/dev/zero of=/swapfile bs=1M count=2048 status=progress
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfileGdzie count=2048 oznacza 2 GB (2048 Megabajtów).
Aby SWAP włączał się sam po każdym restarcie, musimy dopisać go do tabeli partycji:
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstabPrawda o parametrze „Swappiness” w nowoczesnym Linuxie
W wielu starszych poradnikach przeczytasz, że modyfikacja parametru vm.swappiness kontroluje procent zajętości RAM-u, przy którym system zaczyna zrzucać dane na dysk. W nowoczesnych systemach (jądra z serii 6.x) jest to mit.
Obecnie jądro Linuxa używa zaawansowanego algorytmu, a parametr swappiness to po prostu „waga” w decydowaniu, co usunąć z przepełnionego RAM-u. Domyślna wartość to 60.
Zmniejszając tę wartość (np. do 10), mówisz systemowi: „Nie wyrzucaj na dysk uśpionych aplikacji, lepiej skasuj z RAM-u zbuforowane pliki”.
Jeśli zjedziesz do 0, system zacznie zabijać procesy, zanim użyje SWAPu.
sudo sysctl vm.swappiness=10Aby zmiana przetrwała restart, dodaj ją do konfiguracji:
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.confPodsumowanie
Wysoki Load Average po restarcie to nie wada serwera VPS, lecz wynik walki potężnych usług o ograniczone zasoby w pierwszych sekundach działania. Wdrażając nowoczesne limity cgroups (systemctl edit) oraz zapewniając bufor bezpieczeństwa w postaci SWAP-u, sprawisz, że Twój serwer będzie uruchamiał się płynnie, a usługi takie jak WWW czy poczta będą działać błyskawicznie, podczas gdy „ciężkie demony” spokojnie załadują się w tle.
Artykuł pierwotnie opublikowany na stronie botset.pl dnia 29.07.2021 roku. Tekst został poddany gruntownej aktualizacji – dostosowano limity RAM do współczesnych wymagań oprogramowania, wprowadzono nowoczesną składnię limitów Systemd (cgroups v2) oraz wyjaśniono mechanikę MGLRU dla parametru swappiness w najnowszych wersjach jądra Linux.