{"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-sidrensare-tradar-databas","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/mariadb-page-cleaner-threads-datenbank\/","title":{"rendered":"Att f\u00f6rst\u00e5 MariaDB Page Cleaner-tr\u00e5dar: S\u00e5 p\u00e5verkar de prestandan"},"content":{"rendered":"<p><strong>Sidrensare<\/strong> Tr\u00e5dar i MariaDB styr hur InnoDB skriver \u00e4ndrade sidor fr\u00e5n buffertpoolen till lagringsmediet och d\u00e4rmed j\u00e4mnar ut svarstiderna vid skrivbelastning. Den som f\u00f6rst\u00e5r den nuvarande arkitekturen med en enda cleaner-tr\u00e5d kan undvika flaskhalsar i skrivv\u00e4gen och uppr\u00e4tth\u00e5lla <strong>databas<\/strong> J\u00e4mn prestanda.<\/p>\n\n<h2>Centrala punkter<\/h2>\n\n<ul>\n  <li><strong>Arkitektur<\/strong>: En reng\u00f6ringstr\u00e5d t\u00f6mmer smutsiga sidor oberoende av bufferpoolinstanser.<\/li>\n  <li><strong>Versioner<\/strong>: Variabeln <code>innodb_page_cleaners<\/code> har tagits bort fr\u00e5n och med MariaDB 10.6.<\/li>\n  <li><strong>LRU-fokus<\/strong>: Valet av flush baseras p\u00e5 LRU-slutet och framstegen i kontrollpunkten.<\/li>\n  <li><strong>Myt<\/strong>: Fler tr\u00e5dar inneb\u00e4r inte automatiskt b\u00e4ttre prestanda.<\/li>\n  <li><strong>\u00d6vning<\/strong>: Buffertpoolens storlek, I\/O-kapaciteten och kontrollpunktshanteringen har st\u00f6rst inverkan 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>Vad Page Cleaner egentligen g\u00f6r<\/h2>\n\n<p>I tr\u00e5den om Page Cleaner st\u00e5r det <strong>Smutsig<\/strong> Sidor fr\u00e5n InnoDB-buffertpoolen innan anv\u00e4ndaroperationer hamnar direkt p\u00e5 lagringsmediet. P\u00e5 s\u00e5 s\u00e4tt separerar den skrivoperationer fr\u00e5n s\u00f6kningar och minskar m\u00e4rkbart variansen i svarstiderna, framf\u00f6r allt under belastningstoppar. Jag ser Cleaner som en taktgivare: den delar upp skrivningarna i l\u00e4mpliga portioner ist\u00e4l\u00e4llet f\u00f6r att okontrollerat bearbeta stora v\u00e5gor. Tr\u00e5den h\u00e4mtar sidor som hamnar l\u00e4ngst ner i LRU-listan, s\u00e5 att cachen snabbt blir ledig igen f\u00f6r data som anv\u00e4nds flitigt. Samtidigt driver den p\u00e5 checkpoint-processen, s\u00e5 att inte f\u00f6r m\u00e5nga oskrivna \u00e4ndringar fastnar i minnet. Den som f\u00f6rst\u00e5r denna process inser snabbare om <strong>I\/O<\/strong> om det \u00e4r ett flaskhalsproblem eller om flaskhalsen snarare beror p\u00e5 att cachen \u00e4r f\u00f6r liten och att det finns f\u00f6r m\u00e5nga smutsiga sidor.<\/p>\n\n<h2>Versionsstatus: Fr\u00e5n m\u00e5nga tr\u00e5dar till en<\/h2>\n\n<p>Tidigare gick det att konfigurera flera reng\u00f6ringsverktyg, men MariaDB 10.5.1 inledde omstruktureringen och MariaDB 10.6 tog bort <strong>innodb_page_cleaners<\/strong> definitivt. Sedan dess sk\u00f6ter en enda person <code>buf_flush_page_cleaner<\/code>-tr\u00e5d hanterar arbetet f\u00f6r alla bufferpoolinstanser. Detta minskar samordningskostnaderna, f\u00f6renklar optimeringen och \u00e5terspeglar insikten att en bra algoritm \u00e4r viktigare \u00e4n ett stort antal tr\u00e5dar. Den som f\u00f6ljer instruktioner fr\u00e5n MySQL- eller \u00e4ldre artiklar st\u00f6ter snabbt p\u00e5 parametrar som idag \u00e4r verkningsl\u00f6sa. Jag kontrollerar f\u00f6rst den exakta MariaDB-versionen innan jag justerar de f\u00f6rmodade inst\u00e4llningarna. P\u00e5 s\u00e5 s\u00e4tt undviker jag tidsf\u00f6rlust och koncentrerar mig p\u00e5 de inst\u00e4llningsvariabler som p\u00e5verkar <strong>Skrivv\u00e4g<\/strong> verkligen p\u00e5verka.<\/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>Buffertpool, smutsiga sidor och LRU<\/h2>\n\n<p>Bufferpoolen lagrar aktiva data i RAM-minnet och sparar kostsamma <strong>Disk<\/strong>-\u00e5tkomst. S\u00e5 snart transaktioner skriver uppst\u00e5r \u201ddirty pages\u201d, som inledningsvis endast finns i minnet. Cleanern skriver bort dem i god tid s\u00e5 att LRU-listan till slut frig\u00f6rs och sidor som l\u00e4ses ofta f\u00f6rblir h\u00f6gst upp i cachen. Jag h\u00e5ller koll p\u00e5 hur m\u00e5nga bufferpool-instanser som \u00e4r aktiva och hur \u00e5tkomsten f\u00f6rdelas, eftersom parallellitet kan minska k\u00f6erna. Den som vill f\u00f6rdjupa sig ytterligare hittar praktiska tips om <a href=\"https:\/\/webhosting.de\/sv\/mariadb-buffertpool-instanser-flerkaerniga-system-prestandajustering-databas\/\">Bufferpoolinstanser<\/a>, till exempel f\u00f6r flerk\u00e4rniga v\u00e4rddatorer. I slut\u00e4ndan visar andelen \u201ddirty pages\u201d om t\u00f6mningsfrekvensen h\u00e5ller j\u00e4mna steg med skrivhastigheten och om cachen <strong>Tr\u00e4ffar<\/strong> f\u00f6rn\u00f6denheter.<\/p>\n\n<h2>Checkpoint-framsteg och latens<\/h2>\n\n<p>Kontrollpunkten s\u00e4tter en mark\u00f6r som anger gr\u00e4nsen fram till vilken \u00e4ndringarna \u00e4r s\u00e4kert lagrade p\u00e5 datamediet, och Page Cleaner flyttar denna mark\u00f6r fram\u00e5t. Om kontrollpunkten hamnar p\u00e5 efterk\u00e4lken \u00f6kar loggutnyttjandet och skrivf\u00f6rst\u00e4rkningen, vilket m\u00e4rks i commit-tiden och toppv\u00e4rdet f\u00f6r n vid s\u00f6kningar. Jag kontrollerar regelbundet hur mycket checkpoint-avst\u00e5ndet varierar och om Cleaner skapar f\u00f6r stora sv\u00e4ngningar. Om utj\u00e4mningen inte lyckas riskerar man att f\u00e5 perioder med h\u00f6g belastning d\u00e4r anv\u00e4ndartr\u00e5dar blockeras. F\u00f6r att f\u00e5 en grundl\u00e4ggande f\u00f6rst\u00e5else \u00e4r det bra att titta p\u00e5 <a href=\"https:\/\/webhosting.de\/sv\/databas-checkpointing-skrivfoerstaerkning-hosting-guide-skalning\/\">Checkpointing och skrivf\u00f6rst\u00e4rkning<\/a> i samband med webbhotell. Den som granskar dessa nyckeltal kan tidigt avg\u00f6ra om <strong>Spola<\/strong>-om arbetet utf\u00f6rs i god tid eller om systemet m\u00e5ste hinna ikapp i ett senare skede.<\/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>Vanliga missuppfattningar n\u00e4r det g\u00e4ller tuning<\/h2>\n\n<p>M\u00e5nga f\u00f6rv\u00e4ntar sig att fler bakgrundstr\u00e5dar automatiskt ska ge h\u00f6gre genomstr\u00f6mning, men s\u00e5 \u00e4r inte fallet h\u00e4r. Det avg\u00f6rande \u00e4r fortfarande kvaliteten p\u00e5 flush-algoritmen och r\u00e4tt dos av <strong>I\/O<\/strong>-Arbete per intervall. En alltf\u00f6r aggressiv reng\u00f6rare skapar korta belastningstoppar som driver upp svarstiderna. En alltf\u00f6r passiv reng\u00f6rare ackumulerar f\u00f6r m\u00e5nga smutsiga sidor, vilket senare leder till st\u00f6rre t\u00f6mningsv\u00e5gor. B\u00e5da dessa situationer ger upphov till en dragspelseffekt n\u00e4r det g\u00e4ller latenser. Jag str\u00e4var d\u00e4rf\u00f6r efter ett j\u00e4mnt m\u00f6nster som passar minnesundersystemet och belastar anv\u00e4ndartr\u00e5dar s\u00e5 lite som m\u00f6jligt <strong>blockerad<\/strong>.<\/p>\n\n<h2>M\u00e4tv\u00e4rden och \u00f6vervakning: Vad jag kontrollerar<\/h2>\n\n<p>N\u00e4r jag fattar beslut f\u00f6rlitar jag mig p\u00e5 siffror, inte p\u00e5 magk\u00e4nsla. Jag \u00f6vervakar andelen smutsiga sidor, checkpoint-framsteg, skriv- och Fsync-hastigheter samt v\u00e4ntetider f\u00f6r redo-loggar och datafiler. Om commit-tiderna varierar under belastning tittar jag p\u00e5 flush-backloggarna och storleken p\u00e5 redo-loggfilerna. \u00c4ven andelen sidor i slutet av LRU-listan s\u00e4ger n\u00e5got om eviktionstrycket och behovet av flush-bearbetning. Avvikelser i IOPS visar att Cleaner skriver f\u00f6r stora paket eller att lagringsgr\u00e4nsen har n\u00e5tts. Dessa m\u00e4tpunkter avsl\u00f6jar om flaskhalsen snarare beror p\u00e5 cache-storlek, <strong>Minne<\/strong>-Genomstr\u00f6mning 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\u00e4lj r\u00e4tt storlek och I\/O-kapacitet<\/h2>\n\n<p>De viktigaste inst\u00e4llningsparametrarna \u00e4r fortfarande buffertpoolens storlek, I\/O-kapaciteten och logglayouten. En st\u00f6rre buffertpool minskar l\u00e4sbelastningen, men f\u00e5r inte l\u00e5ta andelen smutsiga sidor v\u00e4xa okontrollerat. Parametrarna f\u00f6r I\/O-kapaciteten styr hur mycket Cleaner f\u00f6rs\u00f6ker skriva under en tidsenhet. F\u00f6r l\u00e5ga v\u00e4rden leder till flaskhalsar, medan f\u00f6r h\u00f6ga v\u00e4rden orsakar toppar i latensprofilen. Jag anpassar dessa v\u00e4rden efter det faktiska lagringssystemet ist\u00e4llet f\u00f6r att f\u00f6rlita mig p\u00e5 abstrakta standardv\u00e4rden. F\u00f6ljande tabell sammanfattar relevanta inst\u00e4llningar som p\u00e5verkar beteendet hos <strong>Spola<\/strong>-processen.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Inst\u00e4llning\/aspekt<\/th>\n      <th>Effekt p\u00e5 Page Cleaner<\/th>\n      <th>Anm\u00e4rkning f\u00f6r MariaDB<\/th>\n      <th>Praktisk v\u00e4gledning<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><code>innodb_buffer_pool_storlek<\/code><\/td>\n      <td>P\u00e5verkar m\u00e4ngden \u201ddirty pages\u201d och utdrivningstrycket<\/td>\n      <td>En st\u00f6rre pool kr\u00e4ver en j\u00e4mn flushing-frekvens<\/td>\n      <td>Anv\u00e4nda RAM, men l\u00e4mna utrymme f\u00f6r operativsystemet och <strong>Fr\u00e5ga<\/strong>-L\u00e5t cacheminnet fungera<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_io_capacity<\/code> \/ <code>innodb_io_capacity_max<\/code><\/td>\n      <td>Begr\u00e4nsad omfattning av planerade spolningsarbeten<\/td>\n      <td>Anpassa till faktiska IOPS fr\u00e5n SSD\/NVMe<\/td>\n      <td>B\u00f6rja med ett konservativt v\u00e4rde och h\u00f6j sedan stegvis<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_flush_log_at_trx_commit<\/code><\/td>\n      <td>Styr frekvensen f\u00f6r Commit-Fsync<\/td>\n      <td>Valet p\u00e5verkar latensen och h\u00e5llbarheten<\/td>\n      <td>\u201e1\u201c f\u00f6r l\u00e4ngsta h\u00e5llbarhet; \u201e2\/0\u201c f\u00f6r kortare <strong>F\u00f6rdr\u00f6jning<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Redo-loggens storlek<\/td>\n      <td>Verkar p\u00e5 Checkpoint-avst\u00e5nd och Flush-v\u00e5gor<\/td>\n      <td>Om den \u00e4r f\u00f6r liten kr\u00e4vs det ofta kontrollpunkter<\/td>\n      <td>V\u00e4lj st\u00f6rre dimensioner f\u00f6r att j\u00e4mna ut skrivtopparna<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_page_cleaners<\/code> (gammal)<\/td>\n      <td>Ingen inverkan idag<\/td>\n      <td>Borttaget fr\u00e5n och med MariaDB 10.6<\/td>\n      <td>R\u00f6r inte l\u00e4ngre, fokusera p\u00e5 aktiva <strong>Parametrar<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Praktisk handbok: Testa steg f\u00f6r steg<\/h2>\n\n<p>Jag b\u00f6rjar med en tydlig baslinje under belastning innan jag \u00e4ndrar inst\u00e4llningarna. D\u00e4refter justerar jag <code>innodb_io_capacity<\/code> i sm\u00e5 steg och observerar om latensspikar uppst\u00e5r mindre ofta. Om l\u00e4ngre flush-v\u00e5gor upptr\u00e4der \u00f6kar jag storleken p\u00e5 redo-loggen s\u00e5 att kontrollpunkten f\u00e5r mer buffertutrymme. D\u00e4refter kontrollerar jag om buffertpoolen har tillr\u00e4ckligt med utrymme s\u00e5 att popul\u00e4ra data inte tr\u00e4ngs undan f\u00f6r snabbt. Varje \u00e4ndring f\u00e5r tillr\u00e4ckligt med tid s\u00e5 att effekter och bieffekter tydligt kan visas. F\u00f6rst n\u00e4r nyckeltalen och anv\u00e4ndarupplevelsen tillsammans f\u00f6rb\u00e4ttras markerar jag av <strong>Steg<\/strong> fr\u00e5n.<\/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>Effekten av Doublewrite-bufferten<\/h2>\n\n<p>Doublewrite-bufferten skyddar sidor mot partiella skrivningar och korrupta block, men p\u00e5verkar samtidigt skrivhastigheten och flush-m\u00f6nstret. S\u00e4rskilt vid en h\u00f6g andel uppdateringar kan den p\u00e5verka den upplevda genomstr\u00f6mningen hos Cleaner. Moderna lagringssystem med best\u00e4ndig skrivordning mildrar effekten n\u00e5got, men den \u00e4r \u00e4nd\u00e5 m\u00e4tbar. Jag granskar d\u00e4rf\u00f6r arbetsbelastning, f\u00f6rv\u00e4ntningar p\u00e5 dataintegritet och acceptabel latens innan jag justerar denna inst\u00e4llning. Den som beh\u00f6ver mer information om detta kan l\u00e4sa mer i artikeln om <a href=\"https:\/\/webhosting.de\/sv\/innodb-dubbelskrivningsbuffert-saekerhet-prestandajustering-fokus\/\">Doublewrite-buffert<\/a>. P\u00e5 s\u00e5 s\u00e4tt kan man avg\u00f6ra om livsl\u00e4ngden och <strong>Skydd<\/strong> Prioriteras framf\u00f6r l\u00e4gsta m\u00f6jliga latens.<\/p>\n\n<h2>Vanliga symtom och \u00e5tg\u00e4rder<\/h2>\n\n<p>Om commit-tiderna skjuter i h\u00f6jden trots att CPU:n \u00e4r ledig tyder det p\u00e5 en flushing-k\u00f6 eller svag lagring. Stora sv\u00e4ngningar i IOPS tyder p\u00e5 f\u00f6r stora flushing-paket; d\u00e5 justerar jag ned I\/O-kapaciteten och ut\u00f6kar redo-loggen. Om andelen smutsiga sidor f\u00f6rblir konstant h\u00f6g arbetar reng\u00f6raren f\u00f6r defensivt eller s\u00e5 \u00e4r buffertpoolen f\u00f6r liten. Om ofta anv\u00e4nda sidor snabbt hamnar l\u00e4ngst bak i LRU-listan saknas det cacheutrymme eller s\u00e5 pressar skrivbelastningen poolen f\u00f6r h\u00e5rt. I hostingmilj\u00f6er \u00e4r det ofta den delade lagringen som bromsar; h\u00e4r hj\u00e4lper endast belastningsm\u00e4tning under dagen och, vid behov, ett byte till snabbare lagringsmedier. Jag dokumenterar varje \u00e4ndring s\u00e5 att orsaken och <strong>Effekt<\/strong> f\u00f6rbli entydigt \u00e4ven senare.<\/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>Hur Cleaner prioriterar mellan Flush-listan och LRU<\/h2>\n<p>Vid skrivning skiljer InnoDB mellan tv\u00e5 huvudk\u00e4llor: LRU-listan (sidor som m\u00e5ste ge plats f\u00f6r nya \u00e5tkomstf\u00f6rfr\u00e5gningar) och flushlistan (alla smutsiga sidor, sorterade efter \u00e4ldsta loggsekvensnummer). Page Cleaner balanserar dessa tv\u00e5 m\u00e5l: den rensar i slutet av LRU-listan f\u00f6r att undvika evikteringar och h\u00e4mtar samtidigt fr\u00e5n flush-listan f\u00f6r att konstant flytta fram checkpointet. Om det fria buffertutrymmet kommer under press har LRU-flush prioritet; om d\u00e4remot checkpointavst\u00e5ndet \u00f6kar, \u00f6kar rensaren andelen fr\u00e5n flushlistan. Denna omst\u00e4llning f\u00f6rklarar varf\u00f6r latensprofilerna f\u00f6r\u00e4ndras vid varierande arbetsbelastningar: Om l\u00e4sstrycket \u00f6kar dominerar LRU-flushar; om skrivstrycket \u00f6kar dominerar checkpointarbetet. Jag tolkar m\u00f6nstret i \u00f6vervakningen f\u00f6r att avg\u00f6ra om jag snarare beh\u00f6ver optimera I\/O-kapaciteten eller redo-log-reserven.<\/p>\n\n<h2>Adaptiv spolning: Att tolka tr\u00f6skelv\u00e4rdena korrekt<\/h2>\n<p>MariaDB anv\u00e4nder adaptiv flushing f\u00f6r att dynamiskt anpassa skrivhastigheten efter redo-f\u00f6rbrukningen och andelen smutsiga sidor. I praktiken f\u00f6ljer jag tre variabler: m\u00e5lv\u00e4rdet f\u00f6r smutsiga sidor, l\u00e5gvattenm\u00e4rket och den aktuella skrivhastigheten. Om andelen smutsiga sidor ligger \u00f6ver m\u00e5lv\u00e4rdet drar Cleaner \u00e5t tyglarna; om den sjunker under m\u00e5lv\u00e4rdet blir den mer \u00e5terh\u00e5llsam. En f\u00f6r l\u00e5g l\u00e4gsta niv\u00e5 leder till att flushingen startar f\u00f6r ofta och kan orsaka korta men m\u00e4rkbara latensspikar. En f\u00f6r h\u00f6g gr\u00e4ns l\u00e4mnar kvar f\u00f6r mycket skr\u00e4p i minnet, vilket senare ger upphov till st\u00f6rre problem. Jag justerar tr\u00f6skelv\u00e4rdena s\u00e5 att de passar minnessystemets egenskaper: snabba NVMe-SSD:er klarar kontinuerliga, m\u00e5ttligt h\u00f6gre t\u00f6mningshastigheter; l\u00e5ngsammare system drar nytta av j\u00e4mnare, mindre batcher.<\/p>\n\n<h2>Anv\u00e4nda lagringsspecifika alternativ p\u00e5 ett \u00e4ndam\u00e5lsenligt s\u00e4tt<\/h2>\n<p>Page Cleaner fungerar inte i ett vakuum \u2013 valet av t\u00f6mningsmetod och filsystemets beteende p\u00e5verkar resultatet. Med <code>innodb_flush_method<\/code> styr jag om InnoDB skriver till sidor direkt (O_DIRECT) eller via operativsystemets cache. Direkt skrivning undviker dubbel cachelagring och stabiliserar latenserna p\u00e5 Linux med XFS\/EXT4. Filsystem som ZFS hanterar dock O_DIRECT p\u00e5 ett annat s\u00e4tt; d\u00e4r kontrollerar jag om en synkroniserad metod (<em>fsync<\/em>\/<em>O_DSYNC<\/em>) som ger en mer konsekvent profil. Dessutom \u00e4r det v\u00e4rt att ta en titt p\u00e5 grannskapsrensningen (<em>flush-grannar<\/em>): P\u00e5 HDD-matriser kan det vara l\u00e4mpligt att skriva in angr\u00e4nsande block samtidigt, medan jag p\u00e5 SSD\/NVMe minskar detta f\u00f6r att undvika on\u00f6dig skrivf\u00f6rst\u00e4rkning. Det avg\u00f6rande \u00e4r att konfigurationen passar det fysiska mediet \u2013 den b\u00e4sta reng\u00f6ringsalgoritmen hj\u00e4lper f\u00f6ga om den underliggande lagringen bromsas upp.<\/p>\n\n<h2>\u00d6vervakning i praktiken: fr\u00e5gor som hj\u00e4lper mig<\/h2>\n<p>F\u00f6r att snabbt f\u00e5 en \u00f6verblick anv\u00e4nder jag tre perspektiv: globala statusv\u00e4rden, InnoDB-m\u00e4tv\u00e4rden och den periodiska dumpningen.<\/p>\n<ul>\n  <li>\u00d6versiktssiffror: <code>SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty%';<\/code>, <code>... LIKE 'Innodb_os_log_written';<\/code>, <code>... LIKE 'Innodb_log_waits';<\/code>. Stiga <em>loggv\u00e4ntetider<\/em>, \u00e4r redo-loggen f\u00f6r liten eller s\u00e5 \u00e4r flush-funktionen f\u00f6r l\u00e5ngsam.<\/li>\n  <li>Detaljniv\u00e5: <code>SHOW ENGINE INNODB STATUS\\G<\/code> ger checkpoint-positioner (LSN), l\u00e4ngder p\u00e5 flush-listor och indikationer p\u00e5 flaskhalsar. Jag j\u00e4mf\u00f6r \u201eLog sequence number\u201c och \u201eLast checkpoint at\u201c f\u00f6r att uppskatta checkpoint-avst\u00e5ndet.<\/li>\n  <li>Mer detaljerad telemetri: <code>SELECT NAME, COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME LIKE 'buffer_%dirty%';<\/code> eller . <code>... LIKE 'log_%';<\/code> visar trender som l\u00e4tt f\u00f6rbises i korta tester.<\/li>\n<\/ul>\n<p>Det viktiga \u00e4r korrelationen: Om commit-f\u00f6rdr\u00f6jningarna \u00f6kar samtidigt som Fsync-frekvensen \u00f6kar \u00e4r Cleaner troligen inst\u00e4lld p\u00e5 ett f\u00f6r strikt l\u00e4ge. Om andelen smutsiga sidor och checkpoint-avst\u00e5ndet \u00f6kar samtidigt saknas det flush-genomstr\u00f6mning eller s\u00e5 \u00e4r redo-loggen f\u00f6r liten.<\/p>\n\n<h2>Arbetsbelastningsprofiler: OLTP, rapportering, bulk<\/h2>\n<p>Beroende p\u00e5 arbetsbelastningen l\u00e4gger jag olika tyngdpunkter. I OLTP-milj\u00f6er str\u00e4var jag efter kontinuerliga, sm\u00e5 flush-batcher och ett sn\u00e4vt latensintervall \u2013 h\u00e4r \u00e4r m\u00e5ttligt inst\u00e4llda <code>innodb_io_capacity<\/code> och tillr\u00e4ckliga redo-buffertar \u00e4r avg\u00f6rande. F\u00f6r rapporterings- eller ETL-f\u00f6nster accepterar jag tillf\u00e4lligt h\u00f6gre t\u00f6mningsfrekvenser, men ser till att de inte str\u00e4cker sig in i anv\u00e4ndartopparna. Vid massdata\u00f6verf\u00f6ring f\u00f6redrar jag st\u00f6rre redo-loggar och \u2013 om h\u00e5llbarhetskraven till\u00e5ter det \u2013 en tillf\u00e4lligt reducerad fsync-disciplin (<code>innodb_flush_log_at_trx_commit=2<\/code>). Page Cleaner kan d\u00e5 kontinuerligt \u201earbeta ikapp\u201c utan att bromsa anv\u00e4ndarnas transaktioner. N\u00e4r processen \u00e4r klar \u00e5terst\u00e4ller jag de str\u00e4ngare inst\u00e4llningarna s\u00e5 att den dagliga driften f\u00f6rblir stabil.<\/p>\n\n<h2>L\u00e5ngdistansl\u00f6pare, rensning och indirekta effekter<\/h2>\n<p>\u00c4ven om purge-tr\u00e5den har andra syften (att rensa bort \u00e4ldre versioner) p\u00e5verkar dess hastighet helhetsbilden. Om gamla versioner ligger kvar l\u00e4nge \u00f6kar utrymmesbehovet och lagrings- samt I\/O-belastningen f\u00f6rdelas p\u00e5 ett mindre gynnsamt s\u00e4tt. Detta kan indirekt belasta Page Cleaner, eftersom fler sidor \u00e4r bundna i poolen och LRU snabbare hamnar under press. D\u00e4rf\u00f6r h\u00e5ller jag ett \u00f6ga p\u00e5 rensningsf\u00f6rdr\u00f6jningarna och ser till att inga l\u00e5ngvariga transaktioner \u201el\u00e5ser\u201c systemet. Stabil rensningsprocess, kontinuerlig renare, j\u00e4mn skrivfrekvens \u2013 dessa tre kugghjul m\u00e5ste greppa in i varandra.<\/p>\n\n<h2>Checklista f\u00f6r fels\u00f6kning i skrivv\u00e4gen<\/h2>\n<ul>\n  <li>Checkpoint-avst\u00e5ndet \u00e4r stort och \u00f6kar? Ut\u00f6ka redo-loggen och <code>innodb_io_capacity<\/code> h\u00f6ja, och kontrollera sedan f\u00f6rloppet p\u00e5 nytt.<\/li>\n  <li>IOPS-toppar och commit-toppar? <code>innodb_io_capacity<\/code> s\u00e4nka n\u00e5got, j\u00e4mna ut batchstorleken, ta h\u00e4nsyn till dubbelskrivningseffekten.<\/li>\n  <li>\u00c4r andelen \u201ddirty pages\u201d konstant h\u00f6g? \u00d6ka storleken p\u00e5 buffertpoolen eller sk\u00e4rp inst\u00e4llningarna f\u00f6r adaptiv rensning; kontrollera arbetsbelastningen p\u00e5 hotsets.<\/li>\n  <li>Syns log-v\u00e4ntetiderna? Antingen \u00e4r Redo-reserven f\u00f6r liten eller s\u00e5 h\u00e4nger Flush efter. \u00d6ka f\u00f6rst Redo-reserven och finjustera sedan Cleaner-genomstr\u00f6mningen.<\/li>\n  <li>LSN-framsteg oj\u00e4mna? Flush-paketen \u00e4r inkonsekventa. \u00c4ndra v\u00e4rdena stegvis tills man ser ett j\u00e4mnt framsteg.<\/li>\n  <li>Flaskhalsar n\u00e4ra lagringsenheten? Kontrollera flush-metoden, schemal\u00e4ggaren och inst\u00e4llningarna f\u00f6r RAID-\/SAN-cache; anv\u00e4nd h\u00e5llbar IOPS ist\u00e4llet f\u00f6r topp-IOPS som m\u00e5lv\u00e4rde.<\/li>\n<\/ul>\n\n<h2>Exempel: Kalibrering i tre omg\u00e5ngar<\/h2>\n<p>I en skrivintensiv OLTP-instans b\u00f6rjar jag med en belastningsm\u00e4tning i produktionsf\u00f6nstret. Omg\u00e5ng 1: Jag m\u00e4ter fyllnadsgraden f\u00f6r redo-loggen och checkpoint-avst\u00e5ndet. Loggen \u00e4r ofta fylld till 70\u201380 %, avst\u00e5ndet varierar kraftigt \u2013 d\u00e4rf\u00f6r f\u00f6rdubblar jag redo-storleken. Omg\u00e5ng 2: Efter ett nytt test j\u00e4mnas latenserna ut, men ibland uppst\u00e5r Fsync-toppar. Jag s\u00e4nker <code>innodb_io_capacity<\/code> m\u00e5ttligt, tills IOPS-f\u00f6rdelningen blir j\u00e4mnare. Omg\u00e5ng 3: Andelen smutsiga sidor ligger kvar n\u00e4ra den \u00f6vre gr\u00e4nsen. Jag tilldelar buffertpoolen mer RAM, vilket avlastar LRU och g\u00f6r reng\u00f6ringsarbetet mer f\u00f6ruts\u00e4gbart. Resultat: Commit-P95 sjunker m\u00e4rkbart, IOPS-kurvan blir j\u00e4mnare och checkpointen r\u00f6r sig stadigt fram\u00e5t \u2013 precis det m\u00f6nster jag str\u00e4var efter.<\/p>\n\n<h2>Kortfattat sammanfattat<\/h2>\n\n<p>En enda Cleaner-tr\u00e5d hanterar t\u00f6mningen av smutsiga sidor, h\u00e5ller kontrollpunkten i r\u00f6relse och skyddar s\u00f6kningar mot kraftiga skrivspikar. Relevanta inst\u00e4llningsparametrar \u00e4r fortfarande buffertpoolens storlek, I\/O-kapaciteten, redo-loggens layout och minnessystemets egenskaper. F\u00f6r\u00e5ldrade inst\u00e4llningsparametrar som <strong>innodb_page_cleaners<\/strong> Jag bryr mig inte l\u00e4ngre om det och fokuserar ist\u00e4llet p\u00e5 nyckeltal som har direkt inverkan. Den som granskar nyckeltal som andel smutsiga sidor, avst\u00e5nd mellan kontrollpunkter och commit-tid uppt\u00e4cker flaskhalsar snabbare. Stegvisa f\u00f6r\u00e4ndringar med en tydlig utg\u00e5ngspunkt ger tillf\u00f6rlitliga resultat utan att d\u00f6lja bieffekter. P\u00e5 s\u00e5 s\u00e4tt arbetar Page Cleaner tyst i bakgrunden, och <strong>Svarstid<\/strong> f\u00f6rblir j\u00e4mn \u2013 \u00e4ven under belastning.<\/p>","protected":false},"excerpt":{"rendered":"<p>MariaDB Page Cleaner-tr\u00e5dar f\u00f6rklarade: Page Cleaner i MariaDB InnoDB p\u00e5verkar \u201ddirty pages\u201d och databasens prestanda.<\/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":"110","_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\/sv\/wp-json\/wp\/v2\/posts\/21467","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=21467"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/21467\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/21460"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=21467"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=21467"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=21467"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}