Przejdź do treści 
W dwóch zdaniach wyjaśnię, w jaki sposób system Linux przyspiesza dostęp do plików w pamięci RAM oraz jak przejrzysta pamięć podręczna stron wykorzystuje większe jednostki stron, co zmniejsza nakład pracy administracyjnej. Ponadto wyjaśniam różnice w stosunku do klasycznej pamięci podręcznej stron (Page Cache) z stronami o rozmiarze 4 KiB, a także jej wpływ na TLB, fragmentację i zachowanie obciążenia.
Punkty centralne
- Rozmiar strony: 4 KiB w porównaniu z 2 MiB wpływa na stopień szczegółowości i wydajność.
- Druk TLB: Duże strony ograniczają liczbę wpisów, małe zachowują elastyczność.
- Fragmentacja: Duże strony wymagają spójnej pamięci RAM.
- Obciążenia: Sekwencyjnie – duże zyski, losowo – mniejsze.
- Kontrola: Najpierw przetestuj, zmierz, a potem stopniowo konfiguruj.
Czym jest klasyczna pamięć podręczna stron w systemie Linux?
Klasyczna pamięć podręczna stron przechowuje często używane strony plików w pamięci operacyjnej, dzięki czemu operacje odczytu są wykonywane bezpośrednio z RAM odbywa się. Zazwyczaj pracuje on ze stronami o rozmiarze 4 KiB i zarządza każdą stroną jako odrębną jednostką w pamięci podręcznej. Dzięki temu wiele małych plików lub często wyszukiwanych fragmentów dużych plików pozostaje dostępnych bez obciążania dysku SSD lub HDD. Jądro nadaje priorytet aktywnym stronom, odrzuca rzadko używane treści i w ten sposób dynamicznie reaguje na szczyty obciążenia. Aby uzyskać bardziej szczegółowe informacje, odsyłam do zwięzłego wprowadzenia do Wydajność pamięci podręcznej stron, która w praktyczny sposób opisuje podstawową zasadę.
Dlaczego warto stosować przezroczystą pamięć podręczną stron?
Duża liczba pojedynczych stron o rozmiarze 4 KiB powoduje dodatkową pracę administracyjną i zwiększa presję na TLB. Strony o większym rozmiarze, np. 2 MiB, mogą obejmować tę samą przestrzeń adresową przy mniejszej liczbie wpisów, co pozwala zaoszczędzić czas procesora. Przezroczysta pamięć podręczna stron automatycznie łączy strony plików w większe jednostki, o ile pozwalają na to wzorce dostępu i rozmieszczenie w pamięci. Przypomina to ideę stojącą za Transparent Huge Pages, odnosi się jednak w tym przypadku do pamięci podręcznej opartej na plikach, a nie do pamięci anonimowej. Funkcje takie wdrażam dopiero po zrozumieniu wzorców dostępu, fragmentacji i wymagań dotyczących opóźnień, ponieważ większe strony zwiększają stopień szczegółowości.
Systematyczne porównywanie różnic
Aby ułatwić orientację, zestawiam obok siebie najważniejsze cechy klasycznej pamięci podręcznej, przezroczystej pamięci podręcznej stron oraz THP, tak aby wybór był Obciążenie pracą jest łatwiejsze. Skupiamy się na rozmiarze strony, TLB, fragmentacji, korzyściach i zagrożeniach. Tabela przedstawia zalety i ograniczenia bez marketingowych frazesów. Czytam ją od lewej do prawej i sprawdzam, która kolumna najlepiej pasuje do obciążenia. Następnie decyduję, czy pozostać przy pamięci podręcznej 4 KiB, czy przetestować większe strony.
| Cecha | Klasyczna pamięć podręczna stron (4 KiB) | Przezroczysta pamięć podręczna stron (np. 2 MiB) | THP (pamięć anonimowa) |
|---|---|---|---|
| Rozmiar strony/ziarnistość | Precyzyjne, dokładne buforowanie | W przybliżeniu, całkiem duże obszary | Z grubsza, duże stosy/sterty |
| Druk TLB | Więcej wpisów oznacza wyższą pozycję | Niżej, mniej wpisów | Niżej, mniej wpisów |
| Koszty administracyjne | Wysoki u wielu stron | Mniej metadanych | Mniej metadanych |
| Fragmentacja | Nie jest krytyczny, nie wymaga ciągłości | Wymaga spójnej pamięci RAM | Wymaga spójnej pamięci RAM |
| Odpowiednie obciążenia | Małe pliki, losowe odwołania | Duże pliki, wzorce sekwencyjne | Duże stosy, bazy danych w pamięci RAM |
| Ryzyko | Większe obciążenie TLB i procesora | Overfetch, skoki opóźnienia podczas operacji split/merge | Overfetch, skoki opóźnienia podczas operacji split/merge |
| Zależność od jądra/funkcji | Szeroko dostępny | Należy zwrócić uwagę na wersję/implementację | Sprawdź ustawienia dystrybucji |
Tabela nie zastępuje testu, ale porządkuje moje Decyzja. Najpierw oceniam wzorce dostępu i rozmiar plików. Następnie mierzę opóźnienie, czas procesora i współczynnik trafień w pamięci podręcznej – zarówno z dużymi stronami, jak i bez nich. Jeśli testy wydajności wykazują wyraźne korzyści bez wartości odstających, ostrożnie zwiększam skalę. Jeśli pojawiają się skoki wartości, cofam zmiany lub ograniczam zakres wdrożenia.
W jaki sposób jądro tworzy duże strony plików
Aby w pamięci podręcznej stron mogły powstawać większe jednostki stron, jądro potrzebuje spójnych obszarów plików w pamięci oraz wystarczająco spójnego dostępu. Typowym przykładem jest operacja promowania: kilka stron o rozmiarze 4 KiB jest łączonych w jeden większy folio. Z kolei w przypadku nieodpowiednich wzorców następuje podział z powrotem na mniejsze jednostki. Obserwuję te przejścia szczególnie pod obciążeniem, ponieważ promowanie i dzielenie chwilowo obciążają procesor i powodują aktualizację list LRU. Czytanie sekwencyjne sprzyja promowaniu, natomiast silnie rozproszone obciążenia raczej powodują podziały.
Istotną rolę odgrywa tu funkcja odczytu z wyprzedzeniem (Readahead): jeśli z wyprzedzeniem odczytana zostanie wystarczająca ilość danych, a dane te zostaną następnie faktycznie wykorzystane, powstają duże bloki danych niemalże przy okazji. Jeśli natomiast aplikacje pobierają dane małymi, nieprzewidywalnymi porcjami, pamięć podręczna pozostaje rozdrobniona. Również Writeback współdziała z dużymi stronami: jeśli jednocześnie zapisywanych jest wiele powiązanych ze sobą stron typu „dirty”, może to pozytywnie wpłynąć na przepustowość i liczbę operacji IOPS, jednak wzrasta wielkość impulsów. Dlatego uwzględniam parametry dostrajania typu „dirty” (np. vm.dirty_background_bytes oraz vm.dirty_bytes), aby uniknąć zbyt dużych fal spłukiwania.
Systemy plików, ścieżki wejścia/wyjścia i ich wpływ
Operacje wejścia/wyjścia z buforowaniem czerpią bezpośrednie korzyści z pamięci podręcznej stron, natomiast operacje bezpośredniego wejścia/wyjścia (O_DIRECT) w dużej mierze omija ten mechanizm. W przypadku baz danych lub narzędzi do tworzenia kopii zapasowych, które celowo korzystają z Direct I/O, przezroczysta pamięć podręczna stron ma zatem mniejszy wpływ. W przypadku mmap() efekt zależy od sposobu przeglądania: skanowanie strona po stronie, od początku do końca, pozwala dobrze wykorzystać większe folio; skoki losowe – nie. Z posix_fadvise() czy mogę przekazać jądru pewne wskazówki (np. SEKWENCYJNE, WILLNEED, RANDOM), które wpływają na odczyt z wyprzedzeniem i wypieranie. Takie wskazówki nie stanowią gwarancji, ale zwiększają prawdopodobieństwo, że pamięć podręczna będzie dostosowana do mojego obciążenia.
Systemy plików mają swoje własne algorytmy heurystyczne. W niektórych systemach ext4 i XFS reagują bardzo rozsądnie na strumienie sekwencyjne, podczas gdy systemy plików typu „copy-on-write” z deduplikacją lub kompresją (np. drzewa z wieloma migawkami) wykazują inne profile działania. Dlatego sprawdzam, czy układ i fragmentacja systemu plików pozwalają na tworzenie dużych, spójnych obszarów. Defragmentacja silnie rozdrobnionych danych może przynieść wymierne korzyści, ale należy ją zawsze planować z zachowaniem ostrożności i w ramach okien konserwacyjnych.
Czynniki sprzętowe: architektura, NUMA i urządzenia
Nie każda architektura wykorzystuje 4 KiB jako stronę bazową. W systemach z większymi stronami bazowymi ziarnistość i zachowanie TLB zmieniają się już domyślnie. To przesuwa zakres korzyści wynikających z dużych folio w pamięci podręcznej. Ponadto zwracam uwagę na topologie NUMA: Duże strony działają najlepiej, gdy znajdują się lokalnie w pobliżu procesora, który wykonuje wątek wejścia/wyjścia lub aplikację. Dlatego przypisuję procesy robocze do węzłów, monitoruję statystyki dla poszczególnych obszarów NUMA i zapobiegam niepotrzebnym dostępom zdalnym. W systemie Linux pomagają mi w tym wskaźniki dla poszczególnych węzłów (/sys/devices/system/node/node*/meminfo) oraz przypinanie harmonogramu w celu zachowania lokalności.
Po stronie urządzenia sprawdzam kolejki kontrolera, głębokość NVMe oraz krzywą opóźnień. Duże serwery działają dobrze, charakteryzując się wysoką przepustowością i stabilnym opóźnieniem, ale są wrażliwe na skoki opóźnienia w końcowej części. Harmonogram operacji wejścia/wyjścia, który wygładza obciążenia impulsowe, może tu odegrać kluczową rolę. Wartości odczytu wyprzedzającego (blockdev --getra/--setra) Dokonuję ostrożnej kalibracji dla każdego urządzenia i każdego obciążenia.
Metodologia pomiaru, wskaźniki KPI i możliwość obserwacji
Na wstępie definiuję kilka nielicznych, ale znaczących wskaźników: wskaźnik błędów stronicowania, współczynnik trafień w pamięci podręcznej, czas procesora na żądanie, obciążenie TLB, trafienia w odczycie wyprzedzającym, percentyle opóźnienia (P50/P95/P99) oraz nieudane operacje wejścia/wyjścia. Do analizy systemu wykorzystuję vmstat, sar -B, iostat oraz pidstat, aby rozpoznać trendy. /proc/meminfo oraz smaps pomagają w analizie zawartości pamięci operacyjnej; slabtop wskazuje obciążenie związane z metadanymi. W razie potrzeby dokonuję pomiaru za pomocą perf Błędy TLB i cykle procesora pod rzeczywistym obciążeniem, aby uwidocznić efekt dużych stron.
Test składa się dla mnie z trzech faz: rozgrzewki do osiągnięcia stabilnej częstotliwości odczytów, interwału pomiarowego pod kontrolowanym obciążeniem oraz fazy schładzania w celu obserwacji procesów eviction i writeback. Powtarzam testy z identycznym zestawem danych i zmiennymi parametrami (np. readahead, tryb THP) zawsze/zazwyczaj/nigdy), aby uzyskać wiarygodne wyniki. Nie pomijam wartości odstających: jeśli P99 pogarsza się, mimo że średnia spada, to taka konfiguracja zazwyczaj nie mieści się w moim docelowym przedziale.
Typowe wzorce w praktyce
W przypadku obciążeń związanych ze streamingiem i multimediami duże pliki są w większości odczytywane sekwencyjnie. Tutaj duże folio regularnie wykazują przewagę, ponieważ zmniejsza się obciążenie TLB i nakład administracyjny. Tworzenie kopii zapasowych/przywracanie oraz replikacja z wykorzystaniem długich, sekwencyjnych bloków wykazują podobne zalety, zwłaszcza gdy wiele procesów odczytuje te same obszary. Potoki uczenia maszynowego zyskują, gdy zbiory danych są grupowane i przechowywane; jednak silnie losowe próbkowanie z wielu bardzo małych plików osłabia ten efekt, o ile nie przejdzie się wcześniej na formaty kontenerowe z powiązanymi blokami.
Środowiska kompilacji i CI zawierające tysiące małych plików zazwyczaj działają lepiej przy ziarnistości 4 KiB. W takich przypadkach liczy się szybka i precyzyjna dostępność często używanych fragmentów. Inwestuję tutaj w dużą ilość pamięci RAM przeznaczonej na pliki aktywne (Active(file)), rozsądne odczytywanie z wyprzedzeniem (readahead) na urządzenie oraz ewentualnie w pamięci podręczne powiązane z aplikacjami (np. pamięci podręczne zależności), zamiast wymuszać stosowanie dużych stron w jądrze systemu.
Zarządzanie zasobami: Cgroups i ochrona zestawu roboczego
W środowiskach wielodostępnych ograniczam i zabezpieczam pamięć dla poszczególnych usług. Dzięki cgroup v2 można precyzyjnie rozliczać procesy obciążające pamięć podręczną stron i w razie potrzeby za pomocą memory.low chronić, dzięki czemu ważne zestawy robocze rzadziej są wypierane. memory.high ustala elastyczne pułapy, memory.max ścisłe limity. Obserwuję, jak działają mechanizmy Fairness i Eviction, gdy kilka usług współdzieli tę samą pamięć podręczną serwera. Duże strony mogą tu pomóc w odciążeniu procesora, ale mogą też prowadzić do większych bloków wypierania. Dlatego dostosowuję limity ochronne małymi krokami i sprawdzam dynamikę LRU.
Objawy usterek i środki zaradcze
Gdy często występują jednocześnie zjawiska promotion i split, obserwuję wahania opóźnień, wysokie obciążenie procesora przez jądro oraz zmienne wskaźniki trafień. Sposoby zaradcze: dostosowanie readahead, unikanie kaskad split, rozdzielenie obciążeń lub zmniejszenie agresywności dużych stron. W przypadku objawów overfetch (duża ilość danych w pamięci podręcznej, rosnąca presja na pamięć wymiany, spadający współczynnik trafień dla małych zestawów często używanych) przechodzę na drobniejszą granularność lub izoluję duże operacje odczytu na dedykowanych węzłach. Jeśli impulsy zapisu zwiększają opóźnienie ogona, ustalam bardziej rygorystyczne limity brudnych bajtów i wygładzam interwały opróżniania.
Problem z fluktuacjami NUMA rozwiązuję poprzez przypisanie procesora i pamięci oraz odpowiednie rozmieszczenie wątków wejścia/wyjścia. Jeśli występują nieudane próby odczytu z TLB, ale aplikacja nadal działa wolno, sprawdzam konflikty blokad, blokady systemu plików oraz wpływ kompresji/deszyfrowania w stosie. Wzrost wydajności wynikający z użycia dużych stron jest prawdziwym sukcesem tylko wtedy, gdy jest widoczny w punkcie końcowym aplikacji.
Praktyczny harmonogram egzaminów
Zacznę od punktu odniesienia: aktualne jądro, stan THP (/sys/kernel/mm/transparent_hugepage/), wartości odczytu z wyprzedzeniem, harmonogram operacji wejścia/wyjścia, układ plików i nośników danych. Następnie formułuję dwie lub trzy konkretne hipotezy (np. „sekwencyjne strumienie multimedialne: -10% CPU, stabilniejszy P99“). Następnie ustalam stałe zestawy danych i profile obciążenia, które odzwierciedlają realistyczne wzorce ruchu. Każda seria testów ma identyczny czas rozgrzewania, identyczny czas trwania i identyczny zakres rejestrowanych metryk.
Za każdym razem zmieniam tylko jeden parametr: najpierw Readahead, potem poziom agresywności dużych stron, a na koniec ustawienia LRU/Dirty. Po każdym kroku zapisuję wskaźniki i notatki, aby późniejsze aktualizacje jądra były porównywalne. Dopiero gdy dwa niezależne przebiegi wykazują tę samą tendencję, a opóźnienia P95/P99 są stabilne, wprowadzam zmianę do ograniczonej grupy produkcyjnej. Zawsze towarzyszy temu plan wycofania zmian z jasno określonymi wartościami progowymi (np. „P99 > +15% przez 5 min“).
Wzorce dostępu i wrażliwość
Czytniki sekwencyjne obsługujące duże pliki częściej czerpią korzyści z większych Strony. Losowe odczyty wielu małych plików zazwyczaj przebiegają sprawniej przy rozmiarze 4 KiB, ponieważ pamięć podręczna przechowuje wtedy tylko niezbędne fragmenty. Obciążenia mieszane wymagają pomiarów z wykorzystaniem realistycznych zbiorów danych, ponieważ testy syntetyczne często dają zbyt optymistyczne wyniki. Zwracam uwagę na to, czy funkcja overfetch zajmuje pamięć, której brakuje gdzie indziej. Niewielki zysk w zakresie czasu procesora nie jest opłacalny, jeśli powoduje to wzrost presji na listę LRU i skoki opóźnień.
Scenariusze hostingu internetowego z dużą liczbą małych plików
Typowy hosting współdzielony obsługuje ogromną liczbę małych skryptów, obrazów i zasobów, które pamięć podręczna o rozmiarze 4 KiB z łatwością mieści w Uchwyt ma. Duże strony rzadko wnoszą tu dodatkową wartość, ponieważ pliki często mają rozmiar mniejszy niż 2 MiB lub są wykorzystywane nieregularnie. Zamiast tego inwestuję w wystarczającą ilość pamięci RAM, sensowne wyprzedzanie odczytu (readahead) na każdym urządzeniu oraz pamięci podręczne na poziomie aplikacji, takie jak OPCache. Ponadto sprawdzam, czy zasoby statyczne są dostarczane szybciej przez pamięć podręczną HTTP niż z urządzenia blokowego. Dopiero gdy profile obciążenia wskazują na większe pliki, otwieram drzwi dla większych stron w pamięci podręcznej stron.
Bazy danych, pamięci podręczne i logi
Bazy danych w pamięci i duże stosy często czerpią korzyści z THP w trybie anonimowym Pamięć. W przypadku silników opartych na plikach i potoków logowania z długimi, sekwencyjnymi odczytami przezroczysta pamięć podręczna stron również może przynieść korzyści. Przeprowadzam powtarzalne testy, aby sprawdzić, czy liczba błędów stron (page faults) maleje, a procesor pracuje spokojniej. Jednocześnie obserwuję, czy funkcja overfetch powoduje wzrost zajętej pamięci RAM i czy zmienia się czas zimnego startu. Krótkie wprowadzenie pomoże na początku: korzystam z tego przewodnika, aby Ocena THP oraz właściwie ocenić wzajemne oddziaływania.
Wirtualizacja i kontenery
Kilka maszyn wirtualnych lub kontenerów współdzieli jądro hosta, a tym samym Strona-Pamięć podręczna. Często używane pliki binarne i biblioteki są wówczas dostarczane wszystkim instancjom z tej samej pamięci podręcznej, co pozwala zaoszczędzić operacje wejścia/wyjścia. THP w systemie-gościu może zmniejszyć obciążenie procesora, wymaga jednak uwzględnienia stref NUMA i overcommitu. Dokonuję pomiarów dla każdego węzła NUMA, aby duże strony nie przemieszczały się po całym systemie. Jeśli pod obciążeniem pojawia się jitter, zmniejszam agresywność (madvise) lub selektywnie wyłączam THP, aż krzywe znów staną się płynne.
Sprawdź konfigurację i ustaw odpowiednie parametry
Zacznę od trzeźwej Inwentaryzacja: Jaka wersja jądra, jakie ustawienia domyślne, jakie opcje montowania, jakie wartości odczytu z wyprzedzeniem? Stan THP sprawdzam w katalogu /sys/kernel/mm/transparent_hugepage/ (np. enabled, defrag, khugepaged). Aby sprawdzić zachowanie pamięci podręcznej stron, przeglądam katalog /proc/meminfo, statystyki na poszczególnych węzłach oraz readahead w blokach. Nigdy nie wdrażam zmian na ślepo, lecz najpierw testuję je w środowisku stagingowym przy użyciu rzeczywistych danych. Dopiero potem przenoszę stabilne konfiguracje do środowiska produkcyjnego.
Dostrajanie: odczyt z wyprzedzeniem, usuwanie danych i monitorowanie
Duże strony działają skutecznie tylko wtedy, gdy mechanizm odczytu z wyprzedzeniem, harmonogram operacji wejścia/wyjścia oraz algorytm LRU działają prawidłowo razemdziałanie. Obserwuję wskaźnik błędów strony (Page-Fault-Rate), liczbę nieudanych odwołań (Misses), czas procesora (CPU-Zeit) oraz ewentualne skoki opóźnienia podczas dzielenia i łączenia dużych stron. W warunkach obciążenia interesuje mnie, jak szybko pamięć podręczna wypiera stare strony i czy nie dochodzi do utraty ważnych plików. Dobrym punktem wyjścia do analizy wypierania jest ten wpis na temat Eksmisja pod presją pamięci, w którym wyjaśniono typowe schematy. Następnie ostrożnie dostosowuję parametry odczytu z wyprzedzeniem, opcje systemu plików oraz, w razie potrzeby, korzystanie z dużych stron.
Lista kontrolna dla praktyki – bez mitów
Zacznę od jasno określonych celów: skrócenie czasu pracy procesora, mniejsze opóźnienia, odpowiednie Współczynnik trafień w pamięci podręcznej stron. Następnie definiuję punkty pomiarowe i wybieram rzeczywiste obciążenia, które wykazują szczyty oraz obciążenia mieszane. Potem stopniowo testuję większe strony, najpierw w środowisku stagingowym, a następnie w ograniczonym zakresie w środowisku produkcyjnym. Przygotowuję plany przywrócenia stanu poprzedniego na wypadek wystąpienia nadmiernego pobierania danych, fragmentacji lub wahania wydajności. Na koniec dokumentuję uzyskane efekty, aby konfiguracja pozostała powtarzalna i aby można było ocenić przyszłe aktualizacje jądra.
Krótkie podsumowanie
Klasyczna pamięć podręczna o pojemności 4 KiB pozostaje niezawodnym rozwiązaniem dla wielu aplikacji Podstawa, ponieważ działa precyzyjnie i oszczędnie wykorzystuje pamięć RAM. Przejrzysta pamięć podręczna stron zmniejsza obciążenie TLB i ilość metadanych podczas sekwencyjnego odczytu dużych plików. THP obsługuje anonimowe obszary pamięci i może pomóc w zarządzaniu dużymi stertami, wymaga jednak ostrożności ze względu na możliwe skoki opóźnień. Decyzję podejmuję w oparciu o dane: mierzę, porównuję, a następnie wdrażam. Kto postępuje w ten sposób, osiąga przewidywalne czasy reakcji, rozsądne wykorzystanie pamięci RAM oraz zauważalnie spokojniejsze działanie procesora.
