{"id":20858,"date":"2026-08-21T11:49:48","date_gmt":"2026-08-21T09:49:48","guid":{"rendered":"https:\/\/webhosting.de\/linux-dirty-ratio-dirty-background-ratio-optimierung-writeback\/"},"modified":"2026-08-21T11:49:48","modified_gmt":"2026-08-21T09:49:48","slug":"wspolczynnik-brudzenia-systemu-linux-wspolczynnik-brudzenia-tla-optymalizacja-zapis-z-opoznieniem","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pl\/linux-dirty-ratio-dirty-background-ratio-optimierung-writeback\/","title":{"rendered":"Wska\u017anik \u201eDirty Ratio\u201d i \u201eDirty Background Ratio\u201d w systemie Linux: precyzyjne dostrajanie w celu uzyskania optymalnej wydajno\u015bci zapisu"},"content":{"rendered":"<p>Pokazuj\u0119, jak <strong>linux dirty<\/strong> oraz wsp\u00f3\u0142czynnik \u201edirty background\u201d pozwalaj\u0105 sterowa\u0107 pami\u0119ci\u0105 podr\u0119czn\u0105 strony, a tym samym wp\u0142ywa\u0107 na przepustowo\u015b\u0107 zapisu, op\u00f3\u017anienia i bezpiecze\u0144stwo danych. W ten spos\u00f3b ustalasz konkretne warto\u015bci graniczne, kt\u00f3re uruchamiaj\u0105 procesy czyszczenia pami\u0119ci podr\u0119cznej w odpowiednim momencie, pozwalaj\u0105 unikn\u0105\u0107 blokad i zwi\u0119kszaj\u0105 wydajno\u015b\u0107 zapisu w Twoich obci\u0105\u017ceniach.<\/p>\n\n<h2>Punkty centralne<\/h2>\n<p>Na pocz\u0105tek pokr\u00f3tce podsumuj\u0119 najwa\u017cniejsze tezy, zanim przejd\u0119 do bardziej szczeg\u00f3\u0142owego om\u00f3wienia.<\/p>\n<ul>\n  <li><strong>Nieprzyzwoite strony<\/strong> buforuje zapisy w pami\u0119ci RAM i \u0142\u0105czy wiele niewielkich operacji dost\u0119pu w bardziej wydajne operacje wej\u015bcia\/wyj\u015bcia.<\/li>\n  <li><strong>dirty_background_ratio<\/strong> uruchamia w\u0105tki Flusher w tle, co pozwala w spos\u00f3b niezauwa\u017calny ograniczy\u0107 ilo\u015b\u0107 zanieczyszcze\u0144.<\/li>\n  <li><strong>dirty_ratio<\/strong> spowalnia procesy zapisu, je\u015bli zostanie przekroczona sztywna warto\u015b\u0107 graniczna.<\/li>\n  <li><strong>Relacja<\/strong> Obie te warto\u015bci maj\u0105 wp\u0142yw na szczytowe warto\u015bci op\u00f3\u017anienia, przepustowo\u015b\u0107 oraz wielko\u015b\u0107 bufora.<\/li>\n  <li><strong>Warianty bajt\u00f3w<\/strong> (dirty_bytes) zapewniaj\u0105 wi\u0119ksz\u0105 precyzj\u0119 i pe\u0142n\u0105 kontrol\u0119 na du\u017cych serwerach.<\/li>\n<\/ul>\n\n<h2>Zrozumie\u0107 \u201eDirty Pages\u201d<\/h2>\n\n<p>Gdy proces zapisuje dane, trafiaj\u0105 one najpierw do <strong>Pami\u0119\u0107 podr\u0119czna strony<\/strong> i s\u0105 oznaczane jako \u201ebrudne\u201c, dop\u00f3ki j\u0105dro nie zdo\u0142a ich zapisa\u0107 na no\u015bniku danych. Takie buforowanie przyspiesza dzia\u0142anie aplikacji, poniewa\u017c pami\u0119\u0107 RAM reaguje szybciej ni\u017c jakikolwiek dysk SSD lub HDD, a ma\u0142e operacje zapisu \u0142\u0105cz\u0105 si\u0119 w du\u017ce, sekwencyjne transfery. Zawsze mam na uwadze, ile \u201ebrudu\u201c dopuszczam, poniewa\u017c zbyt du\u017ca ilo\u015b\u0107 buforowanych danych mo\u017ce wyd\u0142u\u017cy\u0107 kolejki lub zwi\u0119kszy\u0107 ryzyko utraty niezapisanych danych w przypadku awarii. Kto rozumie, jak to dzia\u0142a, ten podejmuje lepsze decyzje dotycz\u0105ce writebacku, op\u00f3\u017anie\u0144 i obci\u0105\u017cenia pami\u0119ci. Kr\u00f3tki artyku\u0142 wprowadzaj\u0105cy na temat <a href=\"https:\/\/webhosting.de\/pl\/pamiec-podreczna-z-zapisem-zwrotnym-pamiec-podreczna-jadra-systemu-linux\/\">Pami\u0119\u0107 podr\u0119czna odwr\u00f3cenia<\/a> pomaga w\u0142a\u015bciwie zrozumie\u0107 t\u0119 mechanik\u0119.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-schreibfeintuning-7492.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bezpiecze\u0144stwo danych, fsync i okno awarii<\/h2>\n<p>Warto\u015bci graniczne wp\u0142ywaj\u0105 nie tylko na wydajno\u015b\u0107, ale tak\u017ce na zakres ryzyka. Oszacowuj\u0119 to za pomoc\u0105 prostej zasady praktycznej: maksymalna ilo\u015b\u0107 danych niepewnych podzielona przez sta\u0142\u0105 przepustowo\u015b\u0107 urz\u0105dzenia daje w przybli\u017ceniu czas, po up\u0142ywie kt\u00f3rego bufor zostanie opr\u00f3\u017cniony. Przyk\u0142ad: je\u015bli dopuszcz\u0119 4 GB danych \u201ebrudnych\u201d, a no\u015bnik docelowy osi\u0105ga pr\u0119dko\u015b\u0107 500 MB\/s, ca\u0142kowite zapisanie danych zajmie oko\u0142o 8 sekund. W tym czasie, w przypadku awarii zasilania lub awarii j\u0105dra, najnowsze zapisy mog\u0105 zosta\u0107 utracone.<\/p>\n<p>Aplikacje mog\u0105 wy\u015bwietla\u0107 to okno poprzez <code>fsync()<\/code> lub <code>fdatasync()<\/code> ograniczy\u0107, poniewa\u017c te wywo\u0142ania zmuszaj\u0105 system plik\u00f3w do zapisywania danych (a w zale\u017cno\u015bci od trybu rejestrowania \u2013 r\u00f3wnie\u017c metadanych) na no\u015bniku. Jest to bardziej kosztowne, ale niezb\u0119dne w przypadku baz danych lub dziennik\u00f3w. Dbam o to, by moje limity \u201ebrudnych\u201d danych by\u0142y dostosowane do zachowania synchronizacji: cz\u0119ste <code>fsync()<\/code>-Liczba wy\u015bwietle\u0144 korzysta z ni\u017cszego <em>dirty_ratio<\/em>, aby j\u0105dro nie stosowa\u0142o dodatkowego ograniczania przepustowo\u015bci, skoro dane i tak s\u0105 regularnie zapisywane w pami\u0119ci trwa\u0142ej. Z drugiej strony, w przypadku log\u00f3w, w kt\u00f3rych dominuje operacja do\u0142\u0105czania danych i kt\u00f3re rzadko s\u0105 opr\u00f3\u017cniane, mog\u0119 zezwoli\u0107 na wi\u0119ksze bufory \u2013 zawsze maj\u0105c na uwadze akceptowalne ryzyko utraty danych.<\/p>\n<p>Wa\u017cne s\u0105 r\u00f3wnie\u017c bariery i kolejno\u015b\u0107 zapisu: nowoczesne systemy plik\u00f3w wykorzystuj\u0105 polecenia FUA\/Flush w celu prawid\u0142owego opr\u00f3\u017cnienia pami\u0119ci podr\u0119cznej kontrolera. W przypadku no\u015bnik\u00f3w bez ochrony przed utrat\u0105 zasilania (PLP) du\u017ce bufory zwi\u0119kszaj\u0105 ryzyko; przy zastosowaniu PLP lub zabezpieczenia pami\u0119ci podr\u0119cznej zapisu wi\u0119ksze bufory s\u0105 cz\u0119sto dopuszczalne.<\/p>\n\n<h2>Wsp\u00f3\u0142czynnik zanieczyszczonego t\u0142a: mi\u0119kka warto\u015b\u0107 progowa<\/h2>\n\n<p>Z <strong>dirty_background_ratio<\/strong> Okre\u015blam, od jakiego procentu dost\u0119pnej pami\u0119ci w\u0105tki flusher\u00f3w zaczynaj\u0105 zapisywa\u0107 w tle. Warto\u015b\u0107 ta nie blokuje aplikacji, lecz po cichu uruchamia operacje czyszczenia, aby bufor nie przepe\u0142ni\u0142 si\u0119. Niskie warto\u015bci powoduj\u0105 cz\u0119stsze, ale bardziej r\u00f3wnomierne zapisywanie w tle i wyg\u0142adzaj\u0105 szczyty op\u00f3\u017anie\u0144. Wy\u017csze warto\u015bci pozwalaj\u0105 na wi\u0119ksze buforowanie, co zwi\u0119ksza przepustowo\u015b\u0107 w przypadku du\u017cych sekwencyjnych operacji zapisu, ale mo\u017ce wywo\u0142a\u0107 znaczne szczyty operacji wej\u015bcia\/wyj\u015bcia w przypadku nag\u0142ego opr\u00f3\u017cnienia bufora. Zazwyczaj warto\u015bci domy\u015blne wynosz\u0105 oko\u0142o dziesi\u0119ciu procent, jednak dostosowuj\u0119 ten limit w zale\u017cno\u015bci od no\u015bnika, obci\u0105\u017cenia i wymaga\u0144 bezpiecze\u0144stwa.<\/p>\n\n<h2>Dirty Ratio: gwa\u0142towne hamowanie<\/h2>\n\n<p>Parametr <strong>dirty_ratio<\/strong> oznacza pr\u00f3g, przy kt\u00f3rym j\u0105dro ogranicza wydajno\u015b\u0107 proces\u00f3w zapisuj\u0105cych dane, dop\u00f3ki nie zostanie zapisana wystarczaj\u0105ca liczba stron. Ten sztywny limit chroni pami\u0119\u0107 przed zalaniem danymi, kt\u00f3re nie zosta\u0142y trwale zapisane, i ma tym samym bezpo\u015bredni wp\u0142yw na aplikacje, gdy tylko chc\u0105 one kontynuowa\u0107 generowanie danych. W przypadku baz danych ustawiam t\u0119 warto\u015b\u0107 raczej nisko, aby zapytania zachowa\u0142y sta\u0142y czas odpowiedzi i nie dochodzi\u0142o do d\u0142ugich faz opr\u00f3\u017cniania. Natomiast w przypadku zada\u0144 tworzenia kopii zapasowych stosuj\u0119 wi\u0119ksze bufory, aby efektywnie przesy\u0142a\u0107 du\u017ce bloki danych. Typowe warto\u015bci domy\u015blne wahaj\u0105 si\u0119 od dwudziestu do czterdziestu procent, jednak zawsze dostosowuj\u0119 ten zakres do konkretnego obci\u0105\u017cenia.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_perf_neu_opt_3847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Wzajemne oddzia\u0142ywania i typowe relacje<\/h2>\n\n<p>Obie warto\u015bci graniczne dzia\u0142aj\u0105 jako <strong>Tandem<\/strong> i dopiero razem wywieraj\u0105 sw\u00f3j wp\u0142yw. Zawsze ustawiam warto\u015b\u0107 dirty_background_ratio na ni\u017cszy poziom ni\u017c dirty_ratio, aby j\u0105dro uruchamia\u0142o si\u0119 w tle w odpowiednim czasie, a twarde hamowanie rzadko mia\u0142o miejsce. Jako warto\u015b\u0107 orientacyjn\u0105 cz\u0119sto wybieram od jednej czwartej do po\u0142owy twardego limitu, na przyk\u0142ad 5\u201310 do 20. W ten spos\u00f3b funkcja Writeback uruchamia si\u0119 wystarczaj\u0105co wcze\u015bnie, nie obni\u017caj\u0105c niepotrzebnie przepustowo\u015bci. Kto nie zachowa tej proporcji, do\u015bwiadczy albo zbyt wczesnego ograniczenia przepustowo\u015bci, albo zbyt p\u00f3\u017anego uruchomienia zada\u0144 w tle, co spowoduje odczuwalne skoki op\u00f3\u017anie\u0144.<\/p>\n\n<h2>Sterowanie na poziomie poszczeg\u00f3lnych urz\u0105dze\u0144 i jednostki warstwy blokowej<\/h2>\n<p>Opr\u00f3cz limit\u00f3w globalnych warto przyjrze\u0107 si\u0119 r\u00f3wnie\u017c poziomowi urz\u0105dze\u0144. System Linux rozdziela obci\u0105\u017cenie typu \u201edirty\u201d za pomoc\u0105 tzw. <em>Urz\u0105dzenia obs\u0142ugiwane<\/em> (bdi). W <code>\/sys\/class\/block\/\/bdi\/<\/code> Uwa\u017cam, \u017ce parametry takie jak <code>max_ratio<\/code>, kt\u00f3re okre\u015blaj\u0105, jak\u0105 cz\u0119\u015b\u0107 og\u00f3lnego limitu \u201eDirty-Budget\u201d mo\u017ce wykorzysta\u0107 pojedyncze urz\u0105dzenie. W systemach, w kt\u00f3rych r\u00f3wnolegle dzia\u0142aj\u0105 wolne i szybkie dyski, ograniczam wydajno\u015b\u0107 wolnych no\u015bnik\u00f3w danych, aby nie sta\u0142y si\u0119 one w\u0105skim gard\u0142em.<\/p>\n<p>Istotne znaczenie ma r\u00f3wnie\u017c ograniczenie przepustowo\u015bci warstwy blokowej poprzez <code>\/sys\/block\/\/queue\/wbt_lat_usec<\/code> (Writeback Throttling). W ten spos\u00f3b ustalam docelowe op\u00f3\u017anienie; j\u0105dro ogranicza w\u00f3wczas obci\u0105\u017cenie zwi\u0105zane z zapisem, gdy przekroczy ono ten docelowy czas. W przypadku dysk\u00f3w SATA ch\u0119tnie ustawiam konserwatywne warto\u015bci, aby zapewni\u0107 interaktywno\u015b\u0107. Na bardzo szybkich dyskach NVMe wy\u0142\u0105czam lub zwi\u0119kszam docelowe op\u00f3\u017anienie, aby kontroler m\u00f3g\u0142 w pe\u0142ni wykorzysta\u0107 swoj\u0105 r\u00f3wnoleg\u0142o\u015b\u0107. Harmonogram operacji wej\u015bcia\/wyj\u015bcia (mq-deadline, BFQ, none) dobieram odpowiednio: BFQ sprawdza si\u0119 w systemach interaktywnych o zr\u00f3\u017cnicowanym obci\u0105\u017ceniu, podczas gdy <em>brak<\/em> lub mq-deadline cz\u0119sto sprawdza si\u0119 najlepiej w przypadku zada\u0144 opartych wy\u0142\u0105cznie na przepustowo\u015bci na dyskach NVMe.<\/p>\n<p>Wsp\u00f3\u0142dzia\u0142anie ma kluczowe znaczenie: Czy <em>dirty_background_ratio<\/em> Niskie, ale urz\u0105dzenie jest agresywnie ograniczane przez WBT, co mimo to powoduje widoczne zatory. Dlatego kalibruj\u0119 oba poziomy jednocze\u015bnie \u2013 globalne limity \u201eDirty\u201d dla rozmiaru bufora oraz warstw\u0119 blokow\u0105 dla ochrony przed op\u00f3\u017anieniami.<\/p>\n\n<h2>Ratio a bajty: warto\u015bci domy\u015blne i warianty<\/h2>\n\n<p>W systemach o du\u017cej ilo\u015bci <strong>RAM<\/strong> Warto\u015bci procentowe szybko osi\u0105gaj\u0105 du\u017ce warto\u015bci bezwzgl\u0119dne. W takim przypadku wol\u0119 wprowadzi\u0107 bezwzgl\u0119dne limity za pomoc\u0105 zmiennych `dirty_bytes` i `dirty_background_bytes`, aby wyra\u017anie ograniczy\u0107 rozmiar bufora do oko\u0142o 2\u20138 GB. Oddziela to regulacj\u0119 od silnie zmiennych poziom\u00f3w rozbudowy pami\u0119ci i pozwala utrzyma\u0107 przewidywaln\u0105 ilo\u015b\u0107 danych nieprzechowywanych trwale. Wyb\u00f3r pozostaje dynamiczny: w przypadku ma\u0142ych serwer\u00f3w z niewielk\u0105 ilo\u015bci\u0105 pami\u0119ci RAM warto\u015bci procentowe cz\u0119sto w zupe\u0142no\u015bci wystarczaj\u0105. Ci, kt\u00f3rzy dysponuj\u0105 du\u017c\u0105 pojemno\u015bci\u0105, cz\u0119sto mog\u0105 lepiej planowa\u0107, korzystaj\u0105c z warto\u015bci w bajtach.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametry<\/th>\n      <th>Znaczenie<\/th>\n      <th>Typowe ustawienia domy\u015blne<\/th>\n      <th>Kiedy nale\u017cy to zmieni\u0107?<\/th>\n      <th>Wskaz\u00f3wka<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio<\/td>\n      <td>Rozpocz\u0119cie <strong>Wyr\u00f3wnanie t\u0142a<\/strong> w procentach<\/td>\n      <td>\u2248 10%<\/td>\n      <td>W przypadku waha\u0144 op\u00f3\u017anie\u0144 lub bardzo szybkich dysk\u00f3w SSD\/NVMe<\/td>\n      <td>Ni\u017csza warto\u015b\u0107 = bardziej p\u0142ynne op\u00f3\u017anienie, wy\u017csza warto\u015b\u0107 = wi\u0119kszy bufor<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio<\/td>\n      <td>Twardy <strong>Granica przepustowo\u015bci<\/strong> w procentach<\/td>\n      <td>\u2248 20\u201340%<\/td>\n      <td>W przypadku baz danych ni\u017csze, w przypadku kopii zapasowych wy\u017csze<\/td>\n      <td>Zbyt wysoka \u2192 mo\u017cliwe zablokowania podczas operacji FLUSH<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_background_bytes<\/td>\n      <td>Rozpocz\u0119cie operacji czyszczenia w tle w <strong>Bajty<\/strong><\/td>\n      <td>Wy\u0142\u0105czone, je\u015bli u\u017cywana jest funkcja Ratio<\/td>\n      <td>Du\u017ca pami\u0119\u0107 RAM, sta\u0142e cele buforowania<\/td>\n      <td>Wy\u0142\u0105cza parametry Ratio<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_bytes<\/td>\n      <td>Sztywny limit przepustowo\u015bci w <strong>Bajty<\/strong><\/td>\n      <td>Wy\u0142\u0105czone, je\u015bli u\u017cywana jest funkcja Ratio<\/td>\n      <td>Du\u017ca pami\u0119\u0107 RAM, mo\u017cliwy do zaplanowania limit maksymalny<\/td>\n      <td>Wy\u0142\u0105cza parametry Ratio<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Scenariusze obci\u0105\u017cenia i zalecenia<\/h2>\n\n<p>Sekwencyjne obci\u0105\u017cenia zapisu, takie jak <strong>Kopie zapasowe<\/strong> korzystaj\u0105 z du\u017cych bufor\u00f3w i umiarkowanego zapisu w tle, poniewa\u017c j\u0105dro mo\u017ce zapisywa\u0107 dane na no\u015bniku w du\u017cych partiach. Cz\u0119sto ustawiam tutaj warto\u015b\u0107 dirty_ratio na poziomie od 30 do 40 procent, a dirty_background_ratio na poziomie od 10 do 20 procent. Bazy danych i ma\u0142e aplikacje wykorzystuj\u0105ce losowe operacje wej\u015bcia\/wyj\u015bcia (Random I\/O) wymagaj\u0105 przewidywalnego op\u00f3\u017anienia, dlatego wybieram 10\u201315 procent twardego buforowania i 3\u20135 procent mi\u0119kkiego. W przypadku mieszanych serwer\u00f3w internetowych i aplikacyjnych dobrym kompromisem okazuje si\u0119 15\u201320 procent twardych operacji i 5\u201310 procent mi\u0119kkich. Zakresy te stanowi\u0105 punkt wyj\u015bcia, a ostatecznie licz\u0105 si\u0119 rzeczywiste pomiary w Twoim systemie.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-schreibperformance-feintuning-5648.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aspekty zwi\u0105zane z systemem plik\u00f3w i opcje montowania<\/h2>\n<p>\u015acie\u017cka zapisu ko\u0144czy si\u0119 w systemie plik\u00f3w \u2013 jego strategia wp\u0142ywa na op\u00f3\u017anienia i bezpiecze\u0144stwo. Ext4 z <em>data=ordered<\/em> (Domy\u015blnie) zapisuje dane u\u017cytkowe przed zatwierdzeniem dziennika; <em>data=writeback<\/em> zmniejsza op\u00f3\u017anienie, ale wi\u0105\u017ce si\u0119 z ryzykiem utraty starych danych po awariach. Parametr <code>commit=<\/code> (w sekundach) okre\u015bla cz\u0119stotliwo\u015b\u0107 zapisywania dziennika. Kr\u00f3tsze interwa\u0142y zmniejszaj\u0105 ryzyko utraty danych, ale wymagaj\u0105 wi\u0119kszej liczby operacji wej\u015bcia\/wyj\u015bcia. System plik\u00f3w XFS wykorzystuje dopracowan\u0105 konstrukcj\u0119 dziennika; du\u017ce <em>logbsize<\/em> a odpowiednie wyr\u00f3wnanie pomaga w zadaniach wymagaj\u0105cych du\u017cej przepustowo\u015bci. System plik\u00f3w Btrfs grupuje operacje zapisu za pomoc\u0105 mechanizmu \u201ecopy-on-write\u201d \u2013 stabilizuje to op\u00f3\u017anienia, ale w przypadku niewielkiej liczby losowych operacji zapisu i dysk\u00f3w SSD o ograniczonej pojemno\u015bci mo\u017ce prowadzi\u0107 do fragmentacji. Opcje takie jak <em>nodatacow<\/em> mog\u0105 pom\u00f3c w przypadku okre\u015blonych \u015bcie\u017cek lub ukierunkowanej defragmentacji, gdy wyst\u0119puj\u0105 skoki op\u00f3\u017anie\u0144.<\/p>\n<p>Zwracam r\u00f3wnie\u017c uwag\u0119 na to, \u017ce <em>relatime<\/em>\/<em>noatime<\/em> (ogranicza liczb\u0119 operacji zapisu metadanych), <em>czas leniuchowania<\/em> (op\u00f3\u017ania mtime\/atime w spos\u00f3b bardziej trwa\u0142y) oraz bariery dziennikowania. Zw\u0142aszcza w przypadku kontroler\u00f3w RAID lub w maszynach wirtualnych kluczowe znaczenie ma prawid\u0142owa semantyka pami\u0119ci podr\u0119cznej: nieprawid\u0142owo skonfigurowane pami\u0119ci podr\u0119czne zapisu niwecz\u0105 wszelkie wysi\u0142ki zwi\u0105zane z \u201ebrudnym dostrajaniem\u201d.<\/p>\n\n<h2>Direct I\/O, O_SYNC i zachowanie aplikacji<\/h2>\n<p>Nie ka\u017cda operacja przechodzi przez pami\u0119\u0107 podr\u0119czn\u0105 stron. Za pomoc\u0105 <code>O_DIRECT<\/code> lub <code>O_SYNC<\/code>\/<code>O_DSYNC<\/code> Procesy te omijaj\u0105 cz\u0119\u015bci pami\u0119ci podr\u0119cznej lub wymagaj\u0105 natychmiastowej trwa\u0142o\u015bci. Bazy danych zazwyczaj zapisuj\u0105 dziennik WAL\/Redo-Log synchronicznie, a obszary danych asynchronicznie. Kalibruj\u0119 progi \u201ebrudnych\u201d danych szczeg\u00f3lnie dla \u015bcie\u017cek asynchronicznych, natomiast dla \u015bcie\u017cek synchronicznych gwarantuj\u0119 niskie op\u00f3\u017anienia dzi\u0119ki szybkim dziennikom (NVMe, dedykowane LUN). Gdy aplikacje bardzo cz\u0119sto <code>fsync()<\/code> w przypadku wywo\u0142a\u0144 du\u017ce bufory nie s\u0105 zbyt pomocne \u2013 op\u00f3\u017anienie zale\u017cy wtedy w wi\u0119kszym stopniu od kontrolera, g\u0142\u0119boko\u015bci kolejki i harmonogramu operacji wej\u015bcia\/wyj\u015bcia ni\u017c od <em>dirty_ratio<\/em>.<\/p>\n\n<h2>Praktyczne modyfikacje krok po kroku<\/h2>\n\n<p>Przed ka\u017cd\u0105 zmian\u0105 sprawdzam <strong>warto\u015bci rzeczywiste<\/strong> z <code>sysctl vm.dirty_ratio<\/code> oraz <code>sysctl vm.dirty_background_ratio<\/code>, aby udokumentowa\u0107 stan pocz\u0105tkowy. W przypadku test\u00f3w kr\u00f3tkoterminowych zapisuj\u0119 warto\u015bci bezpo\u015brednio po <code>\/proc\/sys\/vm\/<\/code>dla przyk\u0142adu <code>echo 15 &gt; \/proc\/sys\/vm\/dirty_ratio<\/code> oraz <code>echo 5 &gt; \/proc\/sys\/vm\/dirty_background_ratio<\/code>. Je\u015bli zmiana ta ma charakter trwa\u0142y, zapisuj\u0119 j\u0105 w <code>\/etc\/sysctl.conf<\/code> lub <code>\/etc\/sysctl.d\/*.conf<\/code>. Zmiany wprowadzam za pomoc\u0105 <code>sysctl -p<\/code> natychmiast, abym m\u00f3g\u0142 szybko zmierzy\u0107 efekt. Osoby, kt\u00f3re zag\u0142\u0119biaj\u0105 si\u0119 w temat zasad systemowych, skorzystaj\u0105 z praktycznych wskaz\u00f3wek dotycz\u0105cych <a href=\"https:\/\/webhosting.de\/pl\/optymalizacja-wydajnosci-serwera-hostingowego-za-pomoca-sysctl\/\">Optymalizacja za pomoc\u0105 sysctl<\/a> na serwerach produkcyjnych.<\/p>\n\n<h2>Wyprowadzanie warto\u015bci: przyk\u0142ady obliczeniowe<\/h2>\n<p>Lubi\u0119 zaczyna\u0107 od konkretnych parametr\u00f3w. Przyk\u0142ad 1: serwer WWW\/aplikacji z 64 GB pami\u0119ci RAM i dyskiem NVMe. Celem jest p\u0142ynne op\u00f3\u017anienie. Ustawiam <code>dirty_background_bytes=1073741824<\/code> (1 GB) oraz <code>dirty_bytes=3221225472<\/code> (3 GB). Przy sta\u0142ej przepustowo\u015bci NVMe wynosz\u0105cej 2 GB\/s oznacza to oko\u0142o 0,5\u20131,5 sekundy na opr\u00f3\u017cnienie \u2013 co jest dobrym wynikiem w przypadku obci\u0105\u017cenia interaktywnego. Przyk\u0142ad 2: W\u0119ze\u0142 kopii zapasowej z 128 GB pami\u0119ci RAM, szybki macierz RAID SATA o przepustowo\u015bci 800 MB\/s. Wybieram <code>dirty_background_ratio=10<\/code>, <code>dirty_ratio=35<\/code>. W warto\u015bciach bezwzgl\u0119dnych jest to ok. 12,8 GB i 44,8 GB; opr\u00f3\u017cnienie macierzy RAID zajmuje 16\u201356 sekund. To w porz\u0105dku, poniewa\u017c zadanie nie jest interaktywne.<\/p>\n<p>Przyk\u0142ad 3: Serwer bazy danych z 256 GB pami\u0119ci RAM, oddzielny dziennik na dysku NVMe, dane na macierzy SSD. Stosuj\u0119 ograniczenia absolutne, aby unikn\u0105\u0107 warto\u015bci odstaj\u0105cych: <code>dirty_background_bytes=2147483648<\/code> (2 GB), <code>dirty_bytes=8589934592<\/code> (8 GB). Dzi\u0119ki temu rozmiar okna awarii pozostaje przewidywalny, a gwa\u0142towne spowolnienia podczas przechodzenia przez punkty kontrolne s\u0105 ograniczone.<\/p>\n\n<h2>Czas odwr\u00f3cenia zapisu i powi\u0105zane parametry<\/h2>\n\n<p>Opr\u00f3cz warto\u015bci granicznych wp\u0142ywaj\u0105 na to <strong>Timer<\/strong> spos\u00f3b odtwarzania danych, a co za tym idzie \u2013 p\u0142ynno\u015b\u0107 dzia\u0142ania aplikacji. Dzi\u0119ki <code>vm.dirty_writeback_centisekundy<\/code> reguluj\u0119 cz\u0119stotliwo\u015b\u0107, z jak\u0105 j\u0105dro budzi program Flusher, podczas gdy <code>vm.dirty_expire_centisecs<\/code> okre\u015bla maksymalny wiek, jaki mog\u0105 osi\u0105gn\u0105\u0107 brudne strony. Kr\u00f3tsze interwa\u0142y zapewniaj\u0105 cz\u0119stsze, ale mniejsze operacje flush, natomiast d\u0142u\u017csze interwa\u0142y pozwalaj\u0105 zaoszcz\u0119dzi\u0107 na wywo\u0142aniach wej\u015bcia\/wyj\u015bcia, ale wi\u0105\u017c\u0105 si\u0119 z ryzykiem powstania wi\u0119kszych pakiet\u00f3w. Dostosowuj\u0119 te warto\u015bci tylko wtedy, gdy pomiary wskazuj\u0105 na rzeczywiste wady, na przyk\u0142ad zbyt rzadkie operacje flush na szybkich dyskach NVMe. Kto post\u0119puje w tej kwestii metodycznie, uniknie waha\u0144 mi\u0119dzy zbyt intensywn\u0105 a zbyt powoln\u0105 aktywno\u015bci\u0105 writeback.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_performance_finetune_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitorowanie i precyzyjna regulacja<\/h2>\n\n<p>Po wprowadzeniu zmian zauwa\u017cam, \u017ce <strong>ci\u0105g\u0142y<\/strong> wska\u017aniki s\u0142u\u017c\u0105ce do uwidocznienia sukces\u00f3w i skutk\u00f3w ubocznych. W <code>\/proc\/meminfo<\/code> Sprawdzam \u201eDirty\u201c i \u201eWriteback\u201c, aby zobaczy\u0107 stan bufor\u00f3w i aktywne operacje flush. Narz\u0119dzia takie jak iostat, sar czy atop pokazuj\u0105 mi przepustowo\u015b\u0107, kolejki i trendy op\u00f3\u017anie\u0144. Odpowiednie wprowadzenie do metryk zawiera ten artyku\u0142 na temat <a href=\"https:\/\/webhosting.de\/pl\/server-io-wait-analyse-iostat-vmstat-metrics-disk\/\">Analiza czasu oczekiwania na operacje wej\u015bcia\/wyj\u015bcia<\/a>. Dopiero na podstawie tych danych zmniejszam lub zwi\u0119kszam limity ma\u0142ymi krokami, aby nie wyst\u0105pi\u0142y \u017cadne nieoczekiwane skutki uboczne.<\/p>\n\n<h2>Kontenery, cgroups i sprawiedliwy podzia\u0142 zasob\u00f3w<\/h2>\n<p>W \u015brodowiskach kontenerowych obci\u0105\u017cenia wsp\u00f3\u0142dziel\u0105 te same mechanizmy j\u0105dra. Funkcja Cgroup-Writeback zapewnia, \u017ce brudne strony s\u0105 przypisywane do podmiotu, kt\u00f3ry je wygenerowa\u0142. Korzystam z kontroler\u00f3w wej\u015bcia\/wyj\u015bcia cgroup\u00f3w (blkcg), aby ogranicza\u0107 przepustowo\u015b\u0107 lub liczb\u0119 operacji IOPS na kontener, gdy poszczeg\u00f3lni najemcy zbyt intensywnie buforuj\u0105 dane. Bezwzgl\u0119dne limity bajt\u00f3w na poziomie hosta (<em>dirty_bytes<\/em>) zapobiegaj\u0105 sytuacji, w kt\u00f3rej pojedynczy go\u015b\u0107 poch\u0142ania ca\u0142y bud\u017cet na \u201eDirty\u201d. Dodatkowo ograniczam pami\u0119\u0107 poprzez <code>memory.max<\/code>, aby funkcja Writeback nie reagowa\u0142a dopiero po globalnym obci\u0105\u017ceniu. Cel pozostaje ten sam: \u017cadne obci\u0105\u017cenie go\u015bcia nie mo\u017ce powodowa\u0107 ogranicze\u0144 w skali hosta w zakresie <em>dirty_ratio<\/em> wymusi\u0107.<\/p>\n\n<h2>\u015arodowiska hostingowe i maszyny wirtualne<\/h2>\n\n<p>W konfiguracjach wielodost\u0119pnych i maszynach wirtualnych zwracam uwag\u0119 na <strong>Overbooking<\/strong> pami\u0119ci RAM i operacji wej\u015bcia\/wyj\u015bcia, poniewa\u017c limity procentowe maj\u0105 tam inny wp\u0142yw. Bezwzgl\u0119dne limity w bajtach mog\u0105 zapobiega\u0107 sytuacji, w kt\u00f3rej poszczeg\u00f3lne maszyny-go\u015bcie tworz\u0105 zbyt du\u017ce bufory i spowalniaj\u0105 s\u0105siad\u00f3w. Uwzgl\u0119dniam deduplikacj\u0119 pami\u0119ci, mechanizm ballooning oraz pami\u0119ci podr\u0119czne kontroler\u00f3w, poniewa\u017c nak\u0142adaj\u0105 si\u0119 one na efekty buforowania. W przypadku serwer\u00f3w zarz\u0105dzanych op\u0142aca si\u0119, gdy dostawca ustawia sensowne warto\u015bci domy\u015blne, aby klienci mogli cieszy\u0107 si\u0119 sta\u0142ymi czasami odpowiedzi. Kto obs\u0142uguje w\u0142asne w\u0119z\u0142y, zyskuje dzi\u0119ki precyzyjnie zdefiniowanym ustawieniom profil\u00f3w dla ka\u017cdej klasy obci\u0105\u017cenia.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/DirtyRatioTuning1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cz\u0119ste nieporozumienia i przeszkody<\/h2>\n<ul>\n  <li><strong>\u201eWi\u0119kszy zapas = coraz wi\u0119ksza przepustowo\u015b\u0107.\u201c<\/strong> Nie jest to w\u0142a\u015bciwe w przypadku obci\u0105\u017ce\u0144 opartych g\u0142\u00f3wnie na operacjach losowych lub urz\u0105dze\u0144 o ma\u0142ej g\u0142\u0119boko\u015bci kolejki. Zbyt du\u017ce bufory powoduj\u0105 gwa\u0142towne opr\u00f3\u017cnianie i tworzenie si\u0119 kolejek.<\/li>\n  <li><strong>\u201eWska\u017anik dirty_ratio nie ma wp\u0142ywu na operacje odczytu.\u201c<\/strong> Po\u015brednio jednak tak: agresywne fazy zapisu powoduj\u0105 wypchni\u0119cie stron z pami\u0119ci podr\u0119cznej i zwi\u0119kszaj\u0105 op\u00f3\u017anienia odczytu.<\/li>\n  <li><strong>\u201eBajty i rozs\u0105dek si\u0119 sumuj\u0105.\u201c<\/strong> Nie. Je\u015bli ustawisz warianty \u201eBytes\u201d, anuluj\u0105 one odpowiadaj\u0105ce im warianty \u201eRatio\u201d. Trzeba zachowa\u0107 jednoznaczno\u015b\u0107.<\/li>\n  <li><strong>\u201efsync() sprawia, \u017ce limity brudnych danych trac\u0105 znaczenie.\u201c<\/strong> Nie. Cz\u0119ste synchronizacje wprawdzie zmniejszaj\u0105 przedzia\u0142 ryzyka, ale pozosta\u0142a cz\u0119\u015b\u0107 obci\u0105\u017cenia nadal podlega warto\u015bciom granicznym.<\/li>\n  <li><strong>\u201eSzybki no\u015bnik danych rozwi\u0105zuje wszystkie problemy.\u201c<\/strong> Nie, je\u015bli warstwa blokowa ogranicza przepustowo\u015b\u0107 (WBT) lub system plik\u00f3w jest zamontowany w spos\u00f3b nieoptymalny.<\/li>\n  <li><strong>\u201eDrop_caches to narz\u0119dzie do optymalizacji.\u201c<\/strong> Opr\u00f3\u017cnianie pami\u0119ci podr\u0119cznej zniekszta\u0142ca pomiary i pog\u0142\u0119bia skoki op\u00f3\u017anie\u0144. W \u015brodowisku produkcyjnym staram si\u0119 tego unika\u0107.<\/li>\n<\/ul>\n\n<h2>Rozwi\u0105zywanie problem\u00f3w: typowe objawy i sposoby zaradcze<\/h2>\n\n<p>Stos <strong>Szczyty op\u00f3\u017anie\u0144<\/strong>, najpierw obni\u017cam pr\u00f3g dzia\u0142ania w tle, aby operacje flusher\u00f3w rozpoczyna\u0142y si\u0119 wcze\u015bniej, a du\u017ce fale zapisu pojawia\u0142y si\u0119 rzadziej. Je\u015bli aplikacje okresowo ulegaj\u0105 zablokowaniu, zazwyczaj oznacza to, \u017ce twardy limit jest zbyt wysoki lub no\u015bnik nie radzi sobie z pojawiaj\u0105cymi si\u0119 seriami operacji flush. W takich przypadkach obni\u017cam warto\u015b\u0107 dirty_ratio, sprawdzam ustawienia odczytu z wyprzedzeniem (read-ahead) i przygl\u0105dam si\u0119 opcjom dziennika systemu plik\u00f3w. W przypadku bardzo szybkiego sprz\u0119tu NVMe stopniowo zwi\u0119kszam pr\u00f3g dzia\u0142ania w tle, aby nie ogranicza\u0107 sztucznie przepustowo\u015bci. Po ka\u017cdej zmianie kieruj\u0119 si\u0119 wynikami pomiar\u00f3w, a nie przeczuciem.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-schreibperformance-5712.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kr\u00f3tkie podsumowanie dla praktyki<\/h2>\n\n<p>Z kilkoma <strong>\u015aruby regulacyjne<\/strong> Wp\u0142ywam na to, w jaki spos\u00f3b Linux buforuje dane do zapisu, kiedy uruchamiaj\u0105 si\u0119 programy czyszcz\u0105ce bufor (flushery) i kiedy j\u0105dro spowalnia dzia\u0142anie. Wska\u017anik \u201eDirty Background Ratio\u201d zapewnia p\u0142ynne czyszczenie, natomiast wska\u017anik \u201eDirty Ratio\u201d bardziej rygorystycznie ogranicza zu\u017cycie pami\u0119ci RAM. Stosunek tych dw\u00f3ch warto\u015bci decyduje o tym, czy system d\u0105\u017cy raczej do r\u00f3wnomiernych op\u00f3\u017anie\u0144, czy do maksymalnej przepustowo\u015bci. Dokumentuj\u0119 ustawienia domy\u015blne, wprowadzam zmiany ma\u0142ymi krokami i konsekwentnie analizuj\u0119 wyniki pomiar\u00f3w. W ten spos\u00f3b powstaje konfiguracja, kt\u00f3ra rozs\u0105dnie r\u00f3wnowa\u017cy obci\u0105\u017cenie, no\u015bnik i ryzyko, a w praktyce dzia\u0142a zauwa\u017calnie szybciej.<\/p>","protected":false},"excerpt":{"rendered":"<p>Dowiedz si\u0119, jak za pomoc\u0105 parametr\u00f3w \u201elinux dirty ratio\u201d i \u201edirty background ratio\u201d mo\u017cna precyzyjnie zoptymalizowa\u0107 wydajno\u015b\u0107 zapisu i wydajno\u015b\u0107 j\u0105dra serwera oraz efektywnie zarz\u0105dza\u0107 stronami brudnymi.<\/p>","protected":false},"author":1,"featured_media":20851,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20858","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"144","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"linux dirty","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20851","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/20858","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/comments?post=20858"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/20858\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media\/20851"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media?parent=20858"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/categories?post=20858"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/tags?post=20858"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}