{"id":21467,"date":"2026-09-16T18:21:26","date_gmt":"2026-09-16T16:21:26","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-page-cleaner-threads-datenbank\/"},"modified":"2026-09-16T18:21:26","modified_gmt":"2026-09-16T16:21:26","slug":"mariadb-czyszczenie-stron-watki-baza-danych","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pl\/mariadb-page-cleaner-threads-datenbank\/","title":{"rendered":"Zrozumie\u0107 w\u0105tki czyszcz\u0105ce strony w MariaDB: jak wp\u0142ywaj\u0105 one na wydajno\u015b\u0107"},"content":{"rendered":"<p><strong>Narz\u0119dzie do czyszczenia strony<\/strong> W\u0105tek w MariaDB kontroluje spos\u00f3b, w jaki InnoDB zapisuje zmodyfikowane strony z puli bufor\u00f3w na no\u015bnik danych, co pozwala wyr\u00f3wna\u0107 czasy odpowiedzi przy obci\u0105\u017ceniu zapisem. Zrozumienie obecnej architektury, opartej na pojedynczym w\u0105tku czyszcz\u0105cym, pozwala unikn\u0105\u0107 w\u0105skich garde\u0142 w \u015bcie\u017cce zapisu i utrzyma\u0107 <strong>baza danych<\/strong> wydajno\u015b\u0107 na sta\u0142ym poziomie.<\/p>\n\n<h2>Punkty centralne<\/h2>\n\n<ul>\n  <li><strong>Architektura<\/strong>: W\u0105tek czyszcz\u0105cy opr\u00f3\u017cnia brudne strony niezale\u017cnie od instancji puli bufor\u00f3w.<\/li>\n  <li><strong>Wersje<\/strong>: Zmienna <code>innodb_page_cleaners<\/code> zosta\u0142o usuni\u0119te pocz\u0105wszy od wersji MariaDB 10.6.<\/li>\n  <li><strong>LRU \u2013 w centrum uwagi<\/strong>: Wyb\u00f3r operacji flush zale\u017cy od ko\u0144ca listy LRU oraz post\u0119pu tworzenia punkt\u00f3w kontrolnych.<\/li>\n  <li><strong>Mit<\/strong>: Wi\u0119ksza liczba w\u0105tk\u00f3w niekoniecznie oznacza lepsz\u0105 wydajno\u015b\u0107.<\/li>\n  <li><strong>Praktyka<\/strong>: Na wynik najwi\u0119kszy wp\u0142yw maj\u0105 rozmiar puli bufor\u00f3w, przepustowo\u015b\u0107 operacji wej\u015bcia\/wyj\u015bcia oraz tworzenie punkt\u00f3w kontrolnych.<\/li>\n<\/ul>\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\/09\/server-performance-5647.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Jak dok\u0142adnie dzia\u0142a program Page Cleaner<\/h2>\n\n<p>W\u0105tek \u201ePage Cleaner\u201d pisze <strong>Brudny<\/strong> Strony z puli bufor\u00f3w InnoDB, zanim operacje u\u017cytkownika trafi\u0105 bezpo\u015brednio na no\u015bnik danych. W ten spos\u00f3b oddziela operacje zapisu od zapyta\u0144 i zauwa\u017calnie zmniejsza zmienno\u015b\u0107 czas\u00f3w odpowiedzi, zw\u0142aszcza podczas szczyt\u00f3w obci\u0105\u017cenia. Postrzegam Cleaner jako regulator rytmu: dzieli operacje zapisu na odpowiednie porcje, zamiast niekontrolowanie przetwarza\u0107 du\u017ce fale danych. W\u0105tek ten pobiera strony, kt\u00f3re znalaz\u0142y si\u0119 na ko\u0144cu listy LRU, dzi\u0119ki czemu pami\u0119\u0107 podr\u0119czna szybko zostaje zwolniona dla cz\u0119sto u\u017cywanych danych. Jednocze\u015bnie przyspiesza on tworzenie punktu kontrolnego, aby w pami\u0119ci nie pozostawa\u0142o zbyt wiele niezapisanych zmian. Kto zrozumie ten proces, szybciej zorientuje si\u0119, czy <strong>I\/O<\/strong> czy przyczyn\u0105 jest w\u0105skie gard\u0142o, czy te\u017c problem wynika raczej z zbyt ma\u0142ej pami\u0119ci podr\u0119cznej i zbyt du\u017cej liczby brudnych stron.<\/p>\n\n<h2>Wersja: Z wielu w\u0105tk\u00f3w w jeden<\/h2>\n\n<p>W przesz\u0142o\u015bci mo\u017cna by\u0142o skonfigurowa\u0107 kilka program\u00f3w czyszcz\u0105cych, jednak w wersji MariaDB 10.5.1 rozpocz\u0119to przebudow\u0119, a w wersji MariaDB 10.6 usuni\u0119to <strong>innodb_page_cleaners<\/strong> ostatecznie. Od tamtej pory zajmuje si\u0119 tym jedna osoba <code>buf_flush_page_cleaner<\/code>-Jeden w\u0105tek obs\u0142uguje wszystkie instancje puli bufor\u00f3w. Zmniejsza to koszty koordynacji, u\u0142atwia optymalizacj\u0119 i odzwierciedla przekonanie, \u017ce dobry algorytm jest wa\u017cniejszy ni\u017c r\u00f3\u017cnorodno\u015b\u0107 w\u0105tk\u00f3w. Kto korzysta z instrukcji zaczerpni\u0119tych ze starszych artyku\u0142\u00f3w dotycz\u0105cych MySQL, szybko natrafia na parametry, kt\u00f3re obecnie nie maj\u0105 \u017cadnego wp\u0142ywu. Zanim wprowadz\u0119 jakiekolwiek rzekome zmiany, najpierw sprawdzam dok\u0142adn\u0105 wersj\u0119 MariaDB. W ten spos\u00f3b unikam straty czasu i skupiam si\u0119 na parametrach, kt\u00f3re maj\u0105 wp\u0142yw na <strong>\u015acie\u017cka zapisu<\/strong> rzeczywi\u015bcie wp\u0142yn\u0105\u0107.<\/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\/09\/mariadb_perfmeeting_3829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pula bufor\u00f3w, brudne strony i LRU<\/h2>\n\n<p>Pula bufor\u00f3w przechowuje cz\u0119sto u\u017cywane dane w pami\u0119ci RAM i pozwala zaoszcz\u0119dzi\u0107 na kosztownych <strong>Dysk<\/strong>-dost\u0119py. Gdy tylko transakcje zapisuj\u0105 dane, powstaj\u0105 \u201ebrudne strony\u201d, kt\u00f3re pocz\u0105tkowo istniej\u0105 wy\u0142\u0105cznie w pami\u0119ci. Modu\u0142 czyszcz\u0105cy zapisuje je w odpowiednim czasie, aby na ko\u0144cu zwolni\u0107 miejsce w LRU, a cz\u0119sto odczytywane strony pozostawa\u0142y na g\u00f3rze pami\u0119ci podr\u0119cznej. Zwracam uwag\u0119 na to, ile instancji puli bufor\u00f3w jest aktywnych i jak rozk\u0142ada si\u0119 dost\u0119p, poniewa\u017c r\u00f3wnoleg\u0142o\u015b\u0107 mo\u017ce z\u0142agodzi\u0107 obci\u0105\u017cenie kolejek. Osoby, kt\u00f3re chc\u0105 zag\u0142\u0119bi\u0107 si\u0119 w ten temat, znajd\u0105 praktyczne wskaz\u00f3wki dotycz\u0105ce <a href=\"https:\/\/webhosting.de\/pl\/mariadb-pula-buforow-instancje-systemy-wielordzeniowe-optymalizacja-wydajnosci-baza-danych\/\">Instancje puli bufor\u00f3w<\/a>, na przyk\u0142ad w przypadku host\u00f3w wielordzeniowych. Ostatecznie wska\u017anik \u201eDirty Page\u201d pokazuje, czy cz\u0119stotliwo\u015b\u0107 opr\u00f3\u017cniania pami\u0119ci podr\u0119cznej nad\u0105\u017ca za tempem zapisu oraz czy pami\u0119\u0107 podr\u0119czna spe\u0142nia swoje <strong>Hity<\/strong> materia\u0142y eksploatacyjne.<\/p>\n\n<h2>Post\u0119p w punktach kontrolnych i op\u00f3\u017anienie<\/h2>\n\n<p>Punkt kontrolny ustawia znacznik, do kt\u00f3rego zmiany s\u0105 bezpiecznie zapisane na no\u015bniku danych, a modu\u0142 czyszcz\u0105cy strony przesuwa ten znacznik do przodu. Je\u015bli punkt kontrolny pozostaje w tyle, wzrasta stopie\u0144 wykorzystania dziennika oraz amplifikacja zapisu, co znajduje odzwierciedlenie w czasie zatwierdzania oraz warto\u015bci szczytowej n podczas zapyta\u0144. Regularnie sprawdzam, jak bardzo waha si\u0119 odleg\u0142o\u015b\u0107 punktu kontrolnego i czy modu\u0142 czyszcz\u0105cy powoduje zbyt du\u017ce wahania. Je\u015bli wyg\u0142adzanie nie powiedzie si\u0119, gro\u017c\u0105 okresy szczytowego obci\u0105\u017cenia, podczas kt\u00f3rych w\u0105tki u\u017cytkownik\u00f3w ulegaj\u0105 zablokowaniu. Aby lepiej to zrozumie\u0107, warto przyjrze\u0107 si\u0119 <a href=\"https:\/\/webhosting.de\/pl\/checkpointing-bazy-danych-write-amplification-hosting-guide-scaling\/\">Tworzenie punkt\u00f3w kontrolnych i amplifikacja zapisu<\/a> w kontek\u015bcie hostingu. Kto analizuje te wska\u017aniki, ten szybko zorientuje si\u0119, czy <strong>Sp\u0142ukiwanie<\/strong>-czy praca zostanie wykonana na czas, czy te\u017c system b\u0119dzie musia\u0142 nadrabia\u0107 zaleg\u0142o\u015bci w p\u00f3\u017aniejszych fazach.<\/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\/09\/mariadb-threads-performance-6574.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Typowe nieporozumienia zwi\u0105zane z tuningiem<\/h2>\n\n<p>Wiele os\u00f3b spodziewa si\u0119, \u017ce dodatkowe w\u0105tki dzia\u0142aj\u0105ce w tle automatycznie zapewni\u0105 wi\u0119ksz\u0105 przepustowo\u015b\u0107, jednak w tym przypadku tak nie jest. Decyduj\u0105ce znaczenie ma jako\u015b\u0107 algorytmu flush oraz odpowiednia dawka <strong>I\/O<\/strong>-Praca w ka\u017cdym przedziale czasowym. Zbyt agresywny modu\u0142 czyszcz\u0105cy powoduje kr\u00f3tkie skoki obci\u0105\u017cenia, kt\u00f3re wyd\u0142u\u017caj\u0105 czasy odpowiedzi. Zbyt \u0142agodny modu\u0142 czyszcz\u0105cy gromadzi zbyt wiele brudnych stron, co prowadzi p\u00f3\u017aniej do wi\u0119kszych fal opr\u00f3\u017cniania pami\u0119ci. Oba przypadki powoduj\u0105 efekt \u201eakordeonu\u201d w op\u00f3\u017anieniach. Dlatego d\u0105\u017c\u0119 do uzyskania r\u00f3wnomiernego wzorca, kt\u00f3ry b\u0119dzie pasowa\u0142 do podsystemu pami\u0119ci i w jak najmniejszym stopniu obci\u0105\u017ca\u0142 w\u0105tki u\u017cytkownik\u00f3w <strong>zablokowany<\/strong>.<\/p>\n\n<h2>Wska\u017aniki i monitorowanie: co sprawdzam<\/h2>\n\n<p>Podejmuj\u0105c decyzje, opieram si\u0119 na danych liczbowych, a nie na przeczuciu. Obserwuj\u0119 odsetek brudnych stron, post\u0119p tworzenia punkt\u00f3w kontrolnych, wska\u017aniki zapisu i Fsync, a tak\u017ce czasy oczekiwania na pliki redo-log i pliki danych. Je\u015bli czasy zatwierdzania zmieniaj\u0105 si\u0119 pod obci\u0105\u017ceniem, sprawdzam zaleg\u0142o\u015bci w opr\u00f3\u017cnianiu pami\u0119ci podr\u0119cznej oraz rozmiar plik\u00f3w redo-log. R\u00f3wnie\u017c odsetek stron na ko\u0144cu listy LRU m\u00f3wi co\u015b o presji ewakuacji i zapotrzebowaniu na operacje flush. Odchylenia w warto\u015bciach IOPS wskazuj\u0105, \u017ce modu\u0142 czyszcz\u0105cy zapisuje zbyt du\u017ce pakiety lub \u017ce osi\u0105gni\u0119to limit pami\u0119ci masowej. Te punkty pomiarowe ujawniaj\u0105, czy w\u0105skim gard\u0142em jest raczej rozmiar pami\u0119ci podr\u0119cznej, <strong>Pami\u0119\u0107<\/strong>- dotyczy przepustowo\u015bci lub strategii flush.<\/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\/09\/mariadb_page_cleaner_5372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Konfiguracja: w\u0142a\u015bciwy dob\u00f3r rozmiar\u00f3w i przepustowo\u015bci wej\u015b\u0107\/wyj\u015b\u0107<\/h2>\n\n<p>Najwa\u017cniejszymi parametrami pozostaj\u0105 rozmiar puli bufor\u00f3w, przepustowo\u015b\u0107 we\/wy oraz uk\u0142ad dziennika. Wi\u0119ksza pula bufor\u00f3w zmniejsza obci\u0105\u017cenie zwi\u0105zane z odczytem, ale nie mo\u017ce dopu\u015bci\u0107 do niekontrolowanego wzrostu odsetka brudnych stron. Parametry wydajno\u015bci we\/wy okre\u015blaj\u0105, ile danych modu\u0142 czyszcz\u0105cy pr\u00f3buje zapisa\u0107 w jednostce czasu. Zbyt ma\u0142e warto\u015bci prowadz\u0105 do zator\u00f3w, zbyt du\u017ce powoduj\u0105 skoki w profilu op\u00f3\u017anie\u0144. Dostosowuj\u0119 te warto\u015bci do rzeczywistego systemu no\u015bnik\u00f3w danych, zamiast polega\u0107 na abstrakcyjnych warto\u015bciach standardowych. Poni\u017csza tabela podsumowuje istotne ustawienia, kt\u00f3re wp\u0142ywaj\u0105 na zachowanie <strong>Sp\u0142ukiwanie<\/strong>-procesu.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Ustawienie\/Proporcje<\/th>\n      <th>Wp\u0142yw na program Page Cleaner<\/th>\n      <th>Uwaga dotycz\u0105ca MariaDB<\/th>\n      <th>Praktyczna wskaz\u00f3wka<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><code>innodb_buffer_pool_size<\/code><\/td>\n      <td>Wp\u0142ywa na liczb\u0119 \u201ebrudnych stron\u201d i presj\u0119 na usuni\u0119cie<\/td>\n      <td>Wi\u0119ksza pula wymaga sta\u0142ego tempa wyrzucania kart<\/td>\n      <td>Wykorzysta\u0107 pami\u0119\u0107 RAM, ale pozostawi\u0107 rezerw\u0119 dla systemu operacyjnego i <strong>Zapytanie<\/strong>-Pozostawi\u0107 pami\u0119\u0107 podr\u0119czn\u0105<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_io_capacity<\/code> \/ <code>innodb_io_capacity_max<\/code><\/td>\n      <td>Ograniczony zakres planowanych prac zwi\u0105zanych z przep\u0142ukiwaniem<\/td>\n      <td>Dostosuj do rzeczywistej warto\u015bci IOPS dysk\u00f3w SSD\/NVMe<\/td>\n      <td>Zacznij od warto\u015bci konserwatywnej, a nast\u0119pnie stopniowo j\u0105 zwi\u0119kszaj<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_flush_log_at_trx_commit<\/code><\/td>\n      <td>Steruje cz\u0119stotliwo\u015bci\u0105 operacji commit-fsync<\/td>\n      <td>Wyb\u00f3r wp\u0142ywa na czas utwardzania i trwa\u0142o\u015b\u0107<\/td>\n      <td>\u201e1\u201c oznacza najwy\u017csz\u0105 trwa\u0142o\u015b\u0107; \u201e2\/0\u201c \u2013 ni\u017csz\u0105 <strong>Op\u00f3\u017anienie<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Rozmiar dziennika ponownego wykonania<\/td>\n      <td>Dzia\u0142a na odleg\u0142o\u015b\u0107 punktu kontrolnego oraz na fale flush<\/td>\n      <td>Zbyt ma\u0142y rozmiar wymusza cz\u0119ste tworzenie punkt\u00f3w kontrolnych<\/td>\n      <td>Zwi\u0119kszy\u0107 wymiary, aby wyr\u00f3wna\u0107 szczyty zapisu<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_page_cleaners<\/code> (stara wersja)<\/td>\n      <td>Dzisiaj bez wp\u0142ywu<\/td>\n      <td>Usuni\u0119to od wersji MariaDB 10.6<\/td>\n      <td>Nie dotyka\u0107, skupi\u0107 si\u0119 na aktywnych <strong>Parametry<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Przewodnik praktyczny: testowanie krok po kroku<\/h2>\n\n<p>Zanim zaczn\u0119 zmienia\u0107 ustawienia, ustalam najpierw jasn\u0105 warto\u015b\u0107 odniesienia pod obci\u0105\u017ceniem. Nast\u0119pnie dostosowuj\u0119 <code>innodb_io_capacity<\/code> post\u0119puj\u0119 ma\u0142ymi krokami i obserwuj\u0119, czy szczyty op\u00f3\u017anie\u0144 pojawiaj\u0105 si\u0119 rzadziej. Je\u015bli zauwa\u017c\u0119 d\u0142u\u017csze fale flush, zwi\u0119kszam rozmiar dziennika Redo, aby punkt kontrolny zyska\u0142 wi\u0119cej miejsca w buforze. Nast\u0119pnie sprawdzam, czy pula bufor\u00f3w ma wystarczaj\u0105co du\u017co miejsca, aby gor\u0105ce dane nie by\u0142y zbyt szybko wypierane. Ka\u017cdej zmianie daj\u0119 wystarczaj\u0105co du\u017co czasu, aby jej skutki i skutki uboczne mog\u0142y si\u0119 wyra\u017anie ujawni\u0107. Dopiero gdy wska\u017aniki i komfort u\u017cytkowania poprawi\u0105 si\u0119 jednocze\u015bnie, zaznaczam <strong>Krok<\/strong> od.<\/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\/09\/mariadb-pagecleaner-4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Wp\u0142yw bufora Doublewrite<\/h2>\n\n<p>Bufor Doublewrite chroni strony przed cz\u0119\u015bciowym zapisem i uszkodzonymi blokami, ale jednocze\u015bnie wp\u0142ywa na szybko\u015b\u0107 zapisu i wzorce opr\u00f3\u017cniania. Zw\u0142aszcza przy du\u017cym udziale aktualizacji mo\u017ce on wp\u0142ywa\u0107 na postrzegan\u0105 przepustowo\u015b\u0107 narz\u0119dzia czyszcz\u0105cego. Nowoczesne systemy pami\u0119ci masowej z trwa\u0142\u0105 kolejno\u015bci\u0105 zapisu w pewnym stopniu \u0142agodz\u0105 ten problem, jednak efekt ten pozostaje mierzalny. Dlatego przed wprowadzeniem zmian w tym zakresie sprawdzam obci\u0105\u017cenie, oczekiwania dotycz\u0105ce integralno\u015bci danych oraz dopuszczalne op\u00f3\u017anienia. Osoby potrzebuj\u0105ce szczeg\u00f3\u0142owych informacji na ten temat znajd\u0105 dodatkowe wyja\u015bnienia w artykule po\u015bwi\u0119conym <a href=\"https:\/\/webhosting.de\/pl\/innodb-bufor-podwojnego-zapisu-bezpieczenstwo-optymalizacja-wydajnosci-glowny-temat\/\">Bufor podw\u00f3jnego zapisu<\/a>. W ten spos\u00f3b mo\u017cna ustali\u0107, czy \u017cywotno\u015b\u0107 i <strong>Ochrona<\/strong> Zapewnienie pierwsze\u0144stwa przed minimalnym op\u00f3\u017anieniem.<\/p>\n\n<h2>Typowe objawy i sposoby post\u0119powania<\/h2>\n\n<p>Je\u015bli czasy commit\u00f3w gwa\u0142townie rosn\u0105, mimo \u017ce procesor jest wolny, oznacza to zator w operacjach flush lub s\u0142ab\u0105 wydajno\u015b\u0107 pami\u0119ci masowej. Du\u017ce wahania warto\u015bci IOPS wskazuj\u0105 na zbyt du\u017ce pakiety flush; w takim przypadku zmniejszam przepustowo\u015b\u0107 operacji we\/wy i powi\u0119kszam dziennik redo. Je\u015bli odsetek brudnych stron pozostaje stale wysoki, oznacza to, \u017ce modu\u0142 czyszcz\u0105cy dzia\u0142a zbyt defensywnie lub pula bufor\u00f3w jest zbyt ma\u0142a. Je\u015bli cz\u0119sto u\u017cywane strony szybko przesuwaj\u0105 si\u0119 na koniec listy LRU, oznacza to brak miejsca w pami\u0119ci podr\u0119cznej lub zbyt du\u017ce obci\u0105\u017cenie zapisem, kt\u00f3re nadmiernie wyczerpuje pul\u0119. W \u015brodowiskach hostingowych cz\u0119sto spowolnienie powoduje wsp\u00f3\u0142dzielona pami\u0119\u0107 masowa; w tym przypadku pomaga jedynie pomiar obci\u0105\u017cenia w ci\u0105gu dnia i, w razie potrzeby, przej\u015bcie na szybsze no\u015bniki. Dokumentuj\u0119 ka\u017cd\u0105 zmian\u0119, aby ustali\u0107 przyczyn\u0119 i <strong>Efekt<\/strong> pozostawa\u0107 jednoznaczne r\u00f3wnie\u017c w przysz\u0142o\u015bci.<\/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\/09\/mariadb-performance-4629.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Jak modu\u0142 czyszcz\u0105cy ustala priorytety mi\u0119dzy list\u0105 Flush a LRU<\/h2>\n<p>Podczas zapisu InnoDB rozr\u00f3\u017cnia dwa g\u0142\u00f3wne \u017ar\u00f3d\u0142a: list\u0119 LRU (strony, kt\u00f3re musz\u0105 zwolni\u0107 miejsce dla nowych operacji) oraz list\u0119 Flush (wszystkie brudne strony, posortowane wed\u0142ug najstarszego numeru sekwencji dziennika). Modu\u0142 czyszcz\u0105cy strony (Page Cleaner) r\u00f3wnowa\u017cy te dwa cele: oczyszcza koniec listy LRU, aby unikn\u0105\u0107 wyrzucania danych, i r\u00f3wnolegle pobiera dane z listy Flush, aby stale przesuwa\u0107 punkt kontrolny do przodu. Je\u015bli wolna przestrze\u0144 w buforze jest pod presj\u0105, priorytet ma operacja LRU-Flush; natomiast gdy odleg\u0142o\u015b\u0107 do punktu kontrolnego wzrasta, modu\u0142 Cleaner zwi\u0119ksza udzia\u0142 operacji z listy Flush. To prze\u0142\u0105czanie wyja\u015bnia, dlaczego profile op\u00f3\u017anie\u0144 zmieniaj\u0105 si\u0119 wraz ze zmieniaj\u0105cym si\u0119 obci\u0105\u017ceniem: gdy wzrasta obci\u0105\u017cenie odczytu, dominuj\u0105 operacje LRU-Flush; gdy wzrasta obci\u0105\u017cenie zapisu, dominuj\u0105 operacje zwi\u0105zane z punktem kontrolnym. Analizuj\u0119 ten wzorzec w danych monitorowania, aby zdecydowa\u0107, czy musz\u0119 raczej zwi\u0119kszy\u0107 przepustowo\u015b\u0107 operacji wej\u015bcia\/wyj\u015bcia, czy rezerw\u0119 dziennika ponownego wykonania.<\/p>\n\n<h2>Adaptacyjne p\u0142ukanie: prawid\u0142owa interpretacja warto\u015bci progowych<\/h2>\n<p>MariaDB wykorzystuje adaptacyjne opr\u00f3\u017cnianie pami\u0119ci (adaptive flushing) w celu dynamicznego dostosowywania szybko\u015bci zapisu do zu\u017cycia redo i odsetka brudnych stron. W praktyce obserwuj\u0119 trzy parametry: warto\u015b\u0107 docelow\u0105 dla brudnych stron, poziom minimalny (low-water mark) oraz aktualn\u0105 szybko\u015b\u0107 zapisu. Je\u015bli odsetek brudnych stron przekracza warto\u015b\u0107 docelow\u0105, modu\u0142 czyszcz\u0105cy zaostrza dzia\u0142anie; je\u015bli spadnie poni\u017cej tej warto\u015bci, dzia\u0142a on bardziej pow\u015bci\u0105gliwie. Zbyt niski poziom minimalny powoduje cz\u0119ste uruchamianie operacji flush i mo\u017ce generowa\u0107 kr\u00f3tkie, ale odczuwalne skoki op\u00f3\u017anie\u0144. Zbyt wysoki poziom pozwala na pozostawienie zbyt du\u017cej ilo\u015bci \u201ebrudu\u201d w pami\u0119ci, co p\u00f3\u017aniej powoduje wi\u0119ksze wahania. Dostosowuj\u0119 warto\u015bci progowe tak, aby odpowiada\u0142y charakterystyce systemu pami\u0119ci: szybkie dyski SSD NVMe radz\u0105 sobie z ci\u0105g\u0142ymi, umiarkowanie wy\u017cszymi cz\u0119stotliwo\u015bciami opr\u00f3\u017cniania; wolniejsze systemy zyskuj\u0105 na p\u0142ynniejszych, mniejszych partiach danych.<\/p>\n\n<h2>W\u0142a\u015bciwe wykorzystanie opcji zwi\u0105zanych z pami\u0119ci\u0105 masow\u0105<\/h2>\n<p>Narz\u0119dzie Page Cleaner nie dzia\u0142a w pr\u00f3\u017cni \u2013 wyb\u00f3r metody czyszczenia pami\u0119ci podr\u0119cznej oraz zachowanie systemu plik\u00f3w maj\u0105 decyduj\u0105cy wp\u0142yw na wynik. Z <code>innodb_flush_method<\/code> kontroluj\u0119, czy InnoDB zapisuje strony bezpo\u015brednio (O_DIRECT), czy te\u017c za po\u015brednictwem pami\u0119ci podr\u0119cznej systemu operacyjnego. Zapis bezpo\u015bredni pozwala unikn\u0105\u0107 podw\u00f3jnego buforowania i stabilizuje op\u00f3\u017anienia w systemie Linux z systemami plik\u00f3w XFS\/EXT4. Systemy plik\u00f3w takie jak ZFS obs\u0142uguj\u0105 jednak O_DIRECT w inny spos\u00f3b; w tym przypadku sprawdzam, czy nale\u017cy zastosowa\u0107 metod\u0119 synchronizowan\u0105 (<em>fsync<\/em>\/<em>O_DSYNC<\/em>), kt\u00f3ry zapewnia bardziej sp\u00f3jny profil. Ponadto warto przyjrze\u0107 si\u0119 funkcji \u201eneighborhood flush\u201d (<em>s\u0105siedzi flush<\/em>): W przypadku macierzy HDD zapis s\u0105siednich blok\u00f3w mo\u017ce by\u0107 uzasadniony, natomiast w przypadku dysk\u00f3w SSD\/NVMe ograniczam go, aby unikn\u0105\u0107 niepotrzebnej amplifikacji zapisu. Kluczowe znaczenie ma to, aby konfiguracja by\u0142a dostosowana do no\u015bnika fizycznego \u2013 nawet najlepszy algorytm czyszczenia niewiele da, je\u015bli spowalnia to dzia\u0142anie podstawowej pami\u0119ci masowej.<\/p>\n\n<h2>Monitorowanie w praktyce: zapytania, kt\u00f3re mi pomagaj\u0105<\/h2>\n<p>Aby uzyska\u0107 szybki przegl\u0105d sytuacji, korzystam z trzech perspektyw: globalnych warto\u015bci stanu, metryk InnoDB oraz okresowego zrzutu danych.<\/p>\n<ul>\n  <li>Podstawowe wska\u017aniki: <code>SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty%';<\/code>, <code>... LIKE 'Innodb_os_log_written';<\/code>, <code>... LIKE 'Innodb_log_waits';<\/code>. Wznoszenie si\u0119 <em>czas oczekiwania na log<\/em>, dziennik ponownego wykonania jest zbyt ma\u0142y lub operacja flush dzia\u0142a zbyt wolno.<\/li>\n  <li>Poziom szczeg\u00f3\u0142owo\u015bci: <code>SHOW ENGINE INNODB STATUS\\G<\/code> dostarcza pozycje punkt\u00f3w kontrolnych (LSN), d\u0142ugo\u015bci list flush oraz informacje o w\u0105skich gard\u0142ach. Por\u00f3wnuj\u0119 \u201eLog sequence number\u201c i \u201eLast checkpoint at\u201c, aby oszacowa\u0107 odleg\u0142o\u015b\u0107 mi\u0119dzy punktami kontrolnymi.<\/li>\n  <li>Bardziej precyzyjna telemetria: <code>SELECT NAME, COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME LIKE 'buffer_%dirty%';<\/code> lub <code>... LIKE 'log_%';<\/code> wskazuje trendy, kt\u00f3re w kr\u00f3tkich testach \u0142atwo przeoczy\u0107.<\/li>\n<\/ul>\n<p>Wa\u017cna jest korelacja: je\u015bli op\u00f3\u017anienia commit\u00f3w rosn\u0105 r\u00f3wnocze\u015bnie ze wzrostem cz\u0119stotliwo\u015bci Fsync, prawdopodobnie ustawienie funkcji \u201eCleaner\u201d jest zbyt rygorystyczne. Je\u015bli wska\u017anik brudnych stron i odleg\u0142o\u015b\u0107 mi\u0119dzy punktami kontrolnymi rosn\u0105 jednocze\u015bnie, oznacza to, \u017ce przepustowo\u015b\u0107 operacji flush jest niewystarczaj\u0105ca lub dziennik redo jest zbyt ma\u0142y.<\/p>\n\n<h2>Profile obci\u0105\u017cenia: OLTP, raportowanie, przetwarzanie zbiorcze<\/h2>\n<p>W zale\u017cno\u015bci od obci\u0105\u017cenia ustalam r\u00f3\u017cne priorytety. W \u015brodowiskach OLTP d\u0105\u017c\u0119 do sta\u0142ych, niewielkich partii operacji flush oraz w\u0105skiego przedzia\u0142u op\u00f3\u017anie\u0144 \u2013 w tym przypadku stosuj\u0119 umiarkowane ustawienia <code>innodb_io_capacity<\/code> oraz wystarczaj\u0105ca wielko\u015b\u0107 bufora redo. W przypadku okien raportowania lub ETL dopuszczam czasowo wy\u017csze cz\u0119stotliwo\u015bci opr\u00f3\u017cniania, dbaj\u0105c jednak o to, by nie przed\u0142u\u017ca\u0142y si\u0119 one a\u017c do okres\u00f3w szczytowego obci\u0105\u017cenia u\u017cytkownik\u00f3w. W przypadku masowego \u0142adowania danych preferuj\u0119 wi\u0119ksze dzienniki powt\u00f3rze\u0144 oraz \u2013 o ile pozwalaj\u0105 na to wymagania dotycz\u0105ce trwa\u0142o\u015bci danych \u2013 tymczasowe z\u0142agodzenie dyscypliny Fsync (<code>innodb_flush_log_at_trx_commit=2<\/code>). Page Cleaner mo\u017ce wtedy nieprzerwanie \u201enadrabia\u0107 zaleg\u0142o\u015bci\u201c, nie spowalniaj\u0105c przy tym operacji u\u017cytkownik\u00f3w. Po zako\u0144czeniu przywracam bardziej restrykcyjne warto\u015bci, aby zapewni\u0107 stabilno\u015b\u0107 codziennej dzia\u0142alno\u015bci.<\/p>\n\n<h2>Biegacze d\u0142ugodystansowi, oczyszczanie i skutki po\u015brednie<\/h2>\n<p>Nawet je\u015bli w\u0105tek czyszcz\u0105cy ma inne cele (usuwanie starszych wersji), jego tempo wp\u0142ywa na og\u00f3ln\u0105 sytuacj\u0119. Je\u015bli stare wersje pozostaj\u0105 w systemie przez d\u0142ugi czas, ro\u015bnie zapotrzebowanie na miejsce, a obci\u0105\u017cenie pami\u0119ci oraz operacji we\/wy rozk\u0142ada si\u0119 w mniej korzystny spos\u00f3b. Mo\u017ce to po\u015brednio obci\u0105\u017ca\u0107 modu\u0142 Page Cleaner, poniewa\u017c wi\u0119cej stron jest przypisanych do puli, a algorytm LRU szybciej znajduje si\u0119 pod presj\u0105. Dlatego te\u017c monitoruj\u0119 op\u00f3\u017anienia w procesie \u201ePurge\u201c i dbam o to, by \u017cadne d\u0142ugotrwa\u0142e transakcje nie \u201eblokowa\u0142y\u201d systemu. Stabilny post\u0119p procesu \u201ePurge\u201d, nieprzerwana praca modu\u0142u \u201eCleaner\u201d, zr\u00f3wnowa\u017cona cz\u0119stotliwo\u015b\u0107 zapisu \u2013 te trzy tryby musz\u0105 ze sob\u0105 wsp\u00f3\u0142gra\u0107.<\/p>\n\n<h2>Lista kontrolna dotycz\u0105ca wykrywania b\u0142\u0119d\u00f3w w \u015bcie\u017cce zapisu<\/h2>\n<ul>\n  <li>Odleg\u0142o\u015b\u0107 od punktu kontrolnego jest du\u017ca i wci\u0105\u017c ro\u015bnie? Zwi\u0119ksz rozmiar dziennika powt\u00f3rze\u0144 i <code>innodb_io_capacity<\/code> podnie\u015b\u0107, a nast\u0119pnie ponownie sprawdzi\u0107 przebieg.<\/li>\n  <li>Wahania IOPS i szczyty liczby operacji commit? <code>innodb_io_capacity<\/code> nieznacznie zmniejszy\u0107, wyg\u0142adzi\u0107 wielko\u015b\u0107 partii, uwzgl\u0119dni\u0107 efekt podw\u00f3jnego zapisu.<\/li>\n  <li>Udzia\u0142 stron brudnych utrzymuje si\u0119 na wysokim poziomie? Zwi\u0119kszy\u0107 pul\u0119 bufor\u00f3w lub zaostrzy\u0107 ustawienia adaptacyjnego opr\u00f3\u017cniania; sprawdzi\u0107 obci\u0105\u017cenie pod k\u0105tem zestaw\u00f3w cz\u0119sto u\u017cywanych.<\/li>\n  <li>Czy widoczne s\u0105 op\u00f3\u017anienia logowania? Albo rezerwa Redo jest zbyt ma\u0142a, albo operacja Flush nie nad\u0105\u017ca. Najpierw nale\u017cy zwi\u0119kszy\u0107 rezerw\u0119 Redo, a nast\u0119pnie precyzyjnie dostroi\u0107 przepustowo\u015b\u0107 modu\u0142u Cleaner.<\/li>\n  <li>Post\u0119p w LSN jest niestabilny? Pakiety Flush s\u0105 niesp\u00f3jne. Nale\u017cy stopniowo zmienia\u0107 warto\u015bci, a\u017c widoczny b\u0119dzie regularny post\u0119p.<\/li>\n  <li>W\u0105skie gard\u0142a zwi\u0105zane z pami\u0119ci\u0105 masow\u0105? Nale\u017cy zweryfikowa\u0107 metod\u0119 flush, harmonogram oraz ustawienia pami\u0119ci podr\u0119cznej RAID\/SAN; jako warto\u015b\u0107 docelow\u0105 nale\u017cy przyj\u0105\u0107 trwa\u0142\u0105 wydajno\u015b\u0107 zamiast szczytowej liczby IOPS.<\/li>\n<\/ul>\n\n<h2>Przyk\u0142ad: Kalibracja w trzech etapach<\/h2>\n<p>W instancji OLTP o du\u017cym obci\u0105\u017ceniu zapisem rozpoczynam od pomiaru obci\u0105\u017cenia w oknie produkcyjnym. Runda 1: Mierz\u0119 poziomy zape\u0142nienia dziennika redo oraz odleg\u0142o\u015b\u0107 do punktu kontrolnego. Dziennik jest cz\u0119sto zape\u0142niony w 70\u201380 %, a odleg\u0142o\u015b\u0107 znacznie si\u0119 waha \u2013 dlatego podwajam rozmiar pliku redo. Runda 2: Po ponownym te\u015bcie op\u00f3\u017anienia si\u0119 wyr\u00f3wnuj\u0105, ale od czasu do czasu pojawiaj\u0105 si\u0119 skoki Fsync. Zmniejszam <code>innodb_io_capacity<\/code> Umiarkowanie, dop\u00f3ki rozk\u0142ad IOPS nie ustabilizuje si\u0119. Runda 3: Wska\u017anik brudnych stron utrzymuje si\u0119 na g\u00f3rnej granicy. Przydzielam wi\u0119cej pami\u0119ci RAM do puli bufor\u00f3w, co odci\u0105\u017ca algorytm LRU i sprawia, \u017ce praca modu\u0142u czyszcz\u0105cego staje si\u0119 bardziej przewidywalna. Wynik: Commit-P95 zauwa\u017calnie spada, krzywa IOPS staje si\u0119 bardziej r\u00f3wnomierna, a punkt kontrolny posuwa si\u0119 naprz\u00f3d w sta\u0142ym tempie \u2013 dok\u0142adnie taki wzorzec, do kt\u00f3rego d\u0105\u017c\u0119.<\/p>\n\n<h2>Kr\u00f3tkie podsumowanie<\/h2>\n\n<p>Pojedynczy w\u0105tek czyszcz\u0105cy organizuje opr\u00f3\u017cnianie brudnych stron, zapewnia ci\u0105g\u0142\u0105 aktualizacj\u0119 punktu kontrolnego oraz chroni zapytania przed gwa\u0142townymi skokami obci\u0105\u017cenia zapisu. Istotnymi parametrami pozostaj\u0105 rozmiar puli bufor\u00f3w, przepustowo\u015b\u0107 wej\u015bcia\/wyj\u015bcia, uk\u0142ad dziennika ponownego wykonania oraz charakterystyka systemu pami\u0119ci. Przestarza\u0142e parametry, takie jak <strong>innodb_page_cleaners<\/strong> Nie zwracam ju\u017c na to uwagi i skupiam si\u0119 na wska\u017anikach maj\u0105cych bezpo\u015bredni wp\u0142yw. Kto \u015bledzi wska\u017aniki takie jak wska\u017anik brudnych stron, odst\u0119p mi\u0119dzy punktami kontrolnymi i czas trwania operacji commit, szybciej wykrywa w\u0105skie gard\u0142a. Stopniowe zmiany oparte na jasnej linii bazowej zapewniaj\u0105 wiarygodne wyniki, nie ukrywaj\u0105c efekt\u00f3w ubocznych. W ten spos\u00f3b Page Cleaner dzia\u0142a cicho w tle, a <strong>Czas reakcji<\/strong> pozostaje sta\u0142a \u2013 nawet pod obci\u0105\u017ceniem.<\/p>","protected":false},"excerpt":{"rendered":"<p>W\u0105tek \u201eMariaDB Page Cleaner\u201d \u2013 wyja\u015bnienie: Modu\u0142 czyszczenia stron w MariaDB InnoDB wp\u0142ywa na liczb\u0119 brudnych stron oraz wydajno\u015b\u0107 bazy danych.<\/p>","protected":false},"author":1,"featured_media":21460,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21467","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"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":"104","_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":"Page Cleaner","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":"21460","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/21467","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=21467"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/21467\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media\/21460"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media?parent=21467"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/categories?post=21467"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/tags?post=21467"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}