{"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-sideoprydning-trade-database","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/mariadb-page-cleaner-threads-datenbank\/","title":{"rendered":"S\u00e5dan forst\u00e5r du MariaDB Page Cleaner-tr\u00e5de: S\u00e5dan p\u00e5virker de ydeevnen"},"content":{"rendered":"<p><strong>Side-renser<\/strong> Tr\u00e5de i MariaDB styrer, hvordan InnoDB skriver \u00e6ndrede sider fra bufferpoolen til lagringsmediet og dermed udj\u00e6vner svartiderne under skrivebelastning. Hvis man forst\u00e5r den nuv\u00e6rende arkitektur med en enkelt cleaner-tr\u00e5d, undg\u00e5r man flaskehalse i skrivebanen og opretholder <strong>database<\/strong> J\u00e6vn ydeevne.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>Arkitektur<\/strong>: En cleaner-tr\u00e5d t\u00f8mmer dirty pages uafh\u00e6ngigt af bufferpool-instanser.<\/li>\n  <li><strong>Versioner<\/strong>: Variablen <code>innodb_page_cleaners<\/code> er blevet fjernet fra og med MariaDB 10.6.<\/li>\n  <li><strong>LRU-fokus<\/strong>: Valget af flush baseres p\u00e5 LRU-slutningen og checkpoint-fremskridtet.<\/li>\n  <li><strong>Myte<\/strong>: Flere tr\u00e5de betyder ikke n\u00f8dvendigvis bedre ydeevne.<\/li>\n  <li><strong>\u00d8velse<\/strong>: St\u00f8rrelsen p\u00e5 bufferpuljen, I\/O-kapaciteten og checkpointing har st\u00f8rst indflydelse p\u00e5 resultatet.<\/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>Hvad Page Cleaner pr\u00e6cist g\u00f8r<\/h2>\n\n<p>I tr\u00e5den om Page Cleaner st\u00e5r der <strong>Beskidt<\/strong> Pages fra InnoDB-bufferpoolen, f\u00f8r brugeroperationer rammer lagringsmediet direkte. Dermed adskiller den skriveoperationer fra foresp\u00f8rgsler og reducerer m\u00e6rkbart variationen i svartiderne, is\u00e6r under spidsbelastninger. Jeg ser Cleaner som en taktgiver: Den opdeler skrivningerne i passende bidder i stedet for at behandle store b\u00f8lger ukontrolleret. Tr\u00e5den henter sider, der ender i bunden af LRU-listen, s\u00e5 cachen hurtigt bliver ledig igen til data med h\u00f8j adgangshastighed. Samtidig fremskynder den checkpointet, s\u00e5 der ikke h\u00e6nger for mange ubeskrevne \u00e6ndringer tilbage i hukommelsen. Den, der forst\u00e5r denne proces, kan hurtigere se, om <strong>I\/O<\/strong> hvad der er flaskehalsen, eller om flaskehalsen snarere skyldes en for lille cache og for mange \u00bbdirty pages\u00ab.<\/p>\n\n<h2>Versionsstatus: Fra mange tr\u00e5de til \u00e9n<\/h2>\n\n<p>Tidligere var det muligt at konfigurere flere cleanere, men MariaDB 10.5.1 indledte oml\u00e6gningen, og MariaDB 10.6 fjernede <strong>innodb_page_cleaners<\/strong> endelig. Siden da har en enkelt <code>buf_flush_page_cleaner<\/code>-tr\u00e5d udf\u00f8rer arbejdet for alle bufferpool-instanser. Dette reducerer koordinationsomkostningerne, forenkler optimeringen og afspejler erkendelsen af, at en god algoritme er vigtigere end et stort antal tr\u00e5de. Hvis man f\u00f8lger vejledninger fra MySQL- eller \u00e6ldre artikler, st\u00f8der man hurtigt p\u00e5 parametre, der i dag er uden effekt. Jeg tjekker f\u00f8rst den n\u00f8jagtige MariaDB-version, f\u00f8r jeg justerer de formodede indstillinger. P\u00e5 den m\u00e5de undg\u00e5r jeg at spilde tid og kan koncentrere mig om de indstillinger, der har <strong>Skrivesti<\/strong> virkelig p\u00e5virke.<\/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>Bufferpool, beskidte sider og LRU<\/h2>\n\n<p>Bufferpoolen opbevarer aktive data i RAM og sparer dyre <strong>Disk<\/strong>-adgange. S\u00e5 snart der foretages skrivetransaktioner, opst\u00e5r der \u00bbdirty pages\u00ab, som i f\u00f8rste omgang kun findes i hukommelsen. Cleaneren skriver dem v\u00e6k i tide, s\u00e5 LRU'en til sidst frig\u00f8res, og sider, der l\u00e6ses ofte, forbliver \u00f8verst i cachen. Jeg holder \u00f8je med, hvor mange bufferpool-instanser der er aktive, og hvordan adgangen fordeler sig, for parallelitet kan aflaste k\u00f8erne. Hvis man \u00f8nsker at g\u00e5 mere i dybden, finder man praktiske tips til <a href=\"https:\/\/webhosting.de\/da\/mariadb-bufferpool-instanser-flerkernede-systemer-ydeevneoptimering-database\/\">Bufferpool-instanser<\/a>, f.eks. til multicore-v\u00e6rter. I sidste ende viser andelen af \u00bbdirty pages\u00ab, om flush-frekvensen holder trit med skrivehastigheden, og om cachen udnytter sin <strong>Hits<\/strong> forsyninger.<\/p>\n\n<h2>Fremskridt i Checkpoint og ventetid<\/h2>\n\n<p>Checkpointet s\u00e6tter en mark\u00f8r, op til hvilken \u00e6ndringer er sikkert gemt p\u00e5 datamediet, og Page Cleaner flytter denne mark\u00f8r fremad. Hvis checkpointet halter bagefter, stiger logudnyttelsesgraden og skriveforst\u00e6rkningen, hvilket afspejles i commit-varigheden og spids-n ved foresp\u00f8rgsler. Jeg kontrollerer regelm\u00e6ssigt, hvor meget checkpoint-afstanden svinger, og om Cleaner udl\u00f8ser for store udsving. Lykkes udj\u00e6vningen ikke, er der risiko for spidsbelastninger, hvor brugertr\u00e5de blokeres. For at f\u00e5 en grundl\u00e6ggende forst\u00e5else er det nyttigt at se p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/database-checkpointing-skriveforstaerkning-hosting-guide-skalering\/\">Checkpointing og skriveforst\u00e6rkning<\/a> i forbindelse med hosting. N\u00e5r man l\u00e6ser disse n\u00f8gletal, kan man tidligt se, om <strong>Skylle<\/strong>-om arbejdet bliver udf\u00f8rt i tide, eller om systemet m\u00e5 indhente det fors\u00f8mte i de senere faser.<\/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>Typiske misforst\u00e5elser i forbindelse med tuning<\/h2>\n\n<p>Mange forventer, at flere baggrundstr\u00e5de automatisk giver en h\u00f8jere gennemstr\u00f8mning, men det er ikke tilf\u00e6ldet her. Det afg\u00f8rende er stadig kvaliteten af flush-algoritmen og den rette m\u00e6ngde af <strong>I\/O<\/strong>-Arbejde pr. interval. En for aggressiv cleaner skaber korte belastningsspidser, der \u00f8ger responstiderne. En for tam cleaner akkumulerer for mange \u00bbdirty pages\u00ab, hvilket senere medf\u00f8rer st\u00f8rre flush-b\u00f8lger. Begge dele giver en fornemmelse af en harmonikaeffekt i latenstiderne. Jeg sigter derfor mod et j\u00e6vnt m\u00f8nster, der passer til hukommelsessubsystemet og belaster brugertr\u00e5dene s\u00e5 lidt som muligt <strong>blokeret<\/strong>.<\/p>\n\n<h2>M\u00e5linger og overv\u00e5gning: Hvad jeg tjekker<\/h2>\n\n<p>N\u00e5r jeg skal tr\u00e6ffe beslutninger, stoler jeg p\u00e5 tal, ikke p\u00e5 mavefornemmelse. Jeg overv\u00e5ger andelen af dirty pages, checkpoint-fremskridt, skrive- og Fsync-hastigheder samt ventetider p\u00e5 redo-log og datafiler. Hvis commit-tiderne svinger under belastning, kigger jeg p\u00e5 flush-backlogs og st\u00f8rrelsen p\u00e5 redo-log-filerne. Ogs\u00e5 andelen af sider i bunden af LRU-listen siger noget om eviktionspresset og behovet for flush-arbejde. Udslag i IOPS viser, at Cleaner skriver for store pakker, eller at lagergr\u00e6nsen er n\u00e5et. Disse m\u00e5lepunkter afsl\u00f8rer, om flashen snarere ligger i cache-st\u00f8rrelsen, <strong>Hukommelse<\/strong>- vedr\u00f8rende gennemstr\u00f8mning eller flush-strategi.<\/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>Konfiguration: V\u00e6lg de rigtige st\u00f8rrelser og I\/O-kapacitet<\/h2>\n\n<p>De vigtigste indstillingsparametre er fortsat bufferpoolens st\u00f8rrelse, I\/O-kapaciteten og log-layoutet. En st\u00f8rre bufferpool reducerer l\u00e6sebelastningen, men m\u00e5 ikke lade andelen af beskidte sider vokse ukontrolleret. Parametrene for I\/O-kapacitet styrer, hvor meget cleaner-processen fors\u00f8ger at skrive pr. tidsenhed. For sm\u00e5 v\u00e6rdier f\u00f8rer til flaskehalse, mens for store v\u00e6rdier skaber uregelm\u00e6ssigheder i latenstidsprofilen. Jeg tilpasser disse st\u00f8rrelser til det faktiske lagringssystem i stedet for at stole p\u00e5 abstrakte standardv\u00e6rdier. Den f\u00f8lgende tabel opsummerer relevante indstillinger, der p\u00e5virker <strong>Skylle<\/strong>-processen pr\u00e6ge.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Indstilling\/aspekt<\/th>\n      <th>Indvirkning p\u00e5 Page Cleaner<\/th>\n      <th>Bem\u00e6rkning vedr\u00f8rende MariaDB<\/th>\n      <th>Praktisk vejledning<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><code>innodb_buffer_pool_size<\/code><\/td>\n      <td>P\u00e5virker m\u00e6ngden af \u00bbdirty pages\u00ab og eviction-presset<\/td>\n      <td>En st\u00f8rre pulje kr\u00e6ver en j\u00e6vn flush-frekvens<\/td>\n      <td>Brug RAM, men s\u00f8rg for at have en reserve til operativsystemet og <strong>Foresp\u00f8rgsel<\/strong>-Lad cachen v\u00e6re<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_io_kapacitet<\/code> \/ <code>innodb_io_capacity_max<\/code><\/td>\n      <td>Begr\u00e6nset omfang af planlagte skylningsarbejder<\/td>\n      <td>Tilpas til reelle IOPS fra SSD\/NVMe<\/td>\n      <td>Start med et konservativt bel\u00f8b og forh\u00f8j det derefter gradvist<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_flush_log_at_trx_commit<\/code><\/td>\n      <td>Styrer hyppigheden af commit-Fsync<\/td>\n      <td>Valget p\u00e5virker latenstiden og holdbarheden<\/td>\n      <td>\u201e1\u201c for l\u00e6ngst holdbarhed; \u201e2\/0\u201c for kortere holdbarhed <strong>Forsinkelse<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Redo-log-st\u00f8rrelse<\/td>\n      <td>Virker p\u00e5 Checkpoint-afstand og Flush-b\u00f8lger<\/td>\n      <td>For lille medf\u00f8rer hyppige kontrolpunkter<\/td>\n      <td>Dimensioner st\u00f8rre for at udj\u00e6vne skrive-spidsbelastninger<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_page_cleaners<\/code> (gammel)<\/td>\n      <td>I dag uden indflydelse<\/td>\n      <td>Fjernet fra MariaDB 10.6 og frem<\/td>\n      <td>R\u00f8r det ikke mere, fokuser p\u00e5 de aktive <strong>Parametre<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Praktisk vejledning: Testning trin for trin<\/h2>\n\n<p>Jeg starter med en klar baseline under belastning, f\u00f8r jeg \u00e6ndrer indstillingerne. Derefter justerer jeg <code>innodb_io_kapacitet<\/code> i sm\u00e5 trin og observerer, om der opst\u00e5r f\u00e6rre spidsbelastninger. Hvis der viser sig l\u00e6ngere flush-b\u00f8lger, \u00f8ger jeg redo-log-st\u00f8rrelsen, s\u00e5 checkpointet f\u00e5r mere bufferplads. Derefter tjekker jeg, om bufferpoolen har plads nok, s\u00e5 \u00bbvarme\u00ab data ikke fortr\u00e6nges for hurtigt. Hver \u00e6ndring f\u00e5r tilstr\u00e6kkelig tid, s\u00e5 virkninger og bivirkninger kan vise sig tydeligt. F\u00f8rst n\u00e5r n\u00f8gletallene og brugeroplevelsen sammen bliver bedre, s\u00e6tter jeg flueben ved <strong>Trin<\/strong> fra.<\/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>Indflydelse fra Doublewrite-bufferen<\/h2>\n\n<p>Doublewrite-bufferen beskytter sider mod delvise skrivninger og beskadigede blokke, men p\u00e5virker samtidig skrivehastigheden og flush-m\u00f8nstret. Is\u00e6r ved en h\u00f8j andel af opdateringer kan den p\u00e5virke den oplevede gennemstr\u00f8mning for Cleaner. Moderne lagringssystemer med vedvarende skrivef\u00f8lge afb\u00f8der en del af dette, men effekten er stadig m\u00e5lbar. Jeg unders\u00f8ger derfor arbejdsbelastning, forventninger til dataintegritet og acceptabel latenstid, f\u00f8r jeg justerer denne indstilling. Hvis du har brug for yderligere detaljer, kan du finde baggrundsinformation i artiklen om <a href=\"https:\/\/webhosting.de\/da\/innodb-dobbeltskrivningsbuffer-sikkerhed-ydeevne-optimering-fokus\/\">Doublewrite-buffer<\/a>. P\u00e5 den m\u00e5de kan man afg\u00f8re, om levetiden og <strong>Beskyttelse<\/strong> F\u00e5r forrang frem for den mindst mulige latenstid.<\/p>\n\n<h2>Almindelige symptomer og foranstaltninger<\/h2>\n\n<p>Hvis commit-tiderne stiger, selvom CPU\u2019en er ledig, tyder det p\u00e5 en flush-k\u00f8 eller svag lagring. Store udsving i IOPS tyder p\u00e5 for store flush-pakker; i s\u00e5 fald justerer jeg I\/O-kapaciteten nedad og udvider redo-loggen. Hvis andelen af beskidte sider forbliver konstant h\u00f8j, arbejder Cleaner for defensivt, eller bufferpoolen er for lille. Hvis ofte anvendte sider hurtigt glider ned mod enden af LRU-listen, mangler der cacheplads, eller skrivebelastningen presser poolen for h\u00e5rdt. I hostingmilj\u00f8er er det ofte den delte storage, der bremser; her hj\u00e6lper kun belastningsm\u00e5ling i l\u00f8bet af dagen og eventuelt et skift til hurtigere medier. Jeg dokumenterer hver \u00e6ndring, s\u00e5 \u00e5rsagen og <strong>Effekt<\/strong> forbliver entydigt senere.<\/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>Hvordan Cleaner prioriterer mellem Flush-listen og LRU<\/h2>\n<p>InnoDB skelner ved skrivning mellem to hovedkilder: LRU-listen (sider, der skal give plads til nye adgangsforesp\u00f8rgsler) og flush-listen (alle \u00bbdirty pages\u00ab, sorteret efter det \u00e6ldste log-sekvensnummer). Page Cleaner afbalancerer disse to m\u00e5l: Den rydder op i enden af LRU-listen for at undg\u00e5 eviktioner og tr\u00e6kker samtidig fra flush-listen for konstant at skubbe checkpointet fremad. Hvis den ledige bufferplads kommer under pres, har LRU-flush prioritet; hvis checkpoint-afstanden derimod vokser, \u00f8ger Cleaner andelen fra flush-listen. Denne skiftende prioritering forklarer, hvorfor latenstidsprofiler \u00e6ndrer sig ved skiftende arbejdsbelastninger: Stiger l\u00e6sepresset, dominerer LRU-flushes; stiger skrivepresset, dominerer checkpoint-arbejdet. Jeg afl\u00e6ser m\u00f8nsteret i overv\u00e5gningen for at afg\u00f8re, om jeg snarere skal optimere I\/O-kapaciteten eller redo-log-reserven.<\/p>\n\n<h2>Adaptiv skylning: Korrekt fortolkning af t\u00e6rskelv\u00e6rdier<\/h2>\n<p>MariaDB anvender adaptiv flushing til dynamisk at tilpasse skrivehastigheden til redo-forbruget og andelen af dirty pages. I praksis holder jeg \u00f8je med tre st\u00f8rrelser: m\u00e5lv\u00e6rdien for dirty pages, low-water-m\u00e6rket og den aktuelle skrivehastighed. Ligger andelen af dirty pages over m\u00e5lv\u00e6rdien, strammer Cleaner t\u00f8jlerne; falder den under, bliver den mere tilbageholdende. En for lav low-water-mark f\u00f8rer til hyppige flush-starter og kan skabe korte, men m\u00e6rkbare latenstidsstigninger. En for h\u00f8j t\u00e6rskelv\u00e6rdi lader for meget \u00bbsnavs\u00ab blive st\u00e5ende i cachen, hvilket senere skaber st\u00f8rre b\u00f8lger. Jeg justerer t\u00e6rskelv\u00e6rdierne, s\u00e5 de passer til cachesystemets karakter: hurtige NVMe-SSD\u2019er kan klare kontinuerlige, moderat h\u00f8jere flush-hastigheder; langsommere systemer drager fordel af j\u00e6vnere, mindre batches.<\/p>\n\n<h2>Brug af lagringsspecifikke indstillinger p\u00e5 en fornuftig m\u00e5de<\/h2>\n<p>Page Cleaner fungerer ikke i et vakuum \u2013 valget af flush-metode og filsystemets adf\u00e6rd har stor indflydelse p\u00e5 resultatet. Med <code>innodb_flush_method<\/code> Her styrer jeg, om InnoDB skriver sider direkte (O_DIRECT) eller via operativsystemets cache. Direkte skrivning undg\u00e5r dobbeltcaching og stabiliserer ventetiderne p\u00e5 Linux med XFS\/EXT4. Filsystemer som ZFS h\u00e5ndterer imidlertid O_DIRECT anderledes; her kontrollerer jeg, om der skal anvendes en synkroniseret metode (<em>fsync<\/em>\/<em>O_DSYNC<\/em>) giver den mest konsistente profil. Derudover er det v\u00e6rd at se n\u00e6rmere p\u00e5 \u00bbneighborhood flushing\u00ab (<em>flush naboer<\/em>): P\u00e5 HDD-arrays kan det v\u00e6re en god id\u00e9 at skrive til tilst\u00f8dende blokke, mens jeg p\u00e5 SSD\/NVMe begr\u00e6nser det for at undg\u00e5 un\u00f8dvendig skriveforst\u00e6rkning. Det afg\u00f8rende er, at konfigurationen passer til det fysiske medie \u2013 selv den bedste cleaner-algoritme nytter ikke meget, hvis det underliggende lagringsmedie bremses.<\/p>\n\n<h2>Overv\u00e5gning i praksis: Foresp\u00f8rgsler, der hj\u00e6lper mig<\/h2>\n<p>For at f\u00e5 et hurtigt overblik bruger jeg tre perspektiver: globale statusv\u00e6rdier, InnoDB-metrikker og den periodiske dump.<\/p>\n<ul>\n  <li>Hurtige n\u00f8gletal: <code>SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty%';<\/code>, <code>... LIKE 'Innodb_os_log_written';<\/code>, <code>... LIKE 'Innodb_log_waits';<\/code>. Stige <em>log-ventetider<\/em>, er Redo-loggen for lille, eller er flush-funktionen for langsom.<\/li>\n  <li>Detaljeringsgrad: <code>SHOW ENGINE INNODB STATUS\\G<\/code> leverer checkpoint-positioner (LSN), flush-list-l\u00e6ngder og oplysninger om flaskehalse. Jeg sammenligner \u201eLog sequence number\u201c og \u201eLast checkpoint at\u201c for at estimere checkpoint-afstanden.<\/li>\n  <li>Mere pr\u00e6cis telemetri: <code>SELECT NAME, COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME LIKE 'buffer_%dirty%';<\/code> eller <code>... LIKE 'log_%';<\/code> viser tendenser, som let overses i korte tests.<\/li>\n<\/ul>\n<p>Det vigtige er sammenh\u00e6ngen: Hvis commit-forsinkelserne stiger samtidig med en \u00f8get Fsync-hastighed, er Cleaner sandsynligvis indstillet for aggressivt. Hvis andelen af dirty pages og checkpoint-afstanden stiger samtidigt, mangler der flush-gennemstr\u00f8mning, eller ogs\u00e5 er redo-loggen for lille.<\/p>\n\n<h2>Arbejdsbelastningsprofiler: OLTP, rapportering, bulk<\/h2>\n<p>Afh\u00e6ngigt af arbejdsbelastningen l\u00e6gger jeg v\u00e6gt p\u00e5 forskellige aspekter. I OLTP-milj\u00f8er sigter jeg mod konstante, sm\u00e5 flush-batches og et sn\u00e6vert latenstidsinterval \u2013 her er moderat indstillede <code>innodb_io_kapacitet<\/code> og tilstr\u00e6kkelige redo-buffere er afg\u00f8rende. I forbindelse med rapporterings- eller ETL-vinduer accepterer jeg til tider h\u00f8jere flush-frekvenser, men s\u00f8rger for, at de ikke str\u00e6kker sig helt ind i brugertoppene. Ved massedataindl\u00e6sning foretr\u00e6kker jeg st\u00f8rre redo-logfiler og \u2013 hvis holdbarhedskrav tillader det \u2013 en midlertidigt lempet Fsync-disciplin (<code>innodb_flush_log_at_trx_commit=2<\/code>). Page Cleaner kan derefter l\u00f8bende \u201eindhente det fors\u00f8mte\u201c uden at bremse brugernes transaktioner. N\u00e5r det er f\u00e6rdigt, genindf\u00f8rer jeg de strengere v\u00e6rdier, s\u00e5 den daglige drift forbliver stabil.<\/p>\n\n<h2>Langdistancel\u00f8bere, udrensning og indirekte effekter<\/h2>\n<p>Selvom Purge-tr\u00e5den har andre form\u00e5l (oprydning af gamle versioner), p\u00e5virker dens hastighed det samlede billede. Hvis gamle versioner ligger l\u00e6nge, stiger pladsbehovet, og belastningen p\u00e5 hukommelsen og I\/O fordeles mindre gunstigt. Det kan indirekte belaste Page Cleaner, fordi flere sider er bundet i puljen, og LRU hurtigere kommer under pres. Derfor holder jeg \u00f8je med Purge-forsinkelserne og s\u00f8rger for, at ingen langvarige transaktioner \u201el\u00e5ser\u201c systemet fast. Stabil fremskridt i Purge, kontinuerlig Cleaner, afbalanceret skrivefrekvens \u2013 disse tre tandhjul skal gribe ind i hinanden.<\/p>\n\n<h2>Tjekliste til fejlfinding i skrivebanen<\/h2>\n<ul>\n  <li>Checkpoint-afstanden h\u00f8j og stigende? Udvid redo-loggen og <code>innodb_io_kapacitet<\/code> L\u00f8ft den, og kontroller derefter forl\u00f8bet igen.<\/li>\n  <li>IOPS-spidser og commit-spidser? <code>innodb_io_kapacitet<\/code> s\u00e6nke den lidt, udj\u00e6vne batchst\u00f8rrelsen, tage h\u00f8jde for dobbeltskrivningseffekten.<\/li>\n  <li>Er andelen af \u00bbDirty Pages\u00ab vedvarende h\u00f8j? Udvid bufferpuljen eller indstil adaptiv flushing til en strengere indstilling; kontroller arbejdsbelastningen p\u00e5 hotsets.<\/li>\n  <li>Er log-ventetider synlige? Enten er redo-reserven for lille, eller ogs\u00e5 halter flush-processen. For\u00f8g f\u00f8rst redo-reserven, og finjuster derefter cleaner-gennemstr\u00f8mningen.<\/li>\n  <li>Er fremskridtet med LSN ustabilt? Flush-pakkerne er inkonsekvente. \u00c6ndr v\u00e6rdierne gradvist, indtil der ses et j\u00e6vnt fremskridt.<\/li>\n  <li>Flaskehalse t\u00e6t p\u00e5 lagringssystemet? Kontroller flush-metoden, scheduleren og RAID-\/SAN-cache-indstillingerne; brug b\u00e6redygtige IOPS i stedet for spidsbelastnings-IOPS som m\u00e5lv\u00e6rdi.<\/li>\n<\/ul>\n\n<h2>Eksempel: Kalibrering i tre runder<\/h2>\n<p>I en skriveintensiv OLTP-instans starter jeg med en belastningsm\u00e5ling i produktionsvinduet. Runde 1: Jeg m\u00e5ler redo-log-fyldningsgraden og checkpoint-afstanden. Loggen er ofte fyldt til 70\u201380 %, mens afstanden svinger kraftigt \u2013 derfor fordobler jeg redo-st\u00f8rrelsen. Runde 2: Efter en ny test udj\u00e6vnes latenstiderne, men lejlighedsvis opst\u00e5r der Fsync-spidsbelastninger. Jeg s\u00e6nker <code>innodb_io_kapacitet<\/code> moderat, indtil IOPS-fordelingen bliver mere stabil. Runde 3: Andelen af \u00bbdirty pages\u00ab forbliver i den \u00f8verste ende. Jeg tildeler bufferpoolen mere RAM, hvilket aflaster LRU\u2019en og g\u00f8r cleaner-arbejdet mere forudsigeligt. Resultat: Commit-P95 falder m\u00e6rkbart, IOPS-kurven bliver mere j\u00e6vn, og checkpointet bev\u00e6ger sig konstant fremad \u2013 pr\u00e6cis det m\u00f8nster, jeg str\u00e6ber efter.<\/p>\n\n<h2>Kort opsummeret<\/h2>\n\n<p>En enkelt cleaner-tr\u00e5d styrer flushing af dirty pages, holder checkpointet i gang og beskytter foresp\u00f8rgsler mod kraftige skrivespidsbelastninger. Relevante indstillingsparametre er fortsat bufferpoolst\u00f8rrelse, I\/O-kapacitet, redo-log-layout og hukommelsessystemets egenskaber. For\u00e6ldede indstillingsparametre som <strong>innodb_page_cleaners<\/strong> Det tager jeg ikke l\u00e6ngere hensyn til, men koncentrerer mig i stedet om n\u00f8gletal, der har direkte indflydelse. Hvis man ser p\u00e5 n\u00f8gletal som andel af beskidte sider, checkpoint-afstand og commit-varighed, finder man flaskehalse hurtigere. Gradvise \u00e6ndringer med en klar baseline giver p\u00e5lidelige resultater uden at skjule bivirkninger. S\u00e5dan arbejder Page Cleaner stille i baggrunden, og <strong>Svartid<\/strong> forbliver ensartet \u2013 ogs\u00e5 under belastning.<\/p>","protected":false},"excerpt":{"rendered":"<p>MariaDB Page Cleaner-tr\u00e5de forklaret: Page Cleaner i MariaDB InnoDB p\u00e5virker \u00bbdirty pages\u00ab og databasens ydeevne.<\/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":"101","_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\/da\/wp-json\/wp\/v2\/posts\/21467","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=21467"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21467\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21460"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21467"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21467"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21467"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}