{"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":"optimering-af-ydeevnen-ved-hjaelp-af-adaptiv-flushing-i-mariadb","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/mariadb-adaptive-flushing-optimieren-performance\/","title":{"rendered":"Optimering af MariaDB Adaptive Flushing: En praktisk vejledning til bedre ydeevne"},"content":{"rendered":"<p>Adaptiv flushing i MariaDB styrer, hvor hurtigt jeg <strong>Beskidte sider<\/strong> skriver fra bufferpoolen til datamediet, s\u00e5 redo-loggen aldrig bliver et flaskehals. N\u00e5r jeg optimerer MariaDB Adaptive Flushing, falder latenstidstoppe, og <strong>Kontrolpunkt<\/strong>-Fremskridtet forbliver stabilt, og skrivebelastningen kan fortsat planl\u00e6gges.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>M\u00e5lte v\u00e6rdier<\/strong> F\u00f8rst: Redo-log-fyldningsgrad, andel af beskidte sider, checkpoint-alder<\/li>\n  <li><strong>I\/O-kapacitet<\/strong> at bestemme det n\u00f8jagtigt, ikke at ansl\u00e5 det<\/li>\n  <li><strong>T\u00e6rskelv\u00e6rdier<\/strong> Anvendelse med omtanke: adaptive_flushing_lwm og Dirty-Page-LWM<\/li>\n  <li><strong>Baggrunds-I\/O<\/strong> dosering: io_capacity og io_capacity_max<\/li>\n  <li><strong>Redo-logfiler<\/strong> Dimensionering, der sikrer en j\u00e6vn str\u00f8mning<\/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>S\u00e5dan fungerer Adaptive Flushing i MariaDB<\/h2>\n\n<p>Jeg aktiverer den dynamiske logik via <strong>innodb_adaptive_flushing<\/strong> og bidrage til at forme adf\u00e6rden i forbindelse med tidlig varsling <strong>innodb_adaptive_flushing_lwm<\/strong>. Jo mere fyldt redo-loggen er, og jo hurtigere den vokser, desto mere aggressivt udf\u00f8rer InnoDB flush-operationer for at undg\u00e5 flashtilstand. Denne regel knytter flush-frekvensen til den faktiske \u00e6ndringsgennemstr\u00f8mning, hvilket g\u00f8r, at korte I\/O-spidsbelastninger forekommer sj\u00e6ldnere. If\u00f8lge MariaDB-dokumentationen tilpasses intensiteten efter checkpoint-fremskridtet for at undg\u00e5 ventetider p\u00e5 disk-skrivninger. Jeg er dog opm\u00e6rksom p\u00e5, at Adaptive Flushing fordeler arbejdet, men ikke kompenserer for for lav lagerydelse.<\/p>\n\n<h2>Forst\u00e5 n\u00f8gletal: Redo-log, dirty pages og checkpoints<\/h2>\n\n<p>F\u00f8rst ser jeg p\u00e5 den procentvise fyldningsgrad af <strong>Redo-logfiler<\/strong>, andelen af \u00bbdirty pages\u00ab i bufferpoolen og checkpoint-alderen. Disse tre parametre viser mig, om serveren kan t\u00f8mme bufferen i tide og j\u00e6vnt, eller om der hober sig arbejde op. Hvis checkpoint-alderen stiger for hurtigt, reagerer Adaptive Flushing, men jeg tjekker da ogs\u00e5 lagringslatensen. Hvis jeg har detaljerede sp\u00f8rgsm\u00e5l om I\/O-strategien, hj\u00e6lper det mig at kigge p\u00e5 de relevante <a href=\"https:\/\/webhosting.de\/da\/mariadb-flush-metoder-innodb-fsync-ydeevne-vejledning-buffer\/\">Flush-metoder<\/a>, fordi de bestemmer, hvor effektivt kernen behandler skrivekommandoerne. Jeg sammenk\u00e6der disse signaler med den m\u00e5lte I\/O-kapacitet, s\u00e5 jeg kan foretage m\u00e5lrettede \u00e6ndringer af t\u00e6rskelv\u00e6rdierne, samtidig med at det samlede system forbliver sammenh\u00e6ngende.<\/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>Indstil justeringsskruerne korrekt<\/h2>\n\n<p>Jeg begynder med <strong>innodb_io_kapacitet<\/strong> og s\u00e6t v\u00e6rdien t\u00e6t p\u00e5 akkumulatorens reelle kontinuerlige ydelse, ikke p\u00e5 de teoretiske maksimumsv\u00e6rdier. Hvad ang\u00e5r spidsbelastninger, mener jeg, at <strong>innodb_io_capacity_max<\/strong> betydeligt h\u00f8jere, s\u00e5 InnoDB kortvarigt kan \u00f8ge ydeevnen under belastning uden at overbelaste CPU\u2019en. T\u00e6rskelv\u00e6rdien <strong>innodb_adaptive_flushing_lwm<\/strong> Jeg indstiller det s\u00e5ledes, at serveren begynder med preflushing i god tid, f\u00f8r redo-loggen bliver fuld. Derudover indstiller jeg <strong>innodb_max_dirty_pages_pct_lwm<\/strong> s\u00e5ledes at InnoDB griber ind tidligt, n\u00e5r andelen af beskidte sider stiger, og der dermed undg\u00e5s flaskehalse. Jeg \u00e6ndrer kun \u00e9n parameter pr. cyklus, registrerer virkningen n\u00f8je og giver systemet tid til at gennemg\u00e5 flere belastningsfaser, f\u00f8r jeg forts\u00e6tter med at optimere.<\/p>\n\n<h2>Konkret m\u00e5ling af I\/O-kapacitet<\/h2>\n\n<p>Jeg m\u00e5ler den kontinuerlige skriveydelse under produktionsbelastning, fordi syntetiske spidsbelastningstests ofte skaber falske forventninger, og <strong>Ensartethed<\/strong> skjule. Det er de mellem- til langsigtede gennemsnit og percentiler, der er relevante, da de holder stand over korte udj\u00e6vningsperioder. Jeg ser p\u00e5 Write-IOPS, Write-Throughput, latenstider og fordelingen af responstiderne, s\u00e5 jeg ikke kun ser p\u00e5 gennemsnitsv\u00e6rdien. Hvis man kun tager udgangspunkt i maksimumsv\u00e6rdien, risikerer man aggressive flush-faser, mens de egentlige transaktioner bliver langsommere. Jeg drager konklusioner for <strong>innodb_io_kapacitet<\/strong> ud fra den observerede holdbarhed, ikke ud fra kortvarige rekordtider.<\/p>\n\n<h2>Oversigt over startv\u00e6rdier og gr\u00e6nsev\u00e6rdier<\/h2>\n\n<p>Jeg bruger standardv\u00e6rdier som udgangspunkt, aldrig som et dogme, og sammenligner dem med den faktiske arbejdsbelastning, st\u00f8rrelsen p\u00e5 bufferpoolen og v\u00e6ksten i <strong>Redo-logfiler<\/strong>. SSD- og NVMe-systemer har klart h\u00f8jere v\u00e6rdier end HDD\u2019er, men jeg indstiller hastighederne kun s\u00e5 h\u00f8jt, at l\u00e6seadgange ikke havner i k\u00f8en. For systemer med h\u00f8j belastning \u00f8ger jeg kapaciteten gradvist og overv\u00e5ger samtidig latenstid, checkpoint-alder og CPU-forbrug. Hvis andelen af beskidte sider falder j\u00e6vnt, og udsvingene i redo-log-fyldningsgraden mindskes, har jeg opn\u00e5et en sund sikkerhedsmargen. Det er stadig afg\u00f8rende for mig, at jeg <strong>Tips<\/strong> kontroller dem i stedet for at overd\u00f8ve dem med overdreven baggrunds-I\/O.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Variabel<\/th>\n      <th>Effekt<\/th>\n      <th>Typisk startv\u00e6rdi for HDD<\/th>\n      <th>Typisk startv\u00e6rdi for SSD<\/th>\n      <th>Typisk startv\u00e6rdi for NVMe<\/th>\n      <th>Hvad jeg l\u00e6gger m\u00e6rke til<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>innodb_adaptive_flushing<\/td>\n      <td>Aktiverer dynamisk flush<\/td>\n      <td>ON<\/td>\n      <td>ON<\/td>\n      <td>ON<\/td>\n      <td>Udligning af bursts<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_adaptive_flushing_lwm<\/td>\n      <td>Tidlig forskylning<\/td>\n      <td>20\u201330%<\/td>\n      <td>20-40%<\/td>\n      <td>30\u201350%<\/td>\n      <td>Redo-log-fyldningsniveau<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_io_kapacitet<\/td>\n      <td>Grundl\u00e6ggende flush-rate<\/td>\n      <td>100-300<\/td>\n      <td>800\u20132000<\/td>\n      <td>2000\u20138000<\/td>\n      <td>Vedvarende skrive-IOPS<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_io_capacity_max<\/td>\n      <td>N\u00f8dgr\u00e6nse<\/td>\n      <td>400\u2013800<\/td>\n      <td>2000-6000<\/td>\n      <td>6000\u201320000<\/td>\n      <td>Fjerne spidser<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_max_dirty_pages_pct_lwm<\/td>\n      <td>Dirty Page \u2013 Lavt vandniveau<\/td>\n      <td>5\u201310%<\/td>\n      <td>5\u201315%<\/td>\n      <td>5\u201315%<\/td>\n      <td>Tidlig indgriben<\/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>At genkende problemtilf\u00e6lde og symptomer<\/h2>\n\n<p>N\u00e5r jeg <strong>Skylle<\/strong>-spidser, tjekker jeg f\u00f8rst I\/O-v\u00e6rdien: hvis den er for lav, hober de \u00bbdirty pages\u00ab sig op, og systemet bliver n\u00f8dt til hurtigt at rydde op. Er v\u00e6rdien for h\u00f8j, overskygger baggrunds-I\/O den aktuelle arbejdsbelastning og tvinger l\u00e6seoperationer til at vente. En tr\u00e6g checkpoint-alder, der pludselig skyder i vejret, afsl\u00f8rer, at serveren reagerer for sent. Samtidig signalerer en hurtigt stigende redo-log-fyldningsgrad, at skrivesiden ikke kan f\u00f8lge med, eller at loggen er for lille. Jeg fortolker disse m\u00f8nstre samlet, fordi et enkelt tal sj\u00e6ldent fuldt ud forklarer, hvordan Adaptive Flushing opf\u00f8rer sig.<\/p>\n\n<h2>Dimensionering af redo-log for j\u00e6vn belastning<\/h2>\n\n<p>Jeg v\u00e6lger st\u00f8rrelsen p\u00e5 <strong>Redo-logfiler<\/strong> s\u00e5ledes at der er tilstr\u00e6kkelig buffer til belastningsb\u00f8lger, uden at checkpoints bliver for lange. En st\u00f8rre logfil giver Adaptive Flushing mere spillerum til at sprede arbejdet, men jeg holder \u00f8je med gendannelsestider og lagerbudget. Hvis logfilen vokser med hvert sekund mod gr\u00e6nsen, mindsker en moderat for\u00f8gelse presset og udj\u00e6vner flush-kurven. Hvis for\u00f8gelsen ikke giver nogen aflastning, ligger problemet oftest i utilstr\u00e6kkelig I\/O-kapacitet eller svingende lagringslatens. Jeg beslutter f\u00f8rst efter observationsvinduer, ikke ud fra \u00f8jebliksbilleder, om jeg skal h\u00e6ve logst\u00f8rrelsen yderligere.<\/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-tr\u00e5de og parallelitet<\/h2>\n\n<p>Jeg ser p\u00e5 antallet af Page-Cleaner-tr\u00e5de, fordi de udf\u00f8rer den parallelle <strong>Skylle<\/strong>-Styre ydeevnen for bufferpool-instanserne. Ved h\u00f8j skrivebelastning giver yderligere parallelitet st\u00f8rre gennemstr\u00f8mning, men jeg overv\u00e5ger lagringsk\u00f8en n\u00f8je. Hvis datamediet mister sin effektivitet p\u00e5 grund af overfyldte k\u00f8er, reducerer jeg antallet af tr\u00e5de eller begr\u00e6nser I\/O-kapaciteten. For at f\u00e5 en bedre forst\u00e5else af denne mekanisme hj\u00e6lper oversigten over <a href=\"https:\/\/webhosting.de\/da\/mariadb-sideoprydning-trade-database\/\">Page-Cleaner-tr\u00e5de<\/a>, s\u00e5 jeg kan opretholde balancen mellem pres og retf\u00e6rdighed. Jeg tr\u00e6ffer en pragmatisk beslutning: s\u00e5 mange tr\u00e5de som n\u00f8dvendigt, s\u00e5 f\u00e5 som fornuftigt, s\u00e5 l\u00e6sningerne ikke kommer i baggrunden.<\/p>\n\n<h2>Doublewrite-buffer: Sikkerhed kontra skrivehastighed<\/h2>\n\n<p>Jeg tager h\u00f8jde for <strong>Doublewrite<\/strong>-Buffer, da den beskytter mod delvise skrivefejl, men medf\u00f8rer ekstra I\/O. P\u00e5 p\u00e5lidelige NVMe-systemer vejer den ekstra belastning mindre tungt, mens den m\u00e6rkes tydeligere p\u00e5 langsommere lagringsenheder. Jeg m\u00e5ler den faktiske effekt p\u00e5 latenstider og page-flush-rate, f\u00f8r jeg justerer denne indstilling. For at kunne tr\u00e6ffe en velovervejet beslutning benytter jeg mig af uddybende oplysninger om <a href=\"https:\/\/webhosting.de\/da\/innodb-dobbeltskrivningsbuffer-sikkerhed-ydeevne-optimering-fokus\/\">Doublewrite-buffer<\/a> og unders\u00f8ger, om en anden risiko- og afkastprofil passer bedre. Jeg tr\u00e6ffer aldrig en beslutning p\u00e5 letf\u00e6rdig vis, fordi datasikkerhed og gennemstr\u00f8mning her h\u00e6nger direkte sammen.<\/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>Overv\u00e5gning og m\u00e5leparametre i praksis<\/h2>\n\n<p>Jeg vurderer andelen af \u00bbDirty Pages\u00ab, forholdet mellem flush-rate og \u00e6ndringsrate samt udviklingen i <strong>Kontrolpunkt<\/strong>-Age. Derudover overv\u00e5ger jeg den procentvise udnyttelse af redo-loggen over tid, da en line\u00e6r stigning tyder p\u00e5, at t\u00e6rskelv\u00e6rdierne snart er n\u00e5et. Jeg holder \u00f8je med I\/O-forsinkelserne sidel\u00f8bende med InnoDB-statistikkerne, s\u00e5 jeg klart kan sammenholde \u00e5rsag og virkning. Efter hver parameter\u00e6ndring sammenligner jeg identiske belastningsvinduer, ellers drager jeg forkerte konklusioner. Jeg dokumenterer kurverne, fordi et billede siger mere end et enkelt m\u00e5lepunkt, og jeg dermed sikkert kan genkende brud p\u00e5 tendenser.<\/p>\n\n<h2>Trin-for-trin tuningsplan<\/h2>\n\n<p>Jeg begynder med en realistisk m\u00e5ling af <strong>Skrivehastighed<\/strong> og fasts\u00e6tter ud fra dette v\u00e6rdien for innodb_io_capacity. Derefter definerer jeg innodb_io_capacity_max som en n\u00f8dl\u00f8sning i pressede situationer, med tilstr\u00e6kkelig afstand til basisv\u00e6rdien. Dern\u00e6st tjekker jeg innodb_adaptive_flushing_lwm og s\u00e6nker v\u00e6rdien, hvis Checkpoint-Age falder for sent. Herefter indstiller jeg innodb_max_dirty_pages_pct_lwm, s\u00e5 preflushing starter i tide, og spidsbelastninger afvikles tidligt. Til sidst justerer jeg redo-log-st\u00f8rrelsen, observerer igen flere belastningscyklusser og dokumenterer hver \u00e6ndring, f\u00f8r jeg tager det n\u00e6ste skridt.<\/p>\n\n<h2>Flush-mekanisme under h\u00e6tten<\/h2>\n\n<p>Jeg skelner mellem to hovedmotiver for at skrive: det <strong>Flush-List-Flushing<\/strong> (drevet af fremskridtet i Checkpoint) og det <strong>LRU-rensning<\/strong> (for\u00e5rsaget af mangel p\u00e5 ledige sider). Hvis bufferpoolen bliver fuld, og der mangler ledige sider, tvinger LRU-flushing mig til at foretage \u00f8jeblikkelige skrivninger, hvilket skaber spidsbelastninger i latenstiden. Adaptiv flushing har til form\u00e5l at undg\u00e5 disse tvangssituationer ved l\u00f8bende at t\u00f8mme flush-listen. For at dette skal lykkes, holder jeg andelen af frie sider stabil og overv\u00e5ger v\u00e6rdier som LRU-scanningsdybde og udnyttelsesgraden pr. bufferpool-instans. Jo mere j\u00e6vnt flush-listen behandles, desto sj\u00e6ldnere skal jeg vente p\u00e5 frie sider i forgrunden.<\/p>\n\n<p>I den forbindelse tager jeg h\u00f8jde for forholdet mellem <strong>innodb_buffer_pool_instances<\/strong>, <strong>innodb_page_cleaners<\/strong> og den fysiske I\/O-kapacitet. Flere instanser og Cleaner-tr\u00e5de \u00f8ger paralleliteten, men kun i det omfang, det er fornuftigt, s\u00e5 l\u00e6nge lagringsk\u00f8erne ikke l\u00f8ber over. Hvis flush-operationer n\u00e5r h\u00f8je k\u00f8-l\u00e6ngder, er det et tegn p\u00e5, at jeg burde have foretaget flush tidligere og langsommere \u2013 netop dette l\u00f8ser jeg via innodb_adaptive_flushing_lwm og basis-\/maks-kapaciteterne.<\/p>\n\n<h2>Transaktions-commit, redo og binlog i sammenh\u00e6ng<\/h2>\n\n<p>Jeg ser p\u00e5 commit-stier og holdbarhedsgarantier i sammenh\u00e6ng med flush-udj\u00e6vning. <strong>innodb_flush_log_at_trx_commit<\/strong> og binlog-synkroniseringen p\u00e5virker, hvor ofte systemet udf\u00f8rer fsyncs, og hvor store de kortvarige spidsbelastninger bliver. Mine retningslinjer:<\/p>\n\n<ul>\n  <li>1: Maksimal holdbarhed (Redo ved hver commit p\u00e5 lagringsmediet). Sikkert, men kr\u00e6ver mange fsync-kommandoer og kan potentielt v\u00e6re mere ustabilt.<\/li>\n  <li>2: Redo t\u00f8mmes hvert sekund, mens Commit kun skriver til operativsystemets cache. Der er f\u00e6rre spidsbelastninger, men til geng\u00e6ld risikerer jeg datatab i tilf\u00e6lde af nedbrud i operativsystemet eller p\u00e5 v\u00e6rten.<\/li>\n  <li>0: Ligner 2, men cachen er endnu mere aggressiv. B\u00f8r kun bruges med forsigtighed i produktionssystemer.<\/li>\n<\/ul>\n\n<p>Sammen med Binlog-synkroniseringen (<strong>sync_binlog<\/strong>) og Group-Commit-effekter kan jeg samle commits og reducere antallet af h\u00e5rde synkroniseringer. Det er vigtigt, at jeg ikke misbruger disse v\u00e6rkt\u00f8jer som erstatning for en ordentlig finjustering af Adaptive Flushing. Jeg vurderer altid risiko, compliance-krav og den \u00f8nskede latenstidsprofiler samlet og justerer kun i det omfang, forretningsreglerne tillader det.<\/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>Ryd tr\u00e5de, historikl\u00e6ngde og langvarige tr\u00e5de<\/h2>\n\n<p>Jeg har den <strong>InnoDB-rensning<\/strong> V\u00e6r opm\u00e6rksom p\u00e5: Mange slettede eller opdaterede linjer genererer fortrydelsesdata, der ryddes asynkront. Hvis <em>Historiens l\u00e6ngde<\/em> Hvis belastningen er stor, stiger baggrundsbelastningen og konkurrerer med side-cleanerne om I\/O. Dette kan indirekte bremse Adaptive Flushing. L\u00f8sningen er at indstille en passende v\u00e6rdi for purge-parallellitet og undg\u00e5 langvarige transaktioner, der kunstigt holder historikken \u00e5ben. Desuden planl\u00e6gger jeg batch-operationer s\u00e5ledes, at jeg kontrollerer m\u00e6ngden af redo- og undo-operationer i stedet for at \u00e6ndre millioner af r\u00e6kker i sm\u00e5 portioner p\u00e5 kort tid.<\/p>\n\n<h2>Change Buffer og Merge-faser<\/h2>\n\n<p>Jeg tager h\u00f8jde for <strong>Skift buffer<\/strong> ved intensive opdateringer af sekund\u00e6re indekser. Det reducerer tilf\u00e6ldig I\/O under k\u00f8rsel, men flytter en del af arbejdet til senere sammenl\u00e6gningsfaser. Disse sammenl\u00e6gninger kan skabe en ekstra flush-belastning, hvis de uheldigvis falder sammen med spidsbelastninger i produktionen. Jeg overv\u00e5ger derfor st\u00f8rrelsen og aktiviteten i \u00e6ndringsbufferen, begr\u00e6nser den om n\u00f8dvendigt og spreder bulk\u00e6ndringer, s\u00e5 sammenl\u00e6gningsfaser ikke kolliderer med spidsbelastninger. Dermed forbliver flush-frekvensen mere forudsigelig og j\u00e6vn.<\/p>\n\n<h2>Flush-metoder og filsystemets indflydelse<\/h2>\n\n<p>Jeg tr\u00e6ffer en bevidst beslutning om <strong>Flush-metoden<\/strong> og filsystemindstillingerne. O_DIRECT undg\u00e5r dobbelte cacher og udj\u00e6vner dermed ofte skrivelatenser, mens AIO og Fsync-stier har deres egne karakteristika. Jeg m\u00e5ler, hvordan disse metoder p\u00e5virker latenstidsfordelingen og stabiliteten i checkpoint-fremskridtet, og henviser ved detaljerede sp\u00f8rgsm\u00e5l til vejledningen om <a href=\"https:\/\/webhosting.de\/da\/mariadb-flush-metoder-innodb-fsync-ydeevne-vejledning-buffer\/\">Flush-metoder<\/a>. Derudover tjekker jeg filsystemets monteringsindstillinger og vedligeholdelsesrutiner (f.eks. konsistente TRIM-\/Discard-strategier for SSD\u2019er), s\u00e5 infrastrukturen ikke ubevidst for\u00e5rsager jitter.<\/p>\n\n<h2>Diagnose: Korrekt afl\u00e6sning af statusmeddelelser<\/h2>\n\n<p>Jeg tr\u00e6kker <em>VIS INNODB-STATUS FOR MOTOREN<\/em> for at vurdere Checkpoint-Age og Flush-fremskridt. Fra <em>Log-sekvensnummer<\/em>, <em>Loggen er ryddet frem til<\/em> og <em>Sidste kontrolpunkt ved<\/em> unders\u00f8ger jeg, hvor stor forskellen er mellem genererede og gemte \u00e6ndringer. Hvis forskellen vokser kontinuerligt hurtigere, end redo-log-st\u00f8rrelsen tillader, er min baggrunds-flush for forsigtig, eller er I\/O-latensen for h\u00f8j. Jeg sammenligner disse v\u00e6rdier med InnoDB-metrikkerne for \u00bbDirty Pages\u00ab, flush-rate og Page Cleaner-aktivitet, s\u00e5 jeg m\u00e5lrettet kan justere de relevante parametre i stedet for blot at behandle symptomerne.<\/p>\n\n<h2>Driftsscenarier: Bulk, DDL og vedligeholdelsesvinduer<\/h2>\n\n<p>Jeg planl\u00e6gger <strong>Storlast<\/strong> og omfattende <strong>DDL<\/strong>-operationer, s\u00e5 Adaptive Flushing ikke overskrides. I forbindelse med planlagte vedligeholdelsesvinduer \u00f8ger jeg midlertidigt <strong>innodb_io_capacity_max<\/strong>, for at udf\u00f8re de forest\u00e5ende skrivninger p\u00e5 en kontrolleret m\u00e5de, og s\u00e6nker den derefter igen til det normale niveau. Ved store importoperationer justerer jeg commit-frekvenserne, s\u00e5 v\u00e6ksten i redo-loggen og fremskridtet i checkpoint-processen holder trit. I mellemtiden overv\u00e5ger jeg l\u00f8bende redo-log-fyldningsgraden, andelen af beskidte sider og latenstidens percentiler, s\u00e5 jeg straks kan gribe ind, hvis der opst\u00e5r afvigelser.<\/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>Almindelige misforst\u00e5elser og anti-m\u00f8nstre<\/h2>\n\n<p>Jeg falder ikke i f\u00e6lden, <strong>innodb_io_capacity_max<\/strong> at bruge det som en permanent tilstand. En for h\u00f8j Max-v\u00e6rdi kan overbelaste hukommelsesk\u00f8erne og bremse realtidsl\u00e6seadgang. Jeg \u201eskjuler\u201c heller ikke svag hukommelse bag en k\u00e6mpe redo-log \u2013 st\u00f8rre logfiler udj\u00e6vner belastningen, men skaber ikke I\/O-reserver. Og jeg accepterer ikke latenstops som en given kendsgerning: Ofte er de resultatet af for sen preflushing eller st\u00e6rkt svingende baggrundsbelastning, som jeg kan afb\u00f8de ved hj\u00e6lp af lavere LWM-t\u00e6rskler og realistiske kapacitetsv\u00e6rdier. Endelig undg\u00e5r jeg at \u00e6ndre flere indstillingsparametre p\u00e5 samme tid; ellers mister jeg kausaliteten og kan ikke g\u00f8re forbedringerne reproducerbare.<\/p>\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Jeg bruger <strong>Adaptiv<\/strong> Flushing for at fordele skriveopgaver j\u00e6vnt over tid og dermed undg\u00e5 spidsbelastninger. Den st\u00f8rste indflydelse opn\u00e5s ved en pr\u00e6cis indstilling af innodb_io_capacity og et fornuftigt forhold til innodb_io_capacity_max. Tidligt indsatte t\u00e6rskelv\u00e6rdier for redo-log-fyldningsgrad og andel af beskidte sider hj\u00e6lper mig med at holde k\u00f8erne sm\u00e5. Med passende redo-logs, fornuftig parallelitet mellem page-cleaner-tr\u00e5dene og opm\u00e6rksom overv\u00e5gning opn\u00e5r jeg mere p\u00e5lidelige skriverutiner. If\u00f8lge MariaDB-dokumentationen om systemvariabler og sideflushing virker disse justeringsmuligheder sammen \u2013 jeg justerer dem trin for trin og holder \u00f8je med effekten, indtil systemet k\u00f8rer stabilt og forudsigeligt.<\/p>","protected":false},"excerpt":{"rendered":"<p>Optimering af MariaDB Adaptive Flushing ved hj\u00e6lp af InnoDB-tuning, I\/O-kapacitet og praktiske tips til stabil ydeevne.<\/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":"94","_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\/da\/wp-json\/wp\/v2\/posts\/21589","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=21589"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21589\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21582"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21589"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21589"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21589"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}