{"id":21589,"date":"2026-09-20T11:47:21","date_gmt":"2026-09-20T09:47:21","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-adaptive-flushing-optimieren-performance\/"},"modified":"2026-09-20T11:47:21","modified_gmt":"2026-09-20T09:47:21","slug":"mariadb-optymalizacja-adaptacyjnego-oprozniania-pamieci-w-celu-poprawy-wydajnosci","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pl\/mariadb-adaptive-flushing-optimieren-performance\/","title":{"rendered":"Optymalizacja funkcji Adaptive Flushing w MariaDB: praktyczny przewodnik po zwi\u0119kszaniu wydajno\u015bci"},"content":{"rendered":"<p>Funkcja Adaptive Flushing w MariaDB reguluje, jak szybko <strong>Brudne strony<\/strong> zapisuj\u0119 z puli bufor\u00f3w na no\u015bnik danych, aby dziennik ponownego wykonania nigdy nie sta\u0142 si\u0119 w\u0105skim gard\u0142em. Gdy optymalizuj\u0119 funkcj\u0119 Adaptive Flushing w MariaDB, zmniejszaj\u0105 si\u0119 szczytowe warto\u015bci op\u00f3\u017anie\u0144, a <strong>Punkt kontrolny<\/strong>-Post\u0119py s\u0105 stabilne, a obci\u0105\u017cenie zapisem pozostaje przewidywalne.<\/p>\n\n<h2>Punkty centralne<\/h2>\n\n<ul>\n  <li><strong>Zmierzone warto\u015bci<\/strong> Po pierwsze: poziom zape\u0142nienia dziennika Redo, odsetek brudnych stron, wiek punktu kontrolnego<\/li>\n  <li><strong>Pojemno\u015b\u0107 wej\u015b\u0107\/wyj\u015b\u0107<\/strong> okre\u015bli\u0107 dok\u0142adnie, a nie szacowa\u0107<\/li>\n  <li><strong>Warto\u015bci progowe<\/strong> W\u0142a\u015bciwe ustawienie: adaptive_flushing_lwm i Dirty-Page-LWM<\/li>\n  <li><strong>We\/wy w tle<\/strong> warto\u015bci: io_capacity i io_capacity_max<\/li>\n  <li><strong>Dzienniki ponownego wykonania<\/strong> dob\u00f3r odpowiednich wymiar\u00f3w w celu zapewnienia r\u00f3wnomiernego przep\u0142ywu<\/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\/mariadb-optimierung-team-3052.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Jak dzia\u0142a funkcja Adaptive Flushing w MariaDB<\/h2>\n\n<p>Aktywuj\u0119 logik\u0119 dynamiczn\u0105 za pomoc\u0105 <strong>innodb_adaptive_flushing<\/strong> i kieruj zachowaniami zwi\u0105zanymi z wczesnym ostrzeganiem za pomoc\u0105 <strong>innodb_adaptive_flushing_lwm<\/strong>. Im bardziej zape\u0142niony jest dziennik ponownego wykonania (Redo Log) i im szybciej si\u0119 powi\u0119ksza, tym bardziej agresywnie InnoDB przeprowadza operacje flush, aby nie dosz\u0142o do w\u0105skiego gard\u0142a. Zasada ta wi\u0105\u017ce cz\u0119stotliwo\u015b\u0107 operacji flush z rzeczywist\u0105 przepustowo\u015bci\u0105 zmian, dzi\u0119ki czemu rzadziej wyst\u0119puj\u0105 kr\u00f3tkie skoki obci\u0105\u017cenia we\/wy. Zgodnie z dokumentacj\u0105 MariaDB intensywno\u015b\u0107 ta jest dostosowywana do post\u0119pu tworzenia punkt\u00f3w kontrolnych, aby unikn\u0105\u0107 op\u00f3\u017anie\u0144 zwi\u0105zanych z operacjami zapisu na dysku. Nale\u017cy jednak pami\u0119ta\u0107, \u017ce adaptacyjne opr\u00f3\u017cnianie rozk\u0142ada obci\u0105\u017cenie, ale nie kompensuje zbyt niskiej wydajno\u015bci pami\u0119ci.<\/p>\n\n<h2>Zrozumienie kluczowych wska\u017anik\u00f3w: dziennik powt\u00f3rze\u0144 (Redo-Log), brudne strony (Dirty Pages) i punkty kontrolne (Checkpoints)<\/h2>\n\n<p>Najpierw sprawdzam procentowy poziom nape\u0142nienia <strong>Dzienniki ponownego wykonania<\/strong>, wska\u017anik brudnych stron w puli bufor\u00f3w oraz wiek punkt\u00f3w kontrolnych. Te trzy wska\u017aniki pokazuj\u0105 mi, czy serwer jest w stanie na czas i r\u00f3wnomiernie opr\u00f3\u017cnia\u0107 pami\u0119\u0107 buforow\u0105, czy te\u017c gromadz\u0105 si\u0119 zaleg\u0142o\u015bci. Je\u015bli czas \u017cycia punktu kontrolnego ro\u015bnie zbyt szybko, uruchamia si\u0119 funkcja Adaptive Flushing, ale w\u00f3wczas dodatkowo sprawdzam op\u00f3\u017anienie pami\u0119ci masowej. W przypadku szczeg\u00f3\u0142owych pyta\u0144 dotycz\u0105cych strategii operacji wej\u015bcia\/wyj\u015bcia pomocne jest zapoznanie si\u0119 z odpowiednimi <a href=\"https:\/\/webhosting.de\/pl\/mariadb-metody-flush-innodb-fsync-przewodnik-po-wydajnosci-bufor\/\">Metody flush<\/a>, poniewa\u017c decyduj\u0105 one o tym, jak efektywnie j\u0105dro przetwarza polecenia zapisu. \u0141\u0105cz\u0119 te sygna\u0142y z zmierzon\u0105 przepustowo\u015bci\u0105 operacji wej\u015bcia\/wyj\u015bcia, aby m\u00f3c celowo dostosowywa\u0107 warto\u015bci progowe i zapewni\u0107 sp\u00f3jno\u015b\u0107 ca\u0142ego systemu.<\/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_flushing_meeting_1723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Prawid\u0142owe wyregulowanie \u015brub regulacyjnych<\/h2>\n\n<p>Zaczynam od <strong>innodb_io_capacity<\/strong> i ustaw warto\u015b\u0107 zbli\u017con\u0105 do rzeczywistej mocy ci\u0105g\u0142ej akumulatora, a nie do teoretycznych warto\u015bci maksymalnych. Je\u015bli chodzi o warto\u015bci szczytowe, uwa\u017cam, \u017ce <strong>innodb_io_capacity_max<\/strong> znacznie wy\u017cszy, aby InnoDB m\u00f3g\u0142 na kr\u00f3tko zwi\u0119kszy\u0107 wydajno\u015b\u0107 w sytuacji obci\u0105\u017cenia, nie przeci\u0105\u017caj\u0105c procesora. Warto\u015b\u0107 progow\u0105 <strong>innodb_adaptive_flushing_lwm<\/strong> ustawiam to tak, aby serwer rozpocz\u0105\u0142 preflushing w spos\u00f3b zauwa\u017calny, zanim dziennik redo zape\u0142ni si\u0119 ca\u0142kowicie. Dodatkowo ustawiam <strong>innodb_max_dirty_pages_pct_lwm<\/strong> tak, aby InnoDB m\u00f3g\u0142 wcze\u015bnie podj\u0105\u0107 odpowiednie dzia\u0142ania w miar\u0119 wzrostu wska\u017anika brudnych stron i zapobiec powstawaniu zator\u00f3w. Zmieniam tylko jedn\u0105 warto\u015b\u0107 na cykl, skrupulatnie rejestruj\u0119 efekty i daj\u0119 systemowi czas na przej\u015bcie przez kilka faz obci\u0105\u017cenia, zanim przyst\u0105pi\u0119 do dalszej optymalizacji.<\/p>\n\n<h2>Konkretny pomiar przepustowo\u015bci wej\u015b\u0107\/wyj\u015b\u0107<\/h2>\n\n<p>Mierz\u0119 ci\u0105g\u0142\u0105 wydajno\u015b\u0107 zapisu podczas obci\u0105\u017cenia produkcyjnego, poniewa\u017c syntetyczne testy szczytowe cz\u0119sto budz\u0105 fa\u0142szywe nadzieje, a <strong>R\u00f3wnomierno\u015b\u0107<\/strong> zamaskowa\u0107. Istotne znaczenie maj\u0105 \u015brednie i percentyle w perspektywie \u015brednio- i d\u0142ugoterminowej, kt\u00f3re przetrwaj\u0105 kr\u00f3tkotrwa\u0142e wyg\u0142adzanie danych. Analizuj\u0119 Write-IOPS, przepustowo\u015b\u0107 zapisu, op\u00f3\u017anienia oraz rozk\u0142ad czas\u00f3w odpowiedzi, aby nie skupia\u0107 si\u0119 wy\u0142\u0105cznie na warto\u015bci \u015bredniej. Kto opiera si\u0119 wy\u0142\u0105cznie na warto\u015bci maksymalnej, ryzykuje agresywne fazy opr\u00f3\u017cniania pami\u0119ci, podczas gdy rzeczywiste transakcje ulegaj\u0105 spowolnieniu. Wyci\u0105gam wnioski dotycz\u0105ce <strong>innodb_io_capacity<\/strong> na podstawie obserwowanego zachowania w d\u0142u\u017cszej perspektywie, a nie na podstawie kr\u00f3tkotrwa\u0142ych rekord\u00f3w.<\/p>\n\n<h2>Przegl\u0105d warto\u015bci pocz\u0105tkowych i warto\u015bci granicznych<\/h2>\n\n<p>Warto\u015bci pocz\u0105tkowe traktuj\u0119 jako punkt wyj\u015bcia, a nie jako dogmat, i weryfikuj\u0119 je w oparciu o rzeczywiste obci\u0105\u017cenie, wielko\u015b\u0107 puli bufor\u00f3w oraz wzrost <strong>Dzienniki ponownego wykonania<\/strong>. Systemy SSD i NVMe osi\u0105gaj\u0105 zdecydowanie wy\u017csze warto\u015bci ni\u017c dyski HDD, ale ustawiam te warto\u015bci na takim poziomie, aby operacje odczytu nie trafia\u0142y do kolejki. W przypadku obci\u0105\u017conych system\u00f3w stopniowo zwi\u0119kszam pojemno\u015b\u0107, obserwuj\u0105c jednocze\u015bnie op\u00f3\u017anienia, wiek punkt\u00f3w kontrolnych oraz zu\u017cycie procesora. Je\u015bli wska\u017anik brudnych stron r\u00f3wnomiernie spada, a wahania poziomu zape\u0142nienia dziennika ponownego wykonania malej\u0105, osi\u0105gam bezpieczny margines bezpiecze\u0144stwa. Kluczowe znaczenie ma dla mnie to, \u017ce <strong>Wskaz\u00f3wki<\/strong> kontroluj, zamiast zag\u0142usza\u0107 je nadmiern\u0105 aktywno\u015bci\u0105 operacji wej\u015bcia\/wyj\u015bcia w tle.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Zmienna<\/th>\n      <th>Efekt<\/th>\n      <th>Typowa warto\u015b\u0107 pocz\u0105tkowa dysku twardego (HDD)<\/th>\n      <th>Typowa warto\u015b\u0107 pocz\u0105tkowa dysku SSD<\/th>\n      <th>Typowa warto\u015b\u0107 pocz\u0105tkowa NVMe<\/th>\n      <th>Na co zwracam uwag\u0119<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>innodb_adaptive_flushing<\/td>\n      <td>W\u0142\u0105cz dynamiczne opr\u00f3\u017cnianie<\/td>\n      <td>ON<\/td>\n      <td>ON<\/td>\n      <td>ON<\/td>\n      <td>Kompensacja impuls\u00f3w<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_adaptive_flushing_lwm<\/td>\n      <td>Wczesne przep\u0142ukiwanie<\/td>\n      <td>20\u201330%<\/td>\n      <td>20-40%<\/td>\n      <td>30\u201350%<\/td>\n      <td>Poziom zape\u0142nienia dziennika ponownego wykonania<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_io_capacity<\/td>\n      <td>Podstawowa stawka za przep\u0142ukanie<\/td>\n      <td>100-300<\/td>\n      <td>800\u20132000<\/td>\n      <td>2000\u20138000<\/td>\n      <td>Liczba operacji zapisu na sekund\u0119 (IOPS) przy obci\u0105\u017ceniu ci\u0105g\u0142ym<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_io_capacity_max<\/td>\n      <td>Pr\u00f3g sytuacji kryzysowej<\/td>\n      <td>400\u2013800<\/td>\n      <td>2000-6000<\/td>\n      <td>6000\u201320000<\/td>\n      <td>Usuwanie nadmiaru<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_max_dirty_pages_pct_lwm<\/td>\n      <td>Dirty Page \u2013 niski poziom wody<\/td>\n      <td>5\u201310%<\/td>\n      <td>5\u201315%<\/td>\n      <td>5\u201315%<\/td>\n      <td>Wczesne podj\u0119cie dzia\u0142a\u0144 zaradczych<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\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-adaptive-optimierung-2345.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Rozpoznawanie problem\u00f3w i objaw\u00f3w<\/h2>\n\n<p>Kiedy <strong>Sp\u0142ukiwanie<\/strong>\u2013 Gdy dostrzegam takie skoki, najpierw sprawdzam warto\u015b\u0107 I\/O: je\u015bli jest zbyt niska, gromadz\u0105 si\u0119 brudne strony, a system musi pilnie je usun\u0105\u0107. Je\u015bli warto\u015b\u0107 jest zbyt wysoka, operacje I\/O w tle dominuj\u0105 nad bie\u017c\u0105cym obci\u0105\u017ceniem i powoduj\u0105, \u017ce operacje odczytu musz\u0105 czeka\u0107. Powolny czas \u017cycia punktu kontrolnego (Checkpoint-Age), kt\u00f3ry nagle gwa\u0142townie wzrasta, wskazuje mi, \u017ce serwer reaguje zbyt p\u00f3\u017ano. Jednocze\u015bnie szybko rosn\u0105cy poziom zape\u0142nienia dziennika ponownego wykonania (Redo-Log) sygnalizuje, \u017ce strona zapisu nie nad\u0105\u017ca lub \u017ce dziennik jest zbyt ma\u0142y. Analizuj\u0119 te wzorce \u0142\u0105cznie, poniewa\u017c pojedyncza liczba rzadko w pe\u0142ni wyja\u015bnia zachowanie funkcji Adaptive Flushing.<\/p>\n\n<h2>Dopasowanie rozmiaru dziennika Redo w celu zapewnienia r\u00f3wnomiernego obci\u0105\u017cenia<\/h2>\n\n<p>Wybieram rozmiar <strong>Dzienniki ponownego wykonania<\/strong> tak, aby pozosta\u0142o wystarczaj\u0105co du\u017co miejsca na fale obci\u0105\u017cenia, a punkty kontrolne nie by\u0142y zbyt d\u0142ugie. Wi\u0119kszy dziennik daje funkcji Adaptive Flushing wi\u0119cej swobody w roz\u0142o\u017ceniu pracy, jednak zwracam uwag\u0119 na czasy odzyskiwania i bud\u017cet pami\u0119ci. Je\u015bli dziennik ro\u015bnie co sekund\u0119 w kierunku limitu, rozs\u0105dne zwi\u0119kszenie pojemno\u015bci zmniejsza presj\u0119 i wyg\u0142adza krzyw\u0105 opr\u00f3\u017cniania. Je\u015bli zwi\u0119kszenie rozmiaru nie przynosi ulgi, problem le\u017cy zazwyczaj w nieodpowiedniej przepustowo\u015bci wej\u015bcia\/wyj\u015bcia (I\/O) lub zmiennym op\u00f3\u017anieniu pami\u0119ci masowej. Decyzj\u0119 o ponownym zwi\u0119kszeniu rozmiaru dziennika podejmuj\u0119 dopiero po przeanalizowaniu okien obserwacyjnych, a nie na podstawie pojedynczych chwilowych odczyt\u00f3w.<\/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_optimierung_3412.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Page Cleaner, w\u0105tki i r\u00f3wnoleg\u0142o\u015b\u0107<\/h2>\n\n<p>Sprawdzam liczb\u0119 w\u0105tk\u00f3w programu Page Cleaner, poniewa\u017c odzwierciedlaj\u0105 one r\u00f3wnoleg\u0142\u0105 <strong>Sp\u0142ukiwanie<\/strong>-Kontrola wydajno\u015bci instancji puli bufor\u00f3w. Przy du\u017cym obci\u0105\u017ceniu zapisem dodatkowa r\u00f3wnoleg\u0142o\u015b\u0107 zapewnia wi\u0119ksz\u0105 przepustowo\u015b\u0107, jednak uwa\u017cnie monitoruj\u0119 kolejk\u0119 pami\u0119ci masowej. Je\u015bli no\u015bnik danych traci na wydajno\u015bci z powodu przepe\u0142nionych kolejek, zmniejszam liczb\u0119 w\u0105tk\u00f3w lub ograniczam przepustowo\u015b\u0107 operacji wej\u015bcia\/wyj\u015bcia. Aby lepiej zrozumie\u0107 ten mechanizm, pomocny jest dla mnie przegl\u0105d <a href=\"https:\/\/webhosting.de\/pl\/mariadb-czyszczenie-stron-watki-baza-danych\/\">W\u0105tki dotycz\u0105ce narz\u0119dzia Page Cleaner<\/a>, abym m\u00f3g\u0142 zachowa\u0107 r\u00f3wnowag\u0119 mi\u0119dzy presj\u0105 a sprawiedliwo\u015bci\u0105. Podejmuj\u0119 decyzje w spos\u00f3b pragmatyczny: tyle w\u0105tk\u00f3w, ile trzeba, a jednocze\u015bnie tak ma\u0142o, jak to mo\u017cliwe, \u017ceby czytelnicy nie zostali w tyle.<\/p>\n\n<h2>Bufor Doublewrite: bezpiecze\u0144stwo a szybko\u015b\u0107 zapisu<\/h2>\n\n<p>Bior\u0119 pod uwag\u0119 <strong>Doublewrite<\/strong>-Bufor, poniewa\u017c chroni przed cz\u0119\u015bciowymi b\u0142\u0119dami zapisu, ale wi\u0105\u017ce si\u0119 z dodatkowymi operacjami wej\u015bcia\/wyj\u015bcia. W niezawodnych systemach NVMe ten dodatkowy nak\u0142ad ma mniejsze znaczenie, natomiast w przypadku wolniejszych no\u015bnik\u00f3w jest bardziej odczuwalny. Zanim wprowadz\u0119 zmiany w tym zakresie, mierz\u0119 rzeczywisty wp\u0142yw na op\u00f3\u017anienia i szybko\u015b\u0107 opr\u00f3\u017cniania stron (page-flush-rate). Aby dokona\u0107 rzetelnej oceny, korzystam z bardziej szczeg\u00f3\u0142owych wskaz\u00f3wek dotycz\u0105cych <a href=\"https:\/\/webhosting.de\/pl\/innodb-bufor-podwojnego-zapisu-bezpieczenstwo-optymalizacja-wydajnosci-glowny-temat\/\">Bufor podw\u00f3jnego zapisu<\/a> i sprawdzam, czy inny profil ryzyka i zwrotu b\u0119dzie odpowiedni. Nigdy nie podejmuj\u0119 decyzji pochopnie, poniewa\u017c bezpiecze\u0144stwo danych i przepustowo\u015b\u0107 s\u0105 tu ze sob\u0105 bezpo\u015brednio powi\u0105zane.<\/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_flushing_guide_4528.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitorowanie i wska\u017aniki w praktyce<\/h2>\n\n<p>Oceniam udzia\u0142 \u201ebrudnych stron\u201d, stosunek wska\u017anika flush do wska\u017anika zmian oraz przebieg <strong>Punkt kontrolny<\/strong>-Age. Dodatkowo obserwuj\u0119 procentowe obci\u0105\u017cenie dziennika Redo w czasie, poniewa\u017c liniowy wzrost wskazuje na zbli\u017canie si\u0119 do krytycznych warto\u015bci progowych. \u015aledz\u0119 op\u00f3\u017anienia we\/wy obok statystyk InnoDB, aby m\u00f3c precyzyjnie przyporz\u0105dkowa\u0107 przyczyny i skutki. Po ka\u017cdej zmianie parametr\u00f3w por\u00f3wnuj\u0119 identyczne okna obci\u0105\u017cenia, w przeciwnym razie wyci\u0105gn\u0105\u0142bym b\u0142\u0119dne wnioski. Dokumentuj\u0119 wykresy, poniewa\u017c obraz m\u00f3wi wi\u0119cej ni\u017c pojedynczy punkt pomiarowy i dzi\u0119ki temu mog\u0119 pewnie rozpozna\u0107 za\u0142amania trend\u00f3w.<\/p>\n\n<h2>Plan strojenia krok po kroku<\/h2>\n\n<p>Zaczn\u0119 od realistycznej oceny <strong>Wsp\u00f3\u0142czynnik zapisu<\/strong> i na tej podstawie ustalam warto\u015b\u0107 innodb_io_capacity. Nast\u0119pnie definiuj\u0119 innodb_io_capacity_max jako rozwi\u0105zanie awaryjne na wypadek sytuacji kryzysowych, z wystarczaj\u0105cym marginesem w stosunku do warto\u015bci bazowej. Nast\u0119pnie sprawdzam parametr innodb_adaptive_flushing_lwm i zmniejszam jego warto\u015b\u0107, je\u015bli czas \u017cycia punktu kontrolnego (Checkpoint-Age) jest zbyt d\u0142ugi. Potem ustawiam parametr innodb_max_dirty_pages_pct_lwm tak, aby preflushing rozpoczyna\u0142 si\u0119 w odpowiednim czasie, a szczyty obci\u0105\u017cenia by\u0142y szybko redukowane. Na koniec dostosowuj\u0119 rozmiar dziennika redo, ponownie obserwuj\u0119 kilka cykli obci\u0105\u017cenia i dokumentuj\u0119 ka\u017cd\u0105 zmian\u0119, zanim podejm\u0119 kolejny krok.<\/p>\n\n<h2>Mechanizm sp\u0142ukuj\u0105cy pod pokryw\u0105<\/h2>\n\n<p>Rozr\u00f3\u017cniam dwa g\u0142\u00f3wne czynniki motywuj\u0105ce do pisania: <strong>Opr\u00f3\u017cnianie listy Flush<\/strong> (wynikaj\u0105ce z post\u0119p\u00f3w w Checkpoint) oraz <strong>P\u0142ukanie LRU<\/strong> (spowodowane brakiem wolnych stron). Gdy pula bufor\u00f3w si\u0119 zape\u0142ni i zabraknie wolnych stron, operacja LRU-Flushing zmusza mnie do natychmiastowego zapisu, co powoduje skoki op\u00f3\u017anie\u0144. Adaptacyjne opr\u00f3\u017cnianie ma na celu unikni\u0119cie takich sytuacji poprzez ci\u0105g\u0142e opr\u00f3\u017cnianie listy flush. Aby to si\u0119 uda\u0142o, utrzymuj\u0119 sta\u0142y odsetek wolnych stron i monitoruj\u0119 takie warto\u015bci, jak g\u0142\u0119boko\u015b\u0107 skanowania LRU oraz obci\u0105\u017cenie poszczeg\u00f3lnych instancji puli bufor\u00f3w. Im bardziej r\u00f3wnomiernie przetwarzana jest lista flush, tym rzadziej musz\u0119 czeka\u0107 na wolne strony w tle.<\/p>\n\n<p>Zwracam przy tym uwag\u0119 na zwi\u0105zek mi\u0119dzy <strong>innodb_buffer_pool_instances<\/strong>, <strong>innodb_page_cleaners<\/strong> oraz fizycznej przepustowo\u015bci wej\u015bcia\/wyj\u015bcia. Wi\u0119ksza liczba instancji i w\u0105tk\u00f3w czyszcz\u0105cych zwi\u0119ksza r\u00f3wnoleg\u0142o\u015b\u0107, ale tylko w takim zakresie, w jakim nie dochodzi do przepe\u0142nienia kolejek pami\u0119ci masowej. Je\u015bli operacje flushowania osi\u0105gaj\u0105 du\u017ce d\u0142ugo\u015bci kolejek, jest to znak, \u017ce nale\u017ca\u0142o przeprowadzi\u0107 flushowanie wcze\u015bniej i wolniej \u2013 w\u0142a\u015bnie tym zajmuj\u0119 si\u0119 za pomoc\u0105 parametru innodb_adaptive_flushing_lwm oraz warto\u015bci bazowych i maksymalnych pojemno\u015bci.<\/p>\n\n<h2>Potwierdzenie transakcji, redo i dziennik binarny w kontek\u015bcie<\/h2>\n\n<p>Analizuj\u0119 \u015bcie\u017cki commit\u00f3w i gwarancje trwa\u0142o\u015bci w kontek\u015bcie wyg\u0142adzania operacji flush. <strong>innodb_flush_log_at_trx_commit<\/strong> a synchronizacja binlogu wp\u0142ywa na cz\u0119stotliwo\u015b\u0107 wykonywania operacji fsync przez system oraz na intensywno\u015b\u0107 kr\u00f3tkotrwa\u0142ych skok\u00f3w obci\u0105\u017cenia. Moje wytyczne:<\/p>\n\n<ul>\n  <li>1: Maksymalna trwa\u0142o\u015b\u0107 (ponowne zapisywanie na no\u015bniku przy ka\u017cdym commitcie). Bezpieczne, ale wymaga cz\u0119stego stosowania fsync i mo\u017ce powodowa\u0107 wi\u0119ksze op\u00f3\u017anienia.<\/li>\n  <li>2: Redo jest opr\u00f3\u017cniane co sekund\u0119, a Commit zapisuje dane wy\u0142\u0105cznie w pami\u0119ci podr\u0119cznej systemu operacyjnego. Szczyty obci\u0105\u017cenia s\u0105 mniejsze, ale w zamian nara\u017cam si\u0119 na utrat\u0119 danych w przypadku awarii systemu operacyjnego lub hosta.<\/li>\n  <li>0: Podobnie jak w przypadku 2, jednak buforowanie jest jeszcze bardziej agresywne. W systemach produkcyjnych nale\u017cy stosowa\u0107 z rozwag\u0105.<\/li>\n<\/ul>\n\n<p>W po\u0142\u0105czeniu z synchronizacj\u0105 Binlog (<strong>sync_binlog<\/strong>) oraz dzi\u0119ki efektom Group Commit mog\u0119 grupowa\u0107 zatwierdzenia i zmniejszy\u0107 liczb\u0119 twardych synchronizacji. Wa\u017cne jest, aby nie nadu\u017cywa\u0107 tych narz\u0119dzi jako substytutu prawid\u0142owego dostrajania adaptacyjnego opr\u00f3\u017cniania bufora. Zawsze wsp\u00f3lnie oceniam ryzyko, wymagania dotycz\u0105ce zgodno\u015bci oraz po\u017c\u0105dany profil op\u00f3\u017anie\u0144 i dostosowuj\u0119 ustawienia tylko w takim zakresie, w jakim pozwalaj\u0105 na to zasady biznesowe.<\/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_optimierung_3412.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>W\u0105tki do usuni\u0119cia, d\u0142ugo\u015b\u0107 historii i d\u0142ugotrwa\u0142e w\u0105tki<\/h2>\n\n<p>Mam t\u0119 <strong>InnoDB-Purge<\/strong> Warto zwr\u00f3ci\u0107 uwag\u0119: du\u017ca liczba usuni\u0119tych lub zaktualizowanych wierszy generuje dane operacji cofania, kt\u00f3re s\u0105 czyszczone asynchronicznie. Je\u015bli liczba <em>D\u0142ugo\u015b\u0107 historii<\/em> W miar\u0119 wzrostu obci\u0105\u017cenia w tle wzrasta zu\u017cycie zasob\u00f3w i dochodzi do rywalizacji o operacje wej\u015bcia\/wyj\u015bcia z modu\u0142ami czyszcz\u0105cymi strony. Mo\u017ce to po\u015brednio spowolni\u0107 dzia\u0142anie funkcji Adaptive Flushing. \u015arodkami zaradczymi s\u0105 odpowiednie ustawienie warto\u015bci r\u00f3wnoleg\u0142o\u015bci czyszczenia oraz unikanie d\u0142ugotrwa\u0142ych transakcji, kt\u00f3re sztucznie utrzymuj\u0105 histori\u0119 w stanie otwartym. Ponadto planuj\u0119 operacje wsadowe w taki spos\u00f3b, aby kontrolowa\u0107 ilo\u015b\u0107 operacji \u201eredo\u201d i \u201eundo\u201d, zamiast zmienia\u0107 miliony wierszy partiami w kr\u00f3tkim czasie.<\/p>\n\n<h2>Bufor zmian i fazy scalania<\/h2>\n\n<p>Bior\u0119 pod uwag\u0119 <strong>Zmie\u0144 bufor<\/strong> podczas intensywnych aktualizacji indeks\u00f3w drugorz\u0119dnych. Zmniejsza on liczb\u0119 operacji losowego wej\u015bcia\/wyj\u015bcia w czasie wykonywania, jednak przenosi cz\u0119\u015b\u0107 pracy na p\u00f3\u017aniejsze fazy scalania. Scalanie to mo\u017ce generowa\u0107 dodatkowe obci\u0105\u017cenie zwi\u0105zane z operacjami flush, je\u015bli zbiega si\u0119 ono w niekorzystnym momencie z szczytami obci\u0105\u017cenia produkcyjnego. W zwi\u0105zku z tym monitoruj\u0119 rozmiar i aktywno\u015b\u0107 bufora zmian, w razie potrzeby ograniczam jego rozmiar i rozk\u0142adam zmiany zbiorcze w taki spos\u00f3b, aby fazy scalania nie kolidowa\u0142y z godzinami szczytu. Dzi\u0119ki temu cz\u0119stotliwo\u015b\u0107 operacji flush jest bardziej przewidywalna i r\u00f3wnomierna.<\/p>\n\n<h2>Metody czyszczenia pami\u0119ci i wp\u0142yw systemu plik\u00f3w<\/h2>\n\n<p>\u015awiadomie podejmuj\u0119 decyzj\u0119 w sprawie <strong>Metoda Flush<\/strong> oraz opcje systemu plik\u00f3w. Opcja O_DIRECT pozwala unikn\u0105\u0107 podw\u00f3jnego buforowania, co cz\u0119sto zmniejsza op\u00f3\u017anienia zapisu, podczas gdy \u015bcie\u017cki AIO i Fsync maj\u0105 swoje w\u0142asne cechy charakterystyczne. Mierz\u0119, jak te metody wp\u0142ywaj\u0105 na rozk\u0142ad op\u00f3\u017anie\u0144 oraz stabilno\u015b\u0107 post\u0119pu tworzenia punkt\u00f3w kontrolnych, a w przypadku szczeg\u00f3\u0142owych pyta\u0144 odsy\u0142am do wskaz\u00f3wek dotycz\u0105cych <a href=\"https:\/\/webhosting.de\/pl\/mariadb-metody-flush-innodb-fsync-przewodnik-po-wydajnosci-bufor\/\">Metody flush<\/a>. Dodatkowo sprawdzam opcje montowania system\u00f3w plik\u00f3w oraz procedury konserwacyjne (np. sp\u00f3jne strategie TRIM\/Discard w przypadku dysk\u00f3w SSD), aby infrastruktura nie powodowa\u0142a niezauwa\u017calnych waha\u0144.<\/p>\n\n<h2>Diagnoza: prawid\u0142owe odczytywanie komunikat\u00f3w o stanie<\/h2>\n\n<p>Wyprowadzam si\u0119 <em>POKA\u017b STATUS SILNIKA INNODB<\/em> w celu oceny wieku punktu kontrolnego i post\u0119pu operacji flush. Z <em>Numer sekwencji dziennika<\/em>, <em>Dziennik wyczyszczono do<\/em> oraz <em>Ostatni punkt kontrolny o godz.<\/em> Sprawdzam, jak du\u017ca jest r\u00f3\u017cnica mi\u0119dzy wygenerowanymi a zapisanymi zmianami. Je\u015bli r\u00f3\u017cnica ta stale ro\u015bnie szybciej, ni\u017c pozwala na to rozmiar dziennika redo, oznacza to, \u017ce moje operacje flush w tle s\u0105 zbyt powolne lub op\u00f3\u017anienie wej\u015bcia\/wyj\u015bcia jest zbyt du\u017ce. Por\u00f3wnuj\u0119 te warto\u015bci z metrykami InnoDB dotycz\u0105cymi brudnych stron, cz\u0119stotliwo\u015bci opr\u00f3\u017cniania (Flush-Rate) oraz aktywno\u015bci modu\u0142u czyszczenia stron (Page Cleaner), aby celowo dostosowywa\u0107 odpowiednie parametry, zamiast leczy\u0107 objawy.<\/p>\n\n<h2>Scenariusze operacyjne: operacje masowe, DDL i okna serwisowe<\/h2>\n\n<p>Planuj\u0119 <strong>\u0141adunki masowe<\/strong> oraz obszerne <strong>DDL<\/strong>-operacje w taki spos\u00f3b, aby nie zak\u0142\u00f3ci\u0107 dzia\u0142ania funkcji Adaptive Flushing. W przypadku planowanych okien konserwacyjnych tymczasowo zwi\u0119kszam <strong>innodb_io_capacity_max<\/strong>, aby w kontrolowany spos\u00f3b zrealizowa\u0107 oczekuj\u0105ce operacje zapisu, a nast\u0119pnie ponownie obni\u017cam go do normalnego poziomu. W przypadku du\u017cych import\u00f3w dostosowuj\u0119 cz\u0119stotliwo\u015b\u0107 commit\u00f3w, tak aby tempo wzrostu redo logu i post\u0119p tworzenia punkt\u00f3w kontrolnych by\u0142y zsynchronizowane. W mi\u0119dzyczasie stale monitoruj\u0119 poziom zape\u0142nienia dziennika Redo, wska\u017anik brudnych stron oraz percentyle op\u00f3\u017anie\u0144, aby w razie odchyle\u0144 m\u00f3c natychmiast podj\u0105\u0107 odpowiednie dzia\u0142ania koryguj\u0105ce.<\/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-optimizierung-4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cz\u0119ste b\u0142\u0119dne przekonania i antywzorce<\/h2>\n\n<p>Nie dam si\u0119 z\u0142apa\u0107 w pu\u0142apk\u0119, <strong>innodb_io_capacity_max<\/strong> wykorzystywa\u0107 to jako stan sta\u0142y. Zbyt wysoka warto\u015b\u0107 Max mo\u017ce przeci\u0105\u017cy\u0107 kolejki pami\u0119ci i spowolni\u0107 operacje odczytu w czasie rzeczywistym. Nie \u201eukrywam\u201c te\u017c s\u0142abej pami\u0119ci za ogromnym dziennikiem Redo \u2013 wi\u0119ksze dzienniki wyg\u0142adzaj\u0105 obci\u0105\u017cenie, ale nie tworz\u0105 rezerw operacji we\/wy. Nie akceptuj\u0119 te\u017c szczyt\u00f3w op\u00f3\u017anie\u0144 jako nieuniknionych: cz\u0119sto s\u0105 one wynikiem zbyt p\u00f3\u017anego preflushingu lub silnie wahaj\u0105cego si\u0119 obci\u0105\u017cenia w tle, kt\u00f3re mog\u0119 z\u0142agodzi\u0107 poprzez ni\u017csze progi LWM i realistyczne warto\u015bci pojemno\u015bci. Wreszcie unikam jednoczesnej zmiany wielu parametr\u00f3w; w przeciwnym razie trac\u0119 zwi\u0105zek przyczynowo-skutkowy i nie jestem w stanie odtworzy\u0107 uzyskanych ulepsze\u0144.<\/p>\n\n<h2>Kr\u00f3tkie podsumowanie<\/h2>\n\n<p>U\u017cywam <strong>Adaptacyjne<\/strong> Flushing, aby r\u00f3wnomiernie roz\u0142o\u017cy\u0107 operacje zapisu w czasie i tym samym unikn\u0105\u0107 skok\u00f3w op\u00f3\u017anie\u0144. Najwi\u0119kszy wp\u0142yw ma precyzyjne ustawienie parametru innodb_io_capacity oraz rozs\u0105dny stosunek do warto\u015bci innodb_io_capacity_max. Wcze\u015bnie uruchamiane progi dla poziomu zape\u0142nienia dziennika redo oraz wska\u017anika brudnych stron pomagaj\u0105 mi utrzyma\u0107 kolejki na niskim poziomie. Dzi\u0119ki odpowiednim dziennikom redo, rozs\u0105dnej r\u00f3wnoleg\u0142o\u015bci w\u0105tk\u00f3w czyszcz\u0105cych strony oraz czujnemu monitorowaniu udaje mi si\u0119 zapewni\u0107 bardziej niezawodne procedury zapisu. Zgodnie z dokumentacj\u0105 MariaDB dotycz\u0105c\u0105 zmiennych systemowych i opr\u00f3\u017cniania stron (page flushing) te parametry dzia\u0142aj\u0105 wsp\u00f3lnie \u2013 dostosowuj\u0119 je stopniowo i obserwuj\u0119 ich wp\u0142yw, a\u017c system zacznie dzia\u0142a\u0107 stabilnie i zgodnie z planem.<\/p>","protected":false},"excerpt":{"rendered":"<p>Optymalizacja funkcji Adaptive Flushing w MariaDB poprzez dostosowanie InnoDB, wydajno\u015b\u0107 operacji wej\u015bcia\/wyj\u015bcia oraz praktyczne wskaz\u00f3wki zapewniaj\u0105ce stabiln\u0105 wydajno\u015b\u0107.<\/p>","protected":false},"author":1,"featured_media":21582,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21589","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":"131","_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":"Adaptive Flushing","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":"21582","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/21589","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=21589"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/21589\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media\/21582"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media?parent=21589"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/categories?post=21589"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/tags?post=21589"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}