vm.vfs_cache_pressure – jak optymalnie wykorzystać pamięć podręczną systemu plików w Linuksie

Pokażę, jak działa parametr jądra vm.vfs_cache_pressure jakie znaczenie ma bufor VFS w porównaniu z buforem stron oraz jakie wartości zapewniają większą szybkość przy rzeczywistym profilu obciążenia. Wyraźnie dostosowuję to ustawienie, mierzę efekty i w ten sposób wykorzystuję Pamięć podręczna systemu plików optymalnie.

Punkty centralne

Aby szybko zacząć, podsumuję najważniejsze aspekty związane z tuningiem Pamięci podręczne VFS razem. W ten sposób przy wyborze wartości mam na uwadze wpływ na wyszukiwanie metadanych, obciążenie wejścia/wyjścia oraz obciążenie pamięci RAM. Te punkty pomagają mi w bezpiecznej i powtarzalnej optymalizacji typowych ról serwerowych.

• Zasada działania: Określa, z jaką stanowczością jądro zwalnia dentries/i-węzły w porównaniu z pamięcią podręczną stron.
• Ustawienie domyślne: 100 oznacza wyważoną korektę bez faworyzowania.
• Niskie wartości: Wartości 50–80 powodują, że metadane są dłużej przechowywane w pamięci RAM i przyspieszają wyszukiwanie plików.
• Wysokie wartości: Wartości 120–200 powodują szybsze zwalnianie pamięci podręcznej VFS i zwalniają miejsce dla procesów.
• Praktyka: Zmieniaj stopniowo, mierz, dokumentuj – dopiero potem wprowadzaj kolejne poprawki.

Konsekwentnie stosuję te zasady, aby zachować właściwą równowagę między Współczynnik trafień pamięci podręcznej i wolnej pamięci RAM. Następnie stopniowo dostosowuję wartość vm.vfs_cache_pressure, obserwuję szczyty obciążenia i w razie potrzeby wprowadzam korekty. W ten sposób uzyskuję stabilne czasy reakcji bez nieoczekiwanych ograniczeń pamięciowych.

Czym jest vm.vfs_cache_pressure?

Ten parametr określa, jak rygorystycznie jądro traktuje Pamięć podręczna VFS w porównaniu z innymi pamięciami zwalnia miejsce, gdy tylko zaczyna brakować pamięci RAM. W pamięci podręcznej VFS trafiają dentries i i-węzły, czyli wpisy katalogowe i metadane plików, co zauważalnie przyspiesza wyszukiwanie plików. Wartość 100 traktuje pamięć podręczną VFS i pamięć podręczną stron w ten sam sposób, podczas gdy niższe wartości preferują przechowywanie metadanych w pamięci RAM. Wyższe wartości powodują, że jądro szybciej odrzuca wpisy VFS i szybciej zwalnia pamięć. Wykorzystuję tę opcję celowo, aby utrzymać wysoki odsetek trafień metadanych w obciążeniach związanych z siecią, plikami i systemami CMS, nie wypierając przy tym procesów. W ten sposób kontroluję równowagę między Tempo wyszukiwania i wolnej pamięci operacyjnej w bardzo bezpośredni sposób.

Jak dokładnie działa pamięć podręczna VFS?

Wirtualny system plików stanowi wspólną warstwę dla systemów plików ext4, XFS, Btrfs i innych oraz przechowuje Dentries oraz i-węzły w pamięci RAM, dzięki czemu skanowanie katalogów i powtarzające się operacje dostępu przebiegają sprawnie. Z kolei pamięć podręczna stron przechowuje właściwe bloki plików; obie pamięci podręczne uzupełniają się, ale w warunkach obciążenia konkurują o pamięć. Im więcej małych plików i częstych, powtarzających się operacji dostępu, tym większe korzyści odnosi aplikacja dzięki wysokiemu współczynnikowi trafień metadanych. Właśnie tutaj działa vm.vfs_cache_pressure: to ja decyduję, czy system Linux zachowa te metadane, czy też szybko je wyrzuci. Aby zgłębić aspekty związane z pamięcią podręczną stron, stosuję dodatkowo kompaktny Narzędzie poprawiające wydajność pamięci podręcznej stron jako podstawową wiedzę, aby móc właściwie ocenić działanie pamięci VFS i pamięci podręcznej stron w odpowiednim kontekście.

Wartość domyślna i typowe zakresy wartości

W większości systemów wartość ta wynosi 100 i stanowi w ten sposób zrównoważoną podstawę do pierwszych testów. Jeśli obniżę tę wartość, nadaję pierwszeństwo metadanym i stabilizuję szybkie wyszukiwanie, co sprawdza się zwłaszcza w przypadku wielu małych plików. Jeśli zwiększę tę wartość, Linux szybciej usuwa wpisy VFS i tworzy więcej bufora dla aplikacji lub pamięci podręcznej stron. Z wartościami skrajnymi, takimi jak 0 lub powyżej 500, obchodzę się bardzo ostrożnie, ponieważ mogą one wywołać gwałtowne zachowanie systemu i spowodować niepożądane skutki uboczne. Na co dzień zaczynam od wartości 100, zwiększam ją stopniowo o 20–40 punktów i mierzę wpływ na Opóźnienie IO oraz czasy odpowiedzi.

Wartość	Znaczenie	Kiedy używać	Ryzyko/Uwaga
< 100 (np. 50–80)	Pamięć podręczna VFS pozostaje dłużej w pamięci RAM	Wiele małych plików, częste wyszukiwania	Zwiększenie przydziału pamięci RAM do Metadane
100	Zrównoważona korekta	Solidna wartość początkowa do pomiarów	Dobry Linia bazowawartość ‑
> 100 (np. 120–200)	Pamięć podręczna VFS jest zwalniana w sposób bardziej agresywny	Niewielka ilość pamięci RAM, bazy danych z własną pamięcią podręczną	Możliwe opóźnienie wyszukiwania
Ekstremalne (0, > 500)	Poważne zmiany	Przypadki szczególne – krótkie sprawdzenie	Zagrożenie dla stabilności i Wydajność

Dzięki tej siatce szybko rozpoznaję, który kierunek jest właściwy, nie zbaczając przy tym z kursu. Unikam dużych skoków i szczegółowo dokumentuję każdą zmianę. Dzięki temu zawsze mam jasny obraz przebytej drogi i zachowuję przejrzystość porównania z poprzednimi punktami pomiarowymi.

Rola w procesie czyszczenia pamięci

W sytuacji obciążenia jądro musi zwolnić pamięć RAM i właśnie w tym miejscu vm.vfs_cache_pressure określa proporcje między Pamięć podręczna VFS, pamięć podręczna stron i pamięć procesów. Niskie wartości powodują, że wpisy katalogowe i i-węzłów pozostają dłużej w pamięci, co przyspiesza obsługę wywołań katalogów i wielokrotnego otwierania plików. Wysokie wartości powodują wcześniejsze zwolnienie pamięci i zapewniają więcej miejsca dla procesów lub pamięci podręcznej stron, co może być pomocne w przypadku ograniczonej ilości pamięci RAM. W tym kontekście zwracam szczególną uwagę na opóźnienia operacji wejścia/wyjścia (IO), ponieważ zbyt pusta pamięć podręczna metadanych spowalnia wyszukiwanie plików. Jeśli chodzi o współdziałanie ze strategiami zwalniania pamięci podręcznej stron, ta analiza dostarcza mi informacji na temat Usuwanie danych z pamięci podręcznej stron cenne odniesienia do praktyki, dzięki którym będę podejmować decyzje w oparciu o fakty.

Metodologia pomiaru: zapewnienie przejrzystości pamięci podręcznej VFS

Zanim wprowadzę zmiany, zaznaczam, gdzie pamięć znajduje się w i co zostaje wypierane. W ten sposób mogę stwierdzić, czy to właśnie metadane stanowią prawdziwe wąskie gardło – czy też dominującą rolę odgrywają pamięć podręczna stron, procesy lub brudne strony.

• /proc/meminfo: Sprawdzam wartości InodeCache, Cached, Buffers, SReclaimable i SUnreclaim, aby oszacować udział i możliwość odzyskania.
• slabtop: Podgląd na żywo bloków (slabów), w szczególności dentry, inode_cache, ext4_inode_cache, xfs_inode. Dzięki temu widzę, czy rozmiary dentry i inodów rosną lub maleją.
• Ścieżka IO: Za pomocą vmstat/iostat monitoruję opóźnienia odczytu oraz to, czy podczas wyszukiwań wzrasta liczba operacji dostępu do dysków.

# Szybki przegląd
grep -E 'InodeCache|SReclaimable|SUnreclaim|Cached|Buffers' /proc/meminfo

# Rozkład slabów (posortowany według rozmiaru)
sudo slabtop -s c

# Filtrowanie wyłącznie slabów typu dentry/inode
grep -Ei 'dentry|inode' /proc/slabinfo | sort -k3 -nr | head

# Trendy dotyczące operacji wejścia/wyjścia i pamięci w odstępach sekundowych
vmstat 1
iostat -x 1

Moim zdaniem interpretacja jest jasna: jeśli SReclaimable rośnie wraz z blokami dentry/inode, a jednocześnie wydłużają się opóźnienia operacji wejścia/wyjścia nie, co potwierdza skuteczność pamięci podręcznej metadanych. Jeśli wartości te często spadają do zera, a opóźnienia przy dostępie do katalogów gwałtownie rosną, prawdopodobnie vm.vfs_cache_pressure jest ustawione zbyt agresywnie.

Praktyka: odczytanie i zmiana aktualnej wartości

Sprawdzenie to można przeprowadzić w wierszu poleceń w ciągu kilku sekund i bez Restart. Odczytuję wartość rzeczywistą i zapisuję wartości testowe najpierw tymczasowo, aby móc natychmiast wprowadzać zmiany w oknie testowym. W przypadku zmian produkcyjnych wprowadzam wpisy w pliku /etc/sysctl.conf lub w pliku w katalogu /etc/sysctl.d/, ponownie ładuję system i odnotowuję zmianę w mojej dokumentacji. Każdy poziom testuję pod realistycznym obciążeniem, a nie tylko w stanie spoczynku, aby efekty były widoczne. W ten sposób zapewniam rzetelne porównania „przed i po” oraz oceniam zmianę na podstawie mierzalnych wskaźników.

# Sprawdź aktualną wartość
cat /proc/sys/vm/vfs_cache_pressure
# lub
sysctl vm.vfs_cache_pressure

# Test tymczasowy (do momentu ponownego uruchomienia systemu)
sudo sysctl -w vm.vfs_cache_pressure=60
# alternatywnie
echo 60 | sudo tee /proc/sys/vm/vfs_cache_pressure

# Ustawienie na stałe
echo "vm.vfs_cache_pressure = 60" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Optymalizacja pamięci podręcznej w systemie Linux: praktyczne scenariusze

W przypadku platform hostingowych zawierających wiele zasobów statycznych, repozytoriów plików lub aplikacji z własną pamięcią buforową warto zastosować ukierunkowane Ważenie pamięci podręcznej VFS. Serwery WWW obsługujące wiele małych plików znacznie zyskują na niższych wartościach, ponieważ operacje wyszukiwania rzadziej trafiają na dyski SSD/HDD. Serwery plików z plikami o zróżnicowanych rozmiarach mogą korzystać z umiarkowanie obniżonych wartości, o ile dostępna jest wystarczająca ilość pamięci RAM. Serwery baz danych o dużym obciążeniu pamięci RAM i dużej pamięci podręcznej bazy danych preferują wyższe wartości, aby zapewnić procesom wystarczającą przestrzeń. Oceniam te wzorce na podstawie danych monitorowania, aby ustawienia były dostosowane do rzeczywistego rozkładu dostępów.

Serwer WWW z dużą liczbą plików statycznych

W przypadku plików CSS, JS i obrazów chętnie przechowuję metadane przez dłuższy czas w Schowek. Wartości z przedziału od 50 do 80 często sprawdzają się w tej sytuacji, ponieważ ponowne otwieranie plików przebiega szybciej. Dokładnie sprawdzam szczytowe obciążenia wejścia/wyjścia podczas skoków ruchu i porównuję czasy odpowiedzi przed i po wprowadzeniu zmiany. Jeśli opóźnienia pozostają stabilne, a koszty wyszukiwania 404 maleją, oznacza to, że zmiana jest właściwa. Monitoruję wykorzystanie pamięci RAM, aby procesy miały wystarczającą ilość miejsca pomimo większej pamięci podręcznej metadanych.

Serwery plików lub systemy NAS

Duża liczba odwiedzin i zmiany katalogów przynoszą korzyści dzięki niższy aż do osiągnięcia zrównoważonych wartości. Jeśli mam wystarczającą ilość pamięci RAM, ustawiam raczej wartości w przedziale 50–80; przy mniejszej ilości pamięci trzymam się bliżej 100. Sprawdzam, czy wyświetlanie zawartości katalogów przebiega płynnie i czy migawki/kopie zapasowe nie zajmują zbyt dużo miejsca w pamięci podręcznej. Jeśli opóźnienie operacji wejścia/wyjścia wzrasta w okresach szczytowego obciążenia, ostrożnie zwiększam tę wartość. W ten sposób zachowuję równowagę między komfortem pracy a wolną pamięcią RAM.

Serwery baz danych i systemy o niewielkiej pojemności pamięci

Bazy danych utrzymują własną pamięć podręczną, dlatego przekazuję do Pamięć procesowa zazwyczaj ma pierwszeństwo. Wartości od 120 do 200 sygnalizują, że należy raczej opróżniać pamięć podręczną VFS i zwalniać pamięć RAM. Zwracam przy tym uwagę na opóźnienia zapytań i wzorce błędów stron w aplikacji. Jeśli baza danych zwalnia, ponieważ system zaczyna korzystać z pamięci wymiany, nieznacznie zwiększam tę wartość i jednocześnie zmniejszam vm.swappiness. Takie podejście zapobiega niepotrzebnemu zajmowaniu miejsca przez metadane, które baza danych może lepiej wykorzystać.

Przykłady obciążenia i wartości orientacyjne

Zaczynam od 100, a następnie zmniejszam o 20 w przypadku wartości zbliżonych do wartości sieciowych Obciążenia i zwiększam tę wartość w krokach co 20 dla procesów wymagających dużej ilości pamięci. Każdy poziom testuję co najmniej podczas jednej fazy szczytowej, aby móc zaobserwować wpływ na opóźnienia, trafienia w pamięci podręcznej i aktywność wymiany. Osoby, które chcą zagłębić się w ten temat, znajdą w zwięzłym Narzędzie poprawiające wydajność pamięci podręcznej stron Dodatkowe informacje na temat strategii buforowania plików, które biorę pod uwagę równolegle. Jeśli wartości pomiarowe i stan docelowy są zgodne, zamrażam konfigurację i dokumentuję wskaźniki. Dzięki temu optymalizacja pozostaje powtarzalna, a ja mogę później szybko wprowadzić korekty.

Ryzyko i pułapki

Jeśli ustawię zbyt niską wartość, jądro będzie miało trudności z uwolnieniem wpisów VFS, co w przypadku szczytowego obciążenia może prowadzić do OOM‑ryzyko. Jeśli ustawię go zbyt wysoko, wzrasta opóźnienie podczas wyszukiwania plików i zmiany katalogów, ponieważ metadane muszą być ponownie ładowane. Bez testów w warunkach rzeczywistego obciążenia istnieje ryzyko wyciągnięcia błędnych wniosków na podstawie spokojnych okresów. Gwałtowne skoki utrudniają ocenę, dlatego postępuję stopniowo. Każdą zmianę odnotowuję wraz z datą i godziną, profilem obciążenia oraz wartościami pomiarowymi, aby przyczyny pozostały jasne.

Monitorowanie i wskaźniki

Czy dostosowanie się opłaca, pokazują twarde Metryki. Monitoruję wykorzystanie pamięci RAM, podział między pamięciami podręcznymi a procesami, opóźnienia operacji we/wy oraz aktywność pamięci wymiany. Ponadto analizuję współczynniki trafień w pamięci podręcznej oraz trendy dotyczące błędów stron, aby szybko wykrywać efekty uboczne. Szczególnie w przypadku wielu małych plików zauważalne są poprawy w czasie do pierwszego bajtu. Jeśli opóźnienie operacji wejścia/wyjścia pozostaje na niskim poziomie, a wymiana danych w pamięci wymiany maleje, potwierdza to słuszność obranego kierunku.

Podręcznik optymalizacji: Od hipotezy do wiarygodnych ustawień

Struktura pozwala uniknąć działania na ślepo. Postępuję zgodnie z ustalonym schematem, aby wyniki były wiarygodne, a członkowie zespołu mogli zrozumieć poszczególne etapy.

1. Rejestracja wartości bazowej: vm.vfs_cache_pressure=100, realistyczne obciążenie w zakresie 24–72 godzin. Zapisanie wskaźników (opóźnienia: mediana/95./99. percentyl, czas oczekiwania IO, CPU-Steal, aktywność swapowania, rozmiar i-węzła/d-węzła).
2. Sformułowanie hipotezy: „Wiele małych plików, operacje wyszukiwania są kosztowne – niższe wartości przyspieszają działanie“ lub „Brak pamięci RAM – wyższe wartości zapewniają płynne działanie procesów“.
3. Zmieniać krok po kroku: od ±20 do ±40 punktów. Na każdym poziomie należy zmierzyć co najmniej jedną fazę szczytową.
4. Porównaj: Sprawdzam, czy wskaźniki SLO (np. 95. percentyl) rzeczywiście ulegają poprawie, bez więcej zdarzeń typu swap lub OOM.
5. Kryterium przywrócenia: Jeśli wzrosną opóźnienia 95./99., wydłużą się czasy oczekiwania na operacje wejścia/wyjścia lub zacznie się pojawiać więcej nieudanych odwołań do pamięci podręcznej, cofam się o krok.
6. Freeze i dokumentacja: Zapisać wartość końcową, datę, przedział obciążenia i wskaźniki.

# Krótki test dla kontrolowanych okien pomiarowych (tylko w ramach konserwacji!)
# Przed: Zrzut wskaźników
date; free -h; grep -E 'InodeCache|Cached' /proc/meminfo; vmstat 1 5

sudo sysctl -w vm.vfs_cache_pressure=80
# Test obciążenia / poczekać na osiągnięcie wartości szczytowej, a następnie ponownie zebrać wskaźniki i porównać je

Systemy plików i opcje montowania: kontekst ma znaczenie

Działanie funkcji vm.vfs_cache_pressure zależy również od systemu plików i opcji montowania. Oceniam te czynniki w następujący sposób:

• relatime/noatime: Zapobiega częstym operacjom zapisu atime. Opcja noatime zmniejsza obciążenie wejścia/wyjścia przy dużej liczbie operacji odczytu, co sprawia, że korzyści związane z metadanymi stają się bardziej widoczne.
• czas leniuchowania: Opóźnia aktualizację metadanych w pamięci RAM; powoduje to wygładzenie skoków, ale wpływa na momenty opróżniania pamięci.
• ext4 kontra XFS kontra Btrfs: Różne struktury iodeów i zachowanie programu Shrinker. Zawsze mierzę na docelowym systemie plików, zamiast przenosić założenia.
• NFS/Netz-FS: Buforowanie atrybutów i unieważnianie mogą ograniczać korzyści płynące z VFS. Agresywne zwalnianie (wysokie wartości) powoduje wówczas wzrost liczby zdalnych wyszukiwań.
• OverlayFS/FUSE: Wiele drobnych operacji związanych z metadanymi znacznie zyskuje dzięki pamięci podręcznej VFS; o ile jest dostępna pamięć RAM, utrzymuję te wartości raczej na umiarkowanym lub niskim poziomie.

Kwestie związane z kontenerami i grupami Cgroup

W środowiskach kontenerowych zawsze mam na uwadze, że vm.vfs_cache_pressure to na całym serwerze Przełącznik. Zmiany dotyczą wszystkie Pods/kontenery na węźle. Dlatego postępuję ostrożnie i koordynuję optymalizację na poziomie węzła.

• Limity pamięci: Grupy pamięci (Memory-Cgroups) ograniczają pamięć procesową i pamięć podręczną stron; pamięć typu slab może być uwzględniana proporcjonalnie. Obserwuję zdarzenia typu Pod-OOM i Node-Pressure w tym kontekście.
• Struktura obciążenia: Węzły, na których jednocześnie działają pody baz danych i interfejsy internetowe, nie osiągają wartości skrajnych. W razie potrzeby rozdzielam role na różne węzły.
• Rollout: Najpierw Canaries (jeden węzeł), a następnie stopniowe wdrażanie. Zmiany dokumentuję w linii bazowej węzła (sysctl.d) i odnotowuję, których wdrożeń dotyczą.

Szczególne przypadki z praktyki

Niektóre wzorce można skutecznie wyeliminować, jeśli znam ich przyczyny:

• Zadania CI/Build: Niższe wartości są korzystne w przypadku wielu krótkich operacji dostępu do plików i skanowania katalogów. Po zakończeniu zadania ponownie je zwiększam, jeśli węzły są wykorzystywane do różnych celów.
• Okno tworzenia kopii zapasowej/skanowania: Długie operacje na katalogach powodują wyczyszczenie pamięci podręcznej. Tymczasowo można wyższy Wartość (np. 180) zapobiega przepełnieniu pamięci RAM przez dentries/inody podczas tworzenia kopii zapasowej – po zakończeniu przywracam poprzednie ustawienie.
• Wpisy ujemne: Pliki, które nie istnieją (404), są również buforowane. Wydajność obciążeń internetowych, w których często występują błędy dostępu, wyraźnie wzrasta, jeśli pamięć podręczna VFS nie jest opróżniana zbyt agresywnie.
• Przesyłanie strumieniowe/sekwencyjne operacje wejścia/wyjścia: Tutaj dominuje pamięć podręczna stron; zbyt niskie wartości nie przynoszą większych korzyści i niepotrzebnie zajmują pamięć RAM. Utrzymuję wartość bliską 100 lub nieco wyższą.

# Przykład: nieco bardziej agresywne ustawienie podczas tworzenia pełnej kopii zapasowej
sudo sysctl -w vm.vfs_cache_pressure=180
# Po zakończeniu tworzenia kopii zapasowej przywróć wcześniej ustaloną wartość optymalną
sudo sysctl -w vm.vfs_cache_pressure=60

Automatyzacja i zarządzanie

Po pomyślnym zakończeniu testów włączam to ustawienie do moich standardowych kompilacji. Ważne jest, aby zespoły wiedziały, dlaczego wybrano wartość i kiedy należy to sprawdzić (np. po zmianie wersji lub obciążenia).

• Zarządzanie konfiguracją: Dla każdej roli (serwer WWW, baza danych, serwer plików) definiuję ustawienia domyślne w katalogu /etc/sysctl.d/ i rozdzielam je centralnie.
• Kontrola poślizgu: Regularne audyty sprawdzają, czy wartości w czasie rzeczywistym są zgodne z danymi w repozytorium.
• Runbooki: Dokumentuję etapy pomiaru, wartości graniczne dla cofania zmian oraz procedury awaryjne (np. przywrócenie do wartości 100).

# Rola: serwer WWW (przykład)
cat <<'EOF' | sudo tee /etc/sysctl.d/50-web-vfs.conf
vm.vfs_cache_pressure = 60
EOF
sudo sysctl --system

vm.vfs_cache_pressure i inne parametry jądra

Dobry wynik osiąga się dopiero dzięki współdziałaniu z vm.swappiness oraz wartości progowe dla brudnych stron. Niższa wartość swappiness (np. 10–20) sprawia, że procesy częściej pozostają w pamięci RAM, co pozwala uniknąć niepotrzebnego przenoszenia danych do pamięci zewnętrznej. Za pomocą vm.dirty_background_ratio i vm.dirty_ratio reguluję, jak wcześnie system zapisuje zmienione strony, aby szczyty zapisu nie blokowały całego systemu. Dostosowuję te wartości tak, aby wyszukiwanie metadanych przebiegało szybko, a operacje zapisu były możliwe do zaplanowania. Korzystam tutaj z zwięzłego przeglądu wzajemnego oddziaływania pamięci podręcznych plików: Przegląd buforowania systemu plików.

Zalecenia dotyczące środowisk hostingowych i WordPressa

Wiele motywów, wtyczek i plików multimedialnych generuje niezliczoną ilość małych plików, dlatego też potężny Pamięć podręczna VFS to wyraźnie pomaga. Zaczynam od 100, przy wystarczającej ilości pamięci RAM obniżam do 80, a później do 60 i sprawdzam czasy odpowiedzi, 95. percentyl opóźnień oraz zjawisko „CPU-Steal”. Jeśli pamięć działa bez zarzutu, testuję wartość 50 i ponownie weryfikuję wyniki podczas wieczornego szczytu lub w trakcie kampanii. Jeśli opóźnienia spadają bez uruchamiania swapowania lub mechanizmu OOM Killer, na stałe zapisuję to ustawienie. Równolegle obserwuję pamięć podręczną stron (Page Cache), aby obie pamięci podręczne sensownie się uzupełniały.

Podsumowanie

Za pomocą vm.vfs_cache_pressure kontroluję Równowaga bardzo precyzyjnie dostosowuję wartość między szybkim wyszukiwaniem metadanych a wolną pamięcią RAM. W przypadku obciążeń związanych z siecią umiarkowanie obniżam tę wartość, a w przypadku aplikacji wymagających dużej ilości pamięci – ją zwiększam. Każdą zmianę popieram wynikami pomiarów opóźnień operacji wejścia/wyjścia, trafień w pamięci podręcznej oraz aktywności wymiany. W połączeniu z vm.swappiness i parametrami „dirty” uzyskuję płynne zarządzanie pamięcią. W ten sposób efektywnie wykorzystuję pamięć podręczną systemu plików Linuksa i niezawodnie utrzymuję niskie czasy reakcji pod obciążeniem.