Przejdź do treści 
Pokazuję, jak linux dirty oraz współczynnik „dirty background” pozwalają sterować pamięcią podręczną strony, a tym samym wpływać na przepustowość zapisu, opóźnienia i bezpieczeństwo danych. W ten sposób ustalasz konkretne wartości graniczne, które uruchamiają procesy czyszczenia pamięci podręcznej w odpowiednim momencie, pozwalają uniknąć blokad i zwiększają wydajność zapisu w Twoich obciążeniach.
Punkty centralne
Na początek pokrótce podsumuję najważniejsze tezy, zanim przejdę do bardziej szczegółowego omówienia.
- Nieprzyzwoite strony buforuje zapisy w pamięci RAM i łączy wiele niewielkich operacji dostępu w bardziej wydajne operacje wejścia/wyjścia.
- dirty_background_ratio uruchamia wątki Flusher w tle, co pozwala w sposób niezauważalny ograniczyć ilość zanieczyszczeń.
- dirty_ratio spowalnia procesy zapisu, jeśli zostanie przekroczona sztywna wartość graniczna.
- Relacja Obie te wartości mają wpływ na szczytowe wartości opóźnienia, przepustowość oraz wielkość bufora.
- Warianty bajtów (dirty_bytes) zapewniają większą precyzję i pełną kontrolę na dużych serwerach.
Zrozumieć „Dirty Pages”
Gdy proces zapisuje dane, trafiają one najpierw do Pamięć podręczna strony i są oznaczane jako „brudne“, dopóki jądro nie zdoła ich zapisać na nośniku danych. Takie buforowanie przyspiesza działanie aplikacji, ponieważ pamięć RAM reaguje szybciej niż jakikolwiek dysk SSD lub HDD, a małe operacje zapisu łączą się w duże, sekwencyjne transfery. Zawsze mam na uwadze, ile „brudu“ dopuszczam, ponieważ zbyt duża ilość buforowanych danych może wydłużyć kolejki lub zwiększyć ryzyko utraty niezapisanych danych w przypadku awarii. Kto rozumie, jak to działa, ten podejmuje lepsze decyzje dotyczące writebacku, opóźnień i obciążenia pamięci. Krótki artykuł wprowadzający na temat Pamięć podręczna odwrócenia pomaga właściwie zrozumieć tę mechanikę.
Bezpieczeństwo danych, fsync i okno awarii
Wartości graniczne wpływają nie tylko na wydajność, ale także na zakres ryzyka. Oszacowuję to za pomocą prostej zasady praktycznej: maksymalna ilość danych niepewnych podzielona przez stałą przepustowość urządzenia daje w przybliżeniu czas, po upływie którego bufor zostanie opróżniony. Przykład: jeśli dopuszczę 4 GB danych „brudnych”, a nośnik docelowy osiąga prędkość 500 MB/s, całkowite zapisanie danych zajmie około 8 sekund. W tym czasie, w przypadku awarii zasilania lub awarii jądra, najnowsze zapisy mogą zostać utracone.
Aplikacje mogą wyświetlać to okno poprzez fsync() lub fdatasync() ograniczyć, ponieważ te wywołania zmuszają system plików do zapisywania danych (a w zależności od trybu rejestrowania – również metadanych) na nośniku. Jest to bardziej kosztowne, ale niezbędne w przypadku baz danych lub dzienników. Dbam o to, by moje limity „brudnych” danych były dostosowane do zachowania synchronizacji: częste fsync()-Liczba wyświetleń korzysta z niższego dirty_ratio, aby jądro nie stosowało dodatkowego ograniczania przepustowości, skoro dane i tak są regularnie zapisywane w pamięci trwałej. Z drugiej strony, w przypadku logów, w których dominuje operacja dołączania danych i które rzadko są opróżniane, mogę zezwolić na większe bufory – zawsze mając na uwadze akceptowalne ryzyko utraty danych.
Ważne są również bariery i kolejność zapisu: nowoczesne systemy plików wykorzystują polecenia FUA/Flush w celu prawidłowego opróżnienia pamięci podręcznej kontrolera. W przypadku nośników bez ochrony przed utratą zasilania (PLP) duże bufory zwiększają ryzyko; przy zastosowaniu PLP lub zabezpieczenia pamięci podręcznej zapisu większe bufory są często dopuszczalne.
Współczynnik zanieczyszczonego tła: miękka wartość progowa
Z dirty_background_ratio Określam, od jakiego procentu dostępnej pamięci wątki flusherów zaczynają zapisywać w tle. Wartość ta nie blokuje aplikacji, lecz po cichu uruchamia operacje czyszczenia, aby bufor nie przepełnił się. Niskie wartości powodują częstsze, ale bardziej równomierne zapisywanie w tle i wygładzają szczyty opóźnień. Wyższe wartości pozwalają na większe buforowanie, co zwiększa przepustowość w przypadku dużych sekwencyjnych operacji zapisu, ale może wywołać znaczne szczyty operacji wejścia/wyjścia w przypadku nagłego opróżnienia bufora. Zazwyczaj wartości domyślne wynoszą około dziesięciu procent, jednak dostosowuję ten limit w zależności od nośnika, obciążenia i wymagań bezpieczeństwa.
Dirty Ratio: gwałtowne hamowanie
Parametr dirty_ratio oznacza próg, przy którym jądro ogranicza wydajność procesów zapisujących dane, dopóki nie zostanie zapisana wystarczająca liczba stron. Ten sztywny limit chroni pamięć przed zalaniem danymi, które nie zostały trwale zapisane, i ma tym samym bezpośredni wpływ na aplikacje, gdy tylko chcą one kontynuować generowanie danych. W przypadku baz danych ustawiam tę wartość raczej nisko, aby zapytania zachowały stały czas odpowiedzi i nie dochodziło do długich faz opróżniania. Natomiast w przypadku zadań tworzenia kopii zapasowych stosuję większe bufory, aby efektywnie przesyłać duże bloki danych. Typowe wartości domyślne wahają się od dwudziestu do czterdziestu procent, jednak zawsze dostosowuję ten zakres do konkretnego obciążenia.
Wzajemne oddziaływania i typowe relacje
Obie wartości graniczne działają jako Tandem i dopiero razem wywierają swój wpływ. Zawsze ustawiam wartość dirty_background_ratio na niższy poziom niż dirty_ratio, aby jądro uruchamiało się w tle w odpowiednim czasie, a twarde hamowanie rzadko miało miejsce. Jako wartość orientacyjną często wybieram od jednej czwartej do połowy twardego limitu, na przykład 5–10 do 20. W ten sposób funkcja Writeback uruchamia się wystarczająco wcześnie, nie obniżając niepotrzebnie przepustowości. Kto nie zachowa tej proporcji, doświadczy albo zbyt wczesnego ograniczenia przepustowości, albo zbyt późnego uruchomienia zadań w tle, co spowoduje odczuwalne skoki opóźnień.
Sterowanie na poziomie poszczególnych urządzeń i jednostki warstwy blokowej
Oprócz limitów globalnych warto przyjrzeć się również poziomowi urządzeń. System Linux rozdziela obciążenie typu „dirty” za pomocą tzw. Urządzenia obsługiwane (bdi). W /sys/class/block//bdi/ Uważam, że parametry takie jak max_ratio, które określają, jaką część ogólnego limitu „Dirty-Budget” może wykorzystać pojedyncze urządzenie. W systemach, w których równolegle działają wolne i szybkie dyski, ograniczam wydajność wolnych nośników danych, aby nie stały się one wąskim gardłem.
Istotne znaczenie ma również ograniczenie przepustowości warstwy blokowej poprzez /sys/block//queue/wbt_lat_usec (Writeback Throttling). W ten sposób ustalam docelowe opóźnienie; jądro ogranicza wówczas obciążenie związane z zapisem, gdy przekroczy ono ten docelowy czas. W przypadku dysków SATA chętnie ustawiam konserwatywne wartości, aby zapewnić interaktywność. Na bardzo szybkich dyskach NVMe wyłączam lub zwiększam docelowe opóźnienie, aby kontroler mógł w pełni wykorzystać swoją równoległość. Harmonogram operacji wejścia/wyjścia (mq-deadline, BFQ, none) dobieram odpowiednio: BFQ sprawdza się w systemach interaktywnych o zróżnicowanym obciążeniu, podczas gdy brak lub mq-deadline często sprawdza się najlepiej w przypadku zadań opartych wyłącznie na przepustowości na dyskach NVMe.
Współdziałanie ma kluczowe znaczenie: Czy dirty_background_ratio Niskie, ale urządzenie jest agresywnie ograniczane przez WBT, co mimo to powoduje widoczne zatory. Dlatego kalibruję oba poziomy jednocześnie – globalne limity „Dirty” dla rozmiaru bufora oraz warstwę blokową dla ochrony przed opóźnieniami.
Ratio a bajty: wartości domyślne i warianty
W systemach o dużej ilości RAM Wartości procentowe szybko osiągają duże wartości bezwzględne. W takim przypadku wolę wprowadzić bezwzględne limity za pomocą zmiennych `dirty_bytes` i `dirty_background_bytes`, aby wyraźnie ograniczyć rozmiar bufora do około 2–8 GB. Oddziela to regulację od silnie zmiennych poziomów rozbudowy pamięci i pozwala utrzymać przewidywalną ilość danych nieprzechowywanych trwale. Wybór pozostaje dynamiczny: w przypadku małych serwerów z niewielką ilością pamięci RAM wartości procentowe często w zupełności wystarczają. Ci, którzy dysponują dużą pojemnością, często mogą lepiej planować, korzystając z wartości w bajtach.
| Parametry | Znaczenie | Typowe ustawienia domyślne | Kiedy należy to zmienić? | Wskazówka |
|---|---|---|---|---|
| vm.dirty_background_ratio | Rozpoczęcie Wyrównanie tła w procentach | ≈ 10% | W przypadku wahań opóźnień lub bardzo szybkich dysków SSD/NVMe | Niższa wartość = bardziej płynne opóźnienie, wyższa wartość = większy bufor |
| vm.dirty_ratio | Twardy Granica przepustowości w procentach | ≈ 20–40% | W przypadku baz danych niższe, w przypadku kopii zapasowych wyższe | Zbyt wysoka → możliwe zablokowania podczas operacji FLUSH |
| vm.dirty_background_bytes | Rozpoczęcie operacji czyszczenia w tle w Bajty | Wyłączone, jeśli używana jest funkcja Ratio | Duża pamięć RAM, stałe cele buforowania | Wyłącza parametry Ratio |
| vm.dirty_bytes | Sztywny limit przepustowości w Bajty | Wyłączone, jeśli używana jest funkcja Ratio | Duża pamięć RAM, możliwy do zaplanowania limit maksymalny | Wyłącza parametry Ratio |
Scenariusze obciążenia i zalecenia
Sekwencyjne obciążenia zapisu, takie jak Kopie zapasowe korzystają z dużych buforów i umiarkowanego zapisu w tle, ponieważ jądro może zapisywać dane na nośniku w dużych partiach. Często ustawiam tutaj wartość dirty_ratio na poziomie od 30 do 40 procent, a dirty_background_ratio na poziomie od 10 do 20 procent. Bazy danych i małe aplikacje wykorzystujące losowe operacje wejścia/wyjścia (Random I/O) wymagają przewidywalnego opóźnienia, dlatego wybieram 10–15 procent twardego buforowania i 3–5 procent miękkiego. W przypadku mieszanych serwerów internetowych i aplikacyjnych dobrym kompromisem okazuje się 15–20 procent twardych operacji i 5–10 procent miękkich. Zakresy te stanowią punkt wyjścia, a ostatecznie liczą się rzeczywiste pomiary w Twoim systemie.
Aspekty związane z systemem plików i opcje montowania
Ścieżka zapisu kończy się w systemie plików – jego strategia wpływa na opóźnienia i bezpieczeństwo. Ext4 z data=ordered (Domyślnie) zapisuje dane użytkowe przed zatwierdzeniem dziennika; data=writeback zmniejsza opóźnienie, ale wiąże się z ryzykiem utraty starych danych po awariach. Parametr commit= (w sekundach) określa częstotliwość zapisywania dziennika. Krótsze interwały zmniejszają ryzyko utraty danych, ale wymagają większej liczby operacji wejścia/wyjścia. System plików XFS wykorzystuje dopracowaną konstrukcję dziennika; duże logbsize a odpowiednie wyrównanie pomaga w zadaniach wymagających dużej przepustowości. System plików Btrfs grupuje operacje zapisu za pomocą mechanizmu „copy-on-write” – stabilizuje to opóźnienia, ale w przypadku niewielkiej liczby losowych operacji zapisu i dysków SSD o ograniczonej pojemności może prowadzić do fragmentacji. Opcje takie jak nodatacow mogą pomóc w przypadku określonych ścieżek lub ukierunkowanej defragmentacji, gdy występują skoki opóźnień.
Zwracam również uwagę na to, że relatime/noatime (ogranicza liczbę operacji zapisu metadanych), czas leniuchowania (opóźnia mtime/atime w sposób bardziej trwały) oraz bariery dziennikowania. Zwłaszcza w przypadku kontrolerów RAID lub w maszynach wirtualnych kluczowe znaczenie ma prawidłowa semantyka pamięci podręcznej: nieprawidłowo skonfigurowane pamięci podręczne zapisu niweczą wszelkie wysiłki związane z „brudnym dostrajaniem”.
Direct I/O, O_SYNC i zachowanie aplikacji
Nie każda operacja przechodzi przez pamięć podręczną stron. Za pomocą O_DIRECT lub O_SYNC/O_DSYNC Procesy te omijają części pamięci podręcznej lub wymagają natychmiastowej trwałości. Bazy danych zazwyczaj zapisują dziennik WAL/Redo-Log synchronicznie, a obszary danych asynchronicznie. Kalibruję progi „brudnych” danych szczególnie dla ścieżek asynchronicznych, natomiast dla ścieżek synchronicznych gwarantuję niskie opóźnienia dzięki szybkim dziennikom (NVMe, dedykowane LUN). Gdy aplikacje bardzo często fsync() w przypadku wywołań duże bufory nie są zbyt pomocne – opóźnienie zależy wtedy w większym stopniu od kontrolera, głębokości kolejki i harmonogramu operacji wejścia/wyjścia niż od dirty_ratio.
Praktyczne modyfikacje krok po kroku
Przed każdą zmianą sprawdzam wartości rzeczywiste z sysctl vm.dirty_ratio oraz sysctl vm.dirty_background_ratio, aby udokumentować stan początkowy. W przypadku testów krótkoterminowych zapisuję wartości bezpośrednio po /proc/sys/vm/dla przykładu echo 15 > /proc/sys/vm/dirty_ratio oraz echo 5 > /proc/sys/vm/dirty_background_ratio. Jeśli zmiana ta ma charakter trwały, zapisuję ją w /etc/sysctl.conf lub /etc/sysctl.d/*.conf. Zmiany wprowadzam za pomocą sysctl -p natychmiast, abym mógł szybko zmierzyć efekt. Osoby, które zagłębiają się w temat zasad systemowych, skorzystają z praktycznych wskazówek dotyczących Optymalizacja za pomocą sysctl na serwerach produkcyjnych.
Wyprowadzanie wartości: przykłady obliczeniowe
Lubię zaczynać od konkretnych parametrów. Przykład 1: serwer WWW/aplikacji z 64 GB pamięci RAM i dyskiem NVMe. Celem jest płynne opóźnienie. Ustawiam dirty_background_bytes=1073741824 (1 GB) oraz dirty_bytes=3221225472 (3 GB). Przy stałej przepustowości NVMe wynoszącej 2 GB/s oznacza to około 0,5–1,5 sekundy na opróżnienie – co jest dobrym wynikiem w przypadku obciążenia interaktywnego. Przykład 2: Węzeł kopii zapasowej z 128 GB pamięci RAM, szybki macierz RAID SATA o przepustowości 800 MB/s. Wybieram dirty_background_ratio=10, dirty_ratio=35. W wartościach bezwzględnych jest to ok. 12,8 GB i 44,8 GB; opróżnienie macierzy RAID zajmuje 16–56 sekund. To w porządku, ponieważ zadanie nie jest interaktywne.
Przykład 3: Serwer bazy danych z 256 GB pamięci RAM, oddzielny dziennik na dysku NVMe, dane na macierzy SSD. Stosuję ograniczenia absolutne, aby uniknąć wartości odstających: dirty_background_bytes=2147483648 (2 GB), dirty_bytes=8589934592 (8 GB). Dzięki temu rozmiar okna awarii pozostaje przewidywalny, a gwałtowne spowolnienia podczas przechodzenia przez punkty kontrolne są ograniczone.
Czas odwrócenia zapisu i powiązane parametry
Oprócz wartości granicznych wpływają na to Timer sposób odtwarzania danych, a co za tym idzie – płynność działania aplikacji. Dzięki vm.dirty_writeback_centisekundy reguluję częstotliwość, z jaką jądro budzi program Flusher, podczas gdy vm.dirty_expire_centisecs określa maksymalny wiek, jaki mogą osiągnąć brudne strony. Krótsze interwały zapewniają częstsze, ale mniejsze operacje flush, natomiast dłuższe interwały pozwalają zaoszczędzić na wywołaniach wejścia/wyjścia, ale wiążą się z ryzykiem powstania większych pakietów. Dostosowuję te wartości tylko wtedy, gdy pomiary wskazują na rzeczywiste wady, na przykład zbyt rzadkie operacje flush na szybkich dyskach NVMe. Kto postępuje w tej kwestii metodycznie, uniknie wahań między zbyt intensywną a zbyt powolną aktywnością writeback.
Monitorowanie i precyzyjna regulacja
Po wprowadzeniu zmian zauważam, że ciągły wskaźniki służące do uwidocznienia sukcesów i skutków ubocznych. W /proc/meminfo Sprawdzam „Dirty“ i „Writeback“, aby zobaczyć stan buforów i aktywne operacje flush. Narzędzia takie jak iostat, sar czy atop pokazują mi przepustowość, kolejki i trendy opóźnień. Odpowiednie wprowadzenie do metryk zawiera ten artykuł na temat Analiza czasu oczekiwania na operacje wejścia/wyjścia. Dopiero na podstawie tych danych zmniejszam lub zwiększam limity małymi krokami, aby nie wystąpiły żadne nieoczekiwane skutki uboczne.
Kontenery, cgroups i sprawiedliwy podział zasobów
W środowiskach kontenerowych obciążenia współdzielą te same mechanizmy jądra. Funkcja Cgroup-Writeback zapewnia, że brudne strony są przypisywane do podmiotu, który je wygenerował. Korzystam z kontrolerów wejścia/wyjścia cgroupów (blkcg), aby ograniczać przepustowość lub liczbę operacji IOPS na kontener, gdy poszczególni najemcy zbyt intensywnie buforują dane. Bezwzględne limity bajtów na poziomie hosta (dirty_bytes) zapobiegają sytuacji, w której pojedynczy gość pochłania cały budżet na „Dirty”. Dodatkowo ograniczam pamięć poprzez memory.max, aby funkcja Writeback nie reagowała dopiero po globalnym obciążeniu. Cel pozostaje ten sam: żadne obciążenie gościa nie może powodować ograniczeń w skali hosta w zakresie dirty_ratio wymusić.
Środowiska hostingowe i maszyny wirtualne
W konfiguracjach wielodostępnych i maszynach wirtualnych zwracam uwagę na Overbooking pamięci RAM i operacji wejścia/wyjścia, ponieważ limity procentowe mają tam inny wpływ. Bezwzględne limity w bajtach mogą zapobiegać sytuacji, w której poszczególne maszyny-goście tworzą zbyt duże bufory i spowalniają sąsiadów. Uwzględniam deduplikację pamięci, mechanizm ballooning oraz pamięci podręczne kontrolerów, ponieważ nakładają się one na efekty buforowania. W przypadku serwerów zarządzanych opłaca się, gdy dostawca ustawia sensowne wartości domyślne, aby klienci mogli cieszyć się stałymi czasami odpowiedzi. Kto obsługuje własne węzły, zyskuje dzięki precyzyjnie zdefiniowanym ustawieniom profilów dla każdej klasy obciążenia.
Częste nieporozumienia i przeszkody
- „Większy zapas = coraz większa przepustowość.“ Nie jest to właściwe w przypadku obciążeń opartych głównie na operacjach losowych lub urządzeń o małej głębokości kolejki. Zbyt duże bufory powodują gwałtowne opróżnianie i tworzenie się kolejek.
- „Wskaźnik dirty_ratio nie ma wpływu na operacje odczytu.“ Pośrednio jednak tak: agresywne fazy zapisu powodują wypchnięcie stron z pamięci podręcznej i zwiększają opóźnienia odczytu.
- „Bajty i rozsądek się sumują.“ Nie. Jeśli ustawisz warianty „Bytes”, anulują one odpowiadające im warianty „Ratio”. Trzeba zachować jednoznaczność.
- „fsync() sprawia, że limity brudnych danych tracą znaczenie.“ Nie. Częste synchronizacje wprawdzie zmniejszają przedział ryzyka, ale pozostała część obciążenia nadal podlega wartościom granicznym.
- „Szybki nośnik danych rozwiązuje wszystkie problemy.“ Nie, jeśli warstwa blokowa ogranicza przepustowość (WBT) lub system plików jest zamontowany w sposób nieoptymalny.
- „Drop_caches to narzędzie do optymalizacji.“ Opróżnianie pamięci podręcznej zniekształca pomiary i pogłębia skoki opóźnień. W środowisku produkcyjnym staram się tego unikać.
Rozwiązywanie problemów: typowe objawy i sposoby zaradcze
Stos Szczyty opóźnień, najpierw obniżam próg działania w tle, aby operacje flusherów rozpoczynały się wcześniej, a duże fale zapisu pojawiały się rzadziej. Jeśli aplikacje okresowo ulegają zablokowaniu, zazwyczaj oznacza to, że twardy limit jest zbyt wysoki lub nośnik nie radzi sobie z pojawiającymi się seriami operacji flush. W takich przypadkach obniżam wartość dirty_ratio, sprawdzam ustawienia odczytu z wyprzedzeniem (read-ahead) i przyglądam się opcjom dziennika systemu plików. W przypadku bardzo szybkiego sprzętu NVMe stopniowo zwiększam próg działania w tle, aby nie ograniczać sztucznie przepustowości. Po każdej zmianie kieruję się wynikami pomiarów, a nie przeczuciem.
Krótkie podsumowanie dla praktyki
Z kilkoma Śruby regulacyjne Wpływam na to, w jaki sposób Linux buforuje dane do zapisu, kiedy uruchamiają się programy czyszczące bufor (flushery) i kiedy jądro spowalnia działanie. Wskaźnik „Dirty Background Ratio” zapewnia płynne czyszczenie, natomiast wskaźnik „Dirty Ratio” bardziej rygorystycznie ogranicza zużycie pamięci RAM. Stosunek tych dwóch wartości decyduje o tym, czy system dąży raczej do równomiernych opóźnień, czy do maksymalnej przepustowości. Dokumentuję ustawienia domyślne, wprowadzam zmiany małymi krokami i konsekwentnie analizuję wyniki pomiarów. W ten sposób powstaje konfiguracja, która rozsądnie równoważy obciążenie, nośnik i ryzyko, a w praktyce działa zauważalnie szybciej.
