{"id":21539,"date":"2026-09-19T08:33:36","date_gmt":"2026-09-19T06:33:36","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-flush-methoden-innodb-fsync-performance-guide-buffer\/"},"modified":"2026-09-19T08:33:36","modified_gmt":"2026-09-19T06:33:36","slug":"mariadb-flush-metoder-innodb-fsync-ydeevne-vejledning-buffer","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/mariadb-flush-methoden-innodb-fsync-performance-guide-buffer\/","title":{"rendered":"Sammenligning af MariaDB-flush-metoder: optimal indstilling af innodb flush"},"content":{"rendered":"<p>Jeg sammenligner de vigtigste metoder til <strong>MariaDB-flush<\/strong> og viser, hvordan jeg indstiller innodb flush, s\u00e5 skrivelatensen reduceres, og dataene forbliver sikre. Fokus ligger p\u00e5 indstillingerne for `innodb_flush_method`, holdbarhedsregulatoren `innodb_flush_log_at_trx_commit` samt fornuftige v\u00e6rdier for `Dirty Pages` og I\/O-kapacitet p\u00e5 HDD, SSD og NVMe.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>innodb_flush_method<\/strong> bestemmer, hvordan InnoDB interagerer med operativsystemets cache og undg\u00e5r dobbeltcaching.<\/li>\n  <li><strong>innodb_flush_log_at_trx_commit<\/strong> bestemmer holdbarhed kontra ventetid pr. commit.<\/li>\n  <li><strong>Beskidte sider<\/strong> og I\/O-kapaciteten udj\u00e6vner skrivehastighederne og forhindrer flush-storme.<\/li>\n  <li><strong>Flush-naboer<\/strong> skelner mellem strategier, der er optimeret til HDD, og strategier, der er optimeret til SSD\/NVMe.<\/li>\n  <li><strong>Cloud-ops\u00e6tninger<\/strong> kr\u00e6ver O_DIRECT, en passende IOPS-gr\u00e6nse og p\u00e5lidelig overv\u00e5gning.<\/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-flush-0123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad betyder \u00bbinnodb_flush_method\u00ab helt konkret?<\/h2>\n\n<p>Jeg v\u00e6lger <strong>Flush-metoden<\/strong> afh\u00e6nger af, hvordan InnoDB samarbejder med operativsystemets cache. Med <strong>fsync<\/strong> Dataene havner f\u00f8rst i OS-cachen og skrives derefter permanent via fsync; dette kan f\u00f8re til dobbeltcaching. Hvis jeg indstiller O_DIRECT, omg\u00e5r InnoDB i vid udstr\u00e6kning sidecachen, hvilket sparer RAM og n\u00e6sten altid er en fordel p\u00e5 SSD\/NVMe. O_DSYNC bruger write-through og reducerer buffering, hvilket kan v\u00e6re nyttigt i bestemte kombinationer. O_DIRECT_NO_FSYNC bygger videre p\u00e5 O_DIRECT og tilpasser synkroniseringsadf\u00e6rden, hvilket er et st\u00e6rkt valg p\u00e5 p\u00e5lidelig hardware med egen beskyttelsesmekanisme.<\/p>\n\n<h3>Typiske v\u00e6rdier og versioner<\/h3>\n\n<p>Fra og med MariaDB 10.6 er <strong>O_DIRECT<\/strong> ofte standardindstillingen, fordi det forhindrer dobbeltcaching. I \u00e6ldre versioner er det <strong>fsync<\/strong>, hvilket stadig kan v\u00e6re acceptabelt for HDD-konfigurationer. Fra version 11.0 styrer yderligere variabler som innodb_data_file_buffering og innodb_log_file_buffering detaljerne i bufferingen. I praksis er innodb_flush_method stadig den centrale parameter, som jeg tjekker f\u00f8rst. Derefter finjusterer jeg de detaljerede parametre, indtil latenstiderne falder, og gennemstr\u00f8mningen forbliver konstant.<\/p>\n\n<h2>M\u00e5lrettet brug af innodb_flush_log_at_trx_commit<\/h2>\n\n<p>Jeg overvejer <strong>Holdbarhed<\/strong> og latenstid adskilt, da innodb_flush_log_at_trx_commit bestemmer begge dele. V\u00e6rdien 1 skriver og udf\u00f8rer fsync ved hver commit, hvilket giver maksimal sikkerhed, men bremser langsomme diske kraftigt. V\u00e6rdien 2 skriver til operativsystemets cache ved hver commit og udf\u00f8rer fsync cirka \u00e9n gang pr. sekund; dette reducerer latenstiden, men medf\u00f8rer en risiko for datatab p\u00e5 op til et sekund i tilf\u00e6lde af str\u00f8msvigt. V\u00e6rdien 0 udskyder log-skrivninger fuldst\u00e6ndigt til hvert sekund og leverer den h\u00f8jeste skriveydelse med den st\u00f8rste risiko. Hvis man desuden tager h\u00f8jde for binlog-strategien, kan man klogt tilpasse commit-latenser til replikeringskravene; jeg forklarer detaljerne om samspillet her: <a href=\"https:\/\/webhosting.de\/da\/mariadb-binaere-logfiler-ydeevne-logik\/\">Bin\u00e6re logfiler<\/a>.<\/p>\n\n<h2>Styring af side-flushing og dirty pages<\/h2>\n\n<p>Jeg mener, at andelen af <strong>Beskidte sider<\/strong> s\u00e5ledes at skrivehastighederne forbliver konstante. Til dette form\u00e5l indstiller jeg innodb_max_dirty_pages_pct til et moderat niveau, s\u00e5 der ikke opst\u00e5r pludselige flush-spidsbelastninger. V\u00e6rdierne for innodb_io_capacity og innodb_io_capacity_max tilpasser jeg til lagerets reelle IOPS: lavt for HDD, h\u00f8jere for SSD\/NVMe. En velkonfigureret page-cleaner-tr\u00e5d skriver tilbage i tide set ud fra et LRU-perspektiv, inden siderne fortr\u00e6nges. Jeg beskriver mere om finjustering af tr\u00e5de og nyttige m\u00e5linger her: <a href=\"https:\/\/webhosting.de\/da\/mariadb-sideoprydning-trade-database\/\">Page-Cleaner-tr\u00e5de<\/a>.<\/p>\n\n<h2>Flush-Neighbors: HDD kontra SSD\/NVMe<\/h2>\n\n<p>Med <strong>innodb_flush_neighbors<\/strong> Jeg bruger HDD-venlige skrivem\u00f8nstre eller sl\u00e5r dem fra. P\u00e5 HDD\u2019er \u00f8ger samtidig skrivning af tilst\u00f8dende sider effektiviteten, fordi l\u00e6seren ikke beh\u00f8ver at springe s\u00e5 meget rundt. P\u00e5 SSD\/NVMe er placeringen p\u00e5 mediet stort set irrelevant, da skrivning af tilst\u00f8dende sider der skaber un\u00f8dvendige skrivninger. For HDD indstiller jeg normalt v\u00e6rdien 1, for SSD\/NVMe v\u00e6rdien 0. P\u00e5 den m\u00e5de reducerer jeg un\u00f8dvendige skrivninger og sk\u00e5ner levetiden p\u00e5 hurtige drev.<\/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_flush_vergleich_7643.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Forst\u00e5 og begr\u00e6nse fsync-omkostningerne<\/h2>\n\n<p>Jeg m\u00e5ler p\u00e5 <strong>fsync<\/strong>-Latens, fordi hver millisekund forsinker commit-operationer. Skriveintensive arbejdsbelastninger bruger ellers en stor del af tiden p\u00e5 at vente p\u00e5 bekr\u00e6ftelse fra lagringsmediet. Med innodb_flush_log_at_trx_commit=2 eller 0 reducerer jeg antallet af ressourcekr\u00e6vende synkroniseringer markant. O_DIRECT eller O_DIRECT_NO_FSYNC hj\u00e6lper med at undg\u00e5 dobbeltcaching og forenkle I\/O-stier. P\u00e5 langsom hardware opn\u00e5r jeg ofte m\u00e6rkbare forbedringer, n\u00e5r jeg ser p\u00e5 synkroniseringsfrekvens, flush-metode og andel af beskidte sider samlet.<\/p>\n\n<h2>Anbefalede startv\u00e6rdier efter lagringsmedie<\/h2>\n\n<p>Jeg begynder med meningsfulde <strong>Baseline<\/strong>-v\u00e6rdier og justerer dem derefter ud fra m\u00e5lev\u00e6rdier. Tabellen giver retningslinjer for typiske ops\u00e6tninger og arbejdsbelastninger. Det afg\u00f8rende er reelle IOPS, latenstider og andelen af skrivetransaktioner. Efter den f\u00f8rste k\u00f8rsel kontrollerer jeg andelen af beskidte sider, commit-latenstid og antallet af fsync-kald. Derefter finjusterer jeg trin for trin, indtil profilen er ren og stabil.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Medium<\/th>\n      <th>innodb_flush_method<\/th>\n      <th>innodb_flush_log_at_trx_commit<\/th>\n      <th>innodb_io_kapacitet<\/th>\n      <th>innodb_flush_neighbors<\/th>\n      <th>Noter<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>HDD<\/td>\n      <td>fsync eller O_DIRECT<\/td>\n      <td>1 (kritisk) \/ 2 (balance)<\/td>\n      <td>200\u2013400<\/td>\n      <td>1<\/td>\n      <td>St\u00f8rre forsinkelse pr. <strong>Forpligtelse<\/strong>, det er vigtigt at skylle l\u00f8bende<\/td>\n    <\/tr>\n    <tr>\n      <td>SSD<\/td>\n      <td>O_DIRECT<\/td>\n      <td>1 (kritisk) \/ 2 (balance)<\/td>\n      <td>1000\u20132000<\/td>\n      <td>0<\/td>\n      <td>Undg\u00e5 dobbeltcaching, hold antallet af \u00bbdirty pages\u00ab p\u00e5 et moderat niveau<\/td>\n    <\/tr>\n    <tr>\n      <td>NVMe<\/td>\n      <td>O_DIRECT eller O_DIRECT_NO_FSYNC<\/td>\n      <td>1 (kritisk) \/ 2 (balance) \/ 0 (s\u00e6rligt tilf\u00e6lde)<\/td>\n      <td>2000\u20138000+<\/td>\n      <td>0<\/td>\n      <td>Meget lav <strong>Forsinkelse<\/strong>, V\u00e6lg synkroniseringsfrekvensen omhyggeligt<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>I den forbindelse tager jeg h\u00f8jde for InnoDB <strong>Doublewrite-buffer<\/strong>, som mindsker datakorruption ved nedbrud, men medf\u00f8rer yderligere skrivninger; her giver jeg et kort overblik over baggrunden og indstillingsmulighederne: <a href=\"https:\/\/webhosting.de\/da\/innodb-dobbeltskrivningsbuffer-sikkerhed-ydeevne-optimering-fokus\/\">Doublewrite-buffer<\/a>. I skriveintensive milj\u00f8er foretager jeg m\u00e5linger b\u00e5de med og uden doublewrite-effekter, inden jeg tr\u00e6ffer beslutninger. I kritiske systemer prioriteres integritet frem for maksimal skrivehastighed. Test- eller analyseops\u00e6tninger m\u00e5 gerne v\u00e6re mere aggressive. Jeg underbygger altid mine beslutninger med reproducerbare benchmarks.<\/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-flush-methoden-vergleich-5876.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cloud- og containermilj\u00f8er<\/h2>\n\n<p>Jeg undg\u00e5r dobbelt <strong>Side-cache<\/strong>, fordi der er begr\u00e6nset RAM; O_DIRECT passer derfor ofte godt. Jeg tilpasser innodb_io_capacity til volumenets IOPS-gr\u00e6nser, s\u00e5 jeg ikke udl\u00f8ser en begr\u00e6nsning. Bufferpoolen skal passe til Cgroup-gr\u00e6nsen, ellers risikerer man OOM-kills. Persistente volumener er et must, da ephemeral storage ikke tilbyder varighed. I meget elastiske ops\u00e6tninger begr\u00e6nser jeg for mange samtidige forbindelser og bruger tr\u00e5dpuljen med omtanke.<\/p>\n\n<h2>Indstillinger for sikkerhedskopiering og t\u00f8mning<\/h2>\n\n<p>Jeg tjekker, om backup-v\u00e6rkt\u00f8jerne har deres egne <strong>Skylle<\/strong>-Brug indstillingerne. mariadb-backup kan indstille innodb_flush_method anderledes for at opn\u00e5 et konsistent billede. Hvis backup- og serverparametrene ikke stemmer overens, opst\u00e5r der un\u00f8dvendige I\/O-spidsbelastninger. Under planlagte sikkerhedskopieringer regulerer jeg I\/O-kapaciteten forsigtigt, s\u00e5 l\u00e6se-\/skrivestier forbliver rene. Efter k\u00f8rslen kontrollerer jeg latenstider og andelen af beskidte sider for at udelukke bivirkninger.<\/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-flush-optimal-3435.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Trin-for-trin-tuning i praksis<\/h2>\n\n<p>Jeg begynder med en <strong>Inventar<\/strong>: Lagertype, reelle IOPS, ventetider og gennemstr\u00f8mning. Derefter fastl\u00e6gger jeg st\u00f8rrelsen p\u00e5 bufferpoolen, s\u00e5 den passer til den tilg\u00e6ngelige RAM eller Cgroup-gr\u00e6nsen. Til sidst v\u00e6lger jeg flush-metoden (HDD: fsync\/O_DIRECT; SSD\/NVMe: O_DIRECT eller O_DIRECT_NO_FSYNC). Af hensyn til holdbarheden indstiller jeg innodb_flush_log_at_trx_commit til 1 for kritiske data eller til 2, hvis et sekunds tab er acceptabelt. Til sidst indstiller jeg innodb_io_capacity og innodb_max_dirty_pages_pct, s\u00e5 flushing foreg\u00e5r roligt og stabilt, og jeg kontrollerer m\u00e5lingerne regelm\u00e6ssigt.<\/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-flush-vergleich-8243.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Korrekt dimensionering af redo-log-st\u00f8rrelse og checkpoints<\/h2>\n\n<p>Jeg undg\u00e5r flush-toppe ved at <strong>Redo-logfiler<\/strong> dimensionere dem korrekt. For sm\u00e5 logfiler tvinger InnoDB til hyppige checkpoints; det medf\u00f8rer backpressure og ustabile ventetider. Med st\u00f8rre logfiler udj\u00e6vner jeg checkpoint-forl\u00f8bet, fordi der kan bufferes flere \u00e6ndringsdata, f\u00f8r de er n\u00f8dt til at flyttes over i datafilerne. Her tager jeg h\u00f8jde for to begr\u00e6nsninger: for det f\u00f8rste den tilg\u00e6ngelige I\/O-kapacitet (en stor buffer beskytter ikke mod for langsomme diske), for det andet crash-recovery-tiden, som stiger med meget store redo-logs. I skriveintensive arbejdsbelastninger indstiller jeg logst\u00f8rrelsen s\u00e5ledes, at typiske belastningsspidser absorberes inden for logbudgettet, uden at gendannelsestiden stiger urimeligt.<\/p>\n\n<p>For at finjustere overv\u00e5ger jeg m\u00e5lingerne for \u201echeckpoint age\u201c og forholdet mellem log-skrivehastigheden og flush-hastigheden for datasiderne. Hvis checkpoints gentagne gange n\u00e5r den \u00f8vre gr\u00e6nse, skalerer jeg enten logst\u00f8rrelsen eller \u00f8ger forsigtigt I\/O-kapaciteten for Page Cleaner. M\u00e5let er en j\u00e6vn, kontinuerlig fremdrift i checkpoints uden tvungne handlinger.<\/p>\n\n<h2>Adaptiv skylning og t\u00e6rskelv\u00e6rdier<\/h2>\n\n<p>InnoDB\u2019s adaptive mekanismer hj\u00e6lper med at udf\u00f8re flushing af den aktuelle <strong>Skrivhastighed<\/strong> at justere. Jeg s\u00f8rger for, at LWM-t\u00e6rsklen (Low Watermark) for Dirty Pages ikke er for lav, s\u00e5 Page-Cleaner ikke hele tiden k\u00f8rer \u201ep\u00e5 kanten\u201c. Samtidig undg\u00e5r jeg maksimumsv\u00e6rdier, der f\u00f8rer til for aggressive bulk-flushes. I praksis kontrollerer jeg, om forholdet mellem \u201enye dirty pages pr. sekund\u201c og \u201eflush-IOPS\u201c forbliver stabilt p\u00e5 lang sigt. Hvis bufferpoolen konstant overskrider m\u00e5let for dirty pages, \u00f8ger jeg gradvist innodb_io_capacity eller reducerer m\u00e5lene for dirty pages.<\/p>\n\n<p>P\u00e5 NVMe-konfigurationer kan jeg give Page-Cleaner mere spillerum, fordi enhederne opretholder korte ventetider selv under belastning. P\u00e5 HDD\u2019er arbejder jeg med mere konservative t\u00e6rskelv\u00e6rdier og begr\u00e6nser store udsving for at undg\u00e5 ventetidstop for\u00e5rsaget af s\u00f8gninger. Samspillet med <strong>innodb_flush_neighbors<\/strong> Det udnytter jeg m\u00e5lrettet: HDD drager fordel af den fysiske placering, mens flash ikke g\u00f8r det.<\/p>\n\n<h2>Binlog og Group-Commit i samspil<\/h2>\n\n<p>Den, der anvender replikering, tager h\u00f8jde for dette <strong>Commit-protokol<\/strong> om redo-log og bin\u00e6r log. Jeg indstiller flush-frekvenserne, s\u00e5 group-commit tr\u00e6der i kraft: Mange sm\u00e5 transaktioner skal flushes samlet i stedet for at synkronisere hver enkelt commit. Her passer innodb_flush_log_at_trx_commit=1 til maksimal holdbarhed eller 2 til lavere latenstid. Samtidig indstiller jeg binlog-synkroniseringsmekanismen, s\u00e5 den passer til m\u00e5lsystemet. En lav synkroniseringsfrekvens reducerer omkostningerne pr. commit, men kan medf\u00f8re st\u00f8rre tab af binlog ved nedbrud. I milj\u00f8er med h\u00f8j skrivehastighed og en acceptabel forsinkelse mellem master og replika accepterer jeg en moderat afkobling af binlog-synkroniseringerne for at reducere latenstiderne. Den overordnede logik og afvejningerne beskriver jeg i indl\u00e6gget om <a href=\"https:\/\/webhosting.de\/da\/mariadb-binaere-logfiler-ydeevne-logik\/\">Bin\u00e6re logfiler<\/a> og tilpasser dem derefter til den konkrete flush-profil.<\/p>\n\n<h2>Filsystem, skrivecache og beskyttelse mod str\u00f8msvigt<\/h2>\n\n<p>Jeg vurderer <strong>Hukommelses- og controller-egenskaber<\/strong> f\u00f8r tuningen. Enheder med <em>Beskyttelse mod str\u00f8mtab<\/em> (PLP) kan sikkert benytte skrivecacher; uden PLP er der risiko for, at skrivninger, der er markeret som bekr\u00e6ftede, g\u00e5r tabt ved str\u00f8msvigt. I s\u00e5danne tilf\u00e6lde v\u00e6lger jeg en mere konservativ tilgang: fsync-stier er stadig obligatoriske, og jeg bruger kun O_DIRECT_NO_FSYNC p\u00e5 hardware med p\u00e5lidelig beskyttelse. P\u00e5 Linux-filsystemer som ext4 eller XFS er disse beskyttelsesmekanismer som standard aktive; jeg deaktiverer dem ikke letf\u00e6rdigt, men tilpasser optimeringen ud fra de eksisterende garantier. P\u00e5 ZFS tager jeg desuden h\u00f8jde for dets eget Intent Log og caching-strategier; afh\u00e6ngigt af ops\u00e6tningen kan det betale sig at anvende en separat tilpasset strategi, der ligeledes minimerer dobbeltcaching.<\/p>\n\n<p>For at sikre ensartet ydeevne tjekker jeg desuden alignments (f.eks. 4K-sider p\u00e5 SSD) og indstilling af k\u00f8dybden. Korte, deterministiske ventetider er ofte vigtigere for commit-stier end maksimale IOPS i syntetiske benchmarks. Derfor tester jeg med realistiske blokke og forskellige grader af samtidighed i stedet for kun med spidsbelastninger.<\/p>\n\n<h2>M\u00e5lemetodik: M\u00e5leparametre, status og diagnose<\/h2>\n\n<p>Jeg styrer indstillingen via <strong>konkrete m\u00e5lev\u00e6rdier<\/strong> i stedet for f\u00f8lelse. Blandt mine standardindikatorer er:<\/p>\n<ul>\n  <li>Commit-latens (p50\/p95\/p99) under spidsbelastninger<\/li>\n  <li>fsync-latens og -hastighed for log- og datafiler<\/li>\n  <li>Andelen af \u00bbDirty Pages\u00ab over tid og dens varians<\/li>\n  <li>Fremskridt ved kontrolpunkter og forholdet mellem log-skrivningshastighed og flush-hastighed<\/li>\n  <li>Page-Cleaner-backlog (er der konstant udest\u00e5ende flushes?)<\/li>\n<\/ul>\n<p>Til dette form\u00e5l bruger jeg statusudskrifterne fra InnoDB og sammenholder dem med OS-metrikker (iostat, vmstat). Jeg holder is\u00e6r \u00f8je med disk-latensen i millisekunder, fordelingen mellem l\u00e6sninger og skrivninger samt andelen af synkrone operationer. For at sikre reproducerbare tests \u00e6ndrer jeg m\u00e5lrettet kun \u00e9n parameter pr. trin og registrerer resultatet over l\u00e6ngere tidsintervaller, s\u00e5 outliers ikke dominerer.<\/p>\n\n<h2>Almindelige anti-m\u00f8nstre og modforanstaltninger<\/h2>\n\n<ul>\n  <li>For sm\u00e5 redo-logfiler: medf\u00f8rer hyppige checkpoints. L\u00f8sning: For\u00f8g logfilst\u00f8rrelsen og tilpas I\/O-kapaciteten til flushing.<\/li>\n  <li>Andelen af \u00bbdirty pages\u00ab er vedvarende for h\u00f8j: Page-Cleaner er overbelastet, og der er risiko for flush-storme. Modforanstaltning: S\u00e6nk innodb_max_dirty_pages_pct og \u00f8g io_capacity.<\/li>\n  <li>O_DIRECT uden overv\u00e5gning: Undg\u00e5r ganske vist dobbeltcaching, men kan f\u00f8re til bursts, hvis I\/O-kapaciteten er forkert indstillet. Modforanstaltning: N\u00f8je overv\u00e5gning og tilpasning af kapacitetsv\u00e6rdierne til de faktiske IOPS.<\/li>\n  <li>Uhensigtsm\u00e6ssige \u00bbflush-neighbors\u00ab p\u00e5 SSD\/NVMe: skaber un\u00f8dvendigt arbejde uden nogen fordel. L\u00f8sning: Indstil innodb_flush_neighbors=0.<\/li>\n  <li>Commit-synkroniseringer p\u00e5 langsomme medier: Hver transaktion medf\u00f8rer en fsync-omkostning. Modforanstaltning: Fremme group-commit, eventuelt ved at indstille innodb_flush_log_at_trx_commit=2 (efter en risikovurdering).<\/li>\n  <li>Container uden RAM-buffer: Bufferpoolen er for stor, der er risiko for OOM. L\u00f8sning: Tilpas bufferpoolen n\u00f8je efter Cgroup-gr\u00e6nserne og hold \u00f8je med Pressure.<\/li>\n<\/ul>\n\n<h2>Medregne nedluknings- og gendannelsesforl\u00f8b<\/h2>\n\n<p>Jeg planl\u00e6gger, hvordan indstillingerne p\u00e5virker <strong>Nedlukning<\/strong> og <strong>Gendannelse efter nedbrud<\/strong> indvirke. En hurtig og korrekt nedlukning reducerer gendannelsestiderne, fordi der skal anvendes f\u00e6rre redo-logs. Meget store redo-logs fremmer stabile checkpoints, men forl\u00e6nger gendannelsen i tilf\u00e6lde af fejl. For produktive systemer v\u00e6lger jeg en balance, s\u00e5 jeg p\u00e5 den ene side ikke skaber flush-storme i den daglige drift, og p\u00e5 den anden side ikke skal acceptere en alt for lang genopretning i v\u00e6rste fald. Vedligeholdelsesvinduer og sikkerhedskopier tager jeg h\u00f8jde for fra starten.<\/p>\n\n<h2>Praktiske l\u00f8sninger til typiske arbejdsbelastninger<\/h2>\n\n<ul>\n  <li>OLTP med mange sm\u00e5 commits p\u00e5 SSD\/NVMe: O_DIRECT, innodb_flush_log_at_trx_commit=1 eller 2 afh\u00e6ngigt af holdbarheden, innodb_io_capacity helst h\u00f8jt, Dirty-Pages moderat, Flush-Neighbors=0. Brug aktivt Binlog-Group-Commit.<\/li>\n  <li>Batch-import med stor skrivebelastning: \u00d8g midlertidigt m\u00e5let for \u00bbdirty pages\u00ab en smule, for\u00f8g I\/O-kapaciteten og s\u00e6t indstillingen tilbage efter afslutning. Hvis holdbarheden er acceptabel, kan du midlertidigt indstille innodb_flush_log_at_trx_commit=2.<\/li>\n  <li>HDD-baserede \u00e6ldre systemer: konservativ I\/O-kapacitet, Flush-Neighbors=1, innodb_flush_method=fsync eller O_DIRECT afh\u00e6ngigt af RAM-belastningen. Der skal l\u00e6gges s\u00e6rlig v\u00e6gt p\u00e5 kontinuerlig flushing for at undg\u00e5 s\u00f8gestorm.<\/li>\n  <li>Cloud-volumener med IOPS-budget: Indstil `innodb_io_capacity` s\u00e5 den n\u00f8je overholder den garanterede gr\u00e6nse, undg\u00e5 bursts, og brug `O_DIRECT` for at spare p\u00e5 RAM. Ved kreditsystemer (burst-I\/O) bruger jeg pacing, s\u00e5 budgettet ikke opbruges p\u00e5 \u00e9n gang.<\/li>\n<\/ul>\n\n<h2>Tjekliste til fejlfinding<\/h2>\n\n<ul>\n  <li>Lange p95-commit-forsinkelser? Kontroller fsync-varigheden, aktiver Group Commit, reducer om n\u00f8dvendigt flush-frekvensen (efter en risikovurdering).<\/li>\n  <li>Stor variation i andelen af \u00bbDirty Pages\u00ab? Finjuster io_capacity\/io_capacity_max, og kontroller de adaptive flushing-t\u00e6rskler.<\/li>\n  <li>Pludselige latensspidser ved sikkerhedskopiering? Synkroniser parametrene for sikkerhedskopieringsv\u00e6rkt\u00f8jet og serverv\u00e6rdierne, og juster I\/O-begr\u00e6nsningen midlertidigt.<\/li>\n  <li>H\u00e6nger Replica bagefter? Vurder Binlog-flush-strategien, synkroniseringsfrekvenserne og netv\u00e6rksforsinkelsen samlet; for aggressive synkroniseringer bremser masteren.<\/li>\n  <li>RAM-belastning efter overgang til O_DIRECT? Juster balancen mellem bufferpoolen og OS-cachen p\u00e5 ny; O_DIRECT reducerer OS-cachen, men kan p\u00e5virke applikationens sidecache.<\/li>\n<\/ul>\n\n<h2>Kort resum\u00e9<\/h2>\n\n<p>Jeg organiserer <strong>Flush-strategi<\/strong> altid afh\u00e6nger af hardwaren og holdbarhedsm\u00e5lene. O_DIRECT forhindrer dobbeltcaching og giver som regel de bedste resultater p\u00e5 SSD\/NVMe. Indstillingen innodb_flush_log_at_trx_commit bestemmer hastigheden pr. commit og risikoen ved str\u00f8msvigt. Omhyggeligt valgte v\u00e6rdier for Dirty Pages, I\/O-kapacitet og Flush-Neighbors holder skrivehastighederne j\u00e6vne. Hvis man derudover m\u00e5ler fsync-omkostninger og overholder cloud-begr\u00e6nsninger, kan man p\u00e5lideligt f\u00e5 MariaDB op p\u00e5 fuld hastighed uden at g\u00e5 p\u00e5 kompromis med sikkerheden.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan du optimalt konfigurerer MariaDB-flush-metoder og `innodb_flush` med `O_DIRECT`, `fsync` og `innodb_flush_log_at_trx_commit`. Vejledningen viser dig praktisk databaseoptimering til HDD-, SSD- og cloud-milj\u00f8er med fokus p\u00e5 ydeevne og datasikkerhed.<\/p>","protected":false},"author":1,"featured_media":21532,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21539","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":"62","_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":"MariaDB Flush","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":"21532","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21539","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=21539"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21539\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21532"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21539"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21539"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21539"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}