{"id":21026,"date":"2026-08-26T15:05:23","date_gmt":"2026-08-26T13:05:23","guid":{"rendered":"https:\/\/webhosting.de\/linux-transparent-page-cache-page-cache-unterschiede-optimierung-datencache\/"},"modified":"2026-08-26T15:05:23","modified_gmt":"2026-08-26T13:05:23","slug":"linux-transparent-sidecache-forskelle-mellem-sidecache-optimering-datacache","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/linux-transparent-page-cache-page-cache-unterschiede-optimierung-datencache\/","title":{"rendered":"Linux Transparent Page Cache: Grundl\u00e6ggende principper og forskelle i forhold til den klassiske page-cache"},"content":{"rendered":"<p>I to s\u00e6tninger vil jeg vise, hvordan Linux fremskynder filadgangen i RAM, og hvordan en <strong>transparent sidecache<\/strong> bruger st\u00f8rre sideenheder for at reducere administrationsbyrden. Desuden forklarer jeg forskellene i forhold til den klassiske sidecache med 4-KiB-sider, samt virkningen p\u00e5 TLB, fragmentering og arbejdsbelastningsadf\u00e6rd.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>Sidest\u00f8rrelse<\/strong>: 4 KiB kontra 2 MiB p\u00e5virker granulariteten og effektiviteten.<\/li>\n  <li><strong>TLB-tryk<\/strong>: Store sider reducerer antallet af indl\u00e6g, sm\u00e5 sider forbliver fleksible.<\/li>\n  <li><strong>Fragmentering<\/strong>: Store sider kr\u00e6ver sammenh\u00e6ngende RAM.<\/li>\n  <li><strong>Arbejdsbyrder<\/strong>: Sekventielt har stor fordel, tilf\u00e6ldigt har mindre.<\/li>\n  <li><strong>Kontrol<\/strong>: Test, m\u00e5l, og konfigurer derefter trin for trin.<\/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\/08\/linux-serverraum-8473.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad er den klassiske Linux-sidecache?<\/h2>\n\n<p>Den klassiske sidecache gemmer ofte anvendte filsider i arbejdsminnet, s\u00e5 l\u00e6seadgang sker direkte fra <strong>RAM<\/strong> foreg\u00e5r. Den arbejder typisk med 4-KiB-sider og administrerer hver side som en selvst\u00e6ndig enhed i cachen. Dermed forbliver mange sm\u00e5 filer eller hyppigt anmodede dele af store filer tilg\u00e6ngelige uden at belaste SSD\u2019en eller HDD\u2019en. Kernel prioriterer aktive sider, kasserer sj\u00e6ldent anvendt indhold og reagerer dermed dynamisk p\u00e5 belastningsspidser. For mere dybdeg\u00e5ende baggrundsinformation henviser jeg til en kortfattet introduktion til <a href=\"https:\/\/webhosting.de\/da\/ydelsesforbedring-af-linux-sidecachen\/\">Side-cache-ydeevne<\/a>, der beskriver det grundl\u00e6ggende princip p\u00e5 en praktisk m\u00e5de.<\/p>\n\n<h2>Hvorfor en transparent sidecache?<\/h2>\n\n<p>Mange enkelte 4-KiB-sider medf\u00f8rer administrativt arbejde og \u00f8get pres p\u00e5 <strong>TLB<\/strong>. St\u00f8rre sider p\u00e5 f.eks. 2 MiB kan d\u00e6kke det samme adresserum med f\u00e6rre poster og dermed spare CPU-tid. En transparent sidecache samler automatisk fil-sider til st\u00f8rre enheder, n\u00e5r adgangs-m\u00f8nstre og hukommelsesplacering tillader det. Dette ligner ideen bag Transparent Huge Pages, men henviser her til filbaseret cache i stedet for anonym hukommelse. Jeg tager f\u00f8rst s\u00e5danne funktioner i brug, n\u00e5r jeg har forst\u00e5et adgangsmodeller, fragmentering og latenstidskrav, da st\u00f8rre sider \u00f8ger granulariteten.<\/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\/08\/LinuxPageCacheMeeting4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Systematisk sammenligning af forskelle<\/h2>\n\n<p>For at give et klart overblik har jeg samlet de vigtigste kendetegn ved klassisk cache, transparent sidecache og THP side om side, s\u00e5 valget kan tr\u00e6ffes ud fra <strong>Arbejdsbyrde<\/strong> er lettere. Fokus ligger p\u00e5 sidest\u00f8rrelse, TLB, fragmentering, fordele og risici. Tabellen viser styrker og begr\u00e6nsninger uden marketingfloskler. Jeg l\u00e6ser den fra venstre mod h\u00f8jre og vurderer, hvilken kolonne der passer bedst til belastningen. Derefter beslutter jeg, om jeg holder fast i 4-KiB-cachen eller tester st\u00f8rre sider.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Funktion<\/th>\n      <th>Klassisk sidecache (4 KiB)<\/th>\n      <th>Transparent sidecache (f.eks. 2 MiB)<\/th>\n      <th>THP (anonym hukommelse)<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Sidest\u00f8rrelse\/granularitet<\/td>\n      <td>Pr\u00e6cis og n\u00f8jagtig caching<\/td>\n      <td>Groft sagt, meget store omr\u00e5der<\/td>\n      <td>Grovt, store bunker\/stakke<\/td>\n    <\/tr>\n    <tr>\n      <td>TLB-tryk<\/td>\n      <td>H\u00f8jere takket v\u00e6re mange indl\u00e6g<\/td>\n      <td>Lavere, f\u00e6rre poster<\/td>\n      <td>Lavere, f\u00e6rre poster<\/td>\n    <\/tr>\n    <tr>\n      <td>Administrative udgifter<\/td>\n      <td>H\u00f8jt p\u00e5 mange sider<\/td>\n      <td>F\u00e6rre metadata<\/td>\n      <td>F\u00e6rre metadata<\/td>\n    <\/tr>\n    <tr>\n      <td>Fragmentering<\/td>\n      <td>Ikke-kritisk, kr\u00e6ver ingen sammenh\u00e6ng<\/td>\n      <td>Kr\u00e6ver sammenh\u00e6ngende RAM<\/td>\n      <td>Kr\u00e6ver sammenh\u00e6ngende RAM<\/td>\n    <\/tr>\n    <tr>\n      <td>Egnede laster<\/td>\n      <td>Sm\u00e5 filer, tilf\u00e6ldige adgangsh\u00e6ndelser<\/td>\n      <td>Store filer, sekventielle m\u00f8nstre<\/td>\n      <td>Store heaps, databaser i RAM<\/td>\n    <\/tr>\n    <tr>\n      <td>Risici<\/td>\n      <td>St\u00f8rre TLB- og CPU-overhead<\/td>\n      <td>Overfetch, latenstip ved split\/merge<\/td>\n      <td>Overfetch, latenstip ved split\/merge<\/td>\n    <\/tr>\n    <tr>\n      <td>Kernel-\/feature-afh\u00e6ngighed<\/td>\n      <td>Bredt tilg\u00e6ngelig<\/td>\n      <td>V\u00e6r opm\u00e6rksom p\u00e5 version\/implementering<\/td>\n      <td>Kontroller distributionsindstillingerne<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Tabellen er ikke en erstatning for en test, den giver struktur til min <strong>Beslutning<\/strong>. F\u00f8rst vurderer jeg adgangs m\u00f8nstre og filst\u00f8rrelse. Derefter m\u00e5ler jeg latenstid, CPU-tid og cache-hitrate med og uden store sider. Hvis benchmark-resultaterne viser klare fordele uden afvigelser, skalerer jeg forsigtigt op. Hvis der opst\u00e5r spidsbelastninger, ruller jeg tilbage eller begr\u00e6nser brugen.<\/p>\n\n<h2>Hvordan kernen opretter store fil-sider<\/h2>\n\n<p>For at der kan dannes st\u00f8rre sideenheder i sidecachen, har kernen brug for sammenh\u00e6ngende filomr\u00e5der i hukommelsen og en tilstr\u00e6kkelig sammenh\u00e6ngende adgang. Et typisk eksempel er en \u00bbpromotion\u00ab: Flere sider p\u00e5 4 KiB samles til et st\u00f8rre \u00bbfolio\u00ab. Omvendt sker der ved uhensigtsm\u00e6ssige m\u00f8nstre en opdeling tilbage til mindre enheder. Jeg observerer is\u00e6r disse overgange under belastning, fordi opgradering og opdeling kortvarigt belaster CPU\u2019en og opdaterer LRU-listerne. Sekventielle l\u00e6sere fremmer opgradering, mens st\u00e6rkt spredte arbejdsbelastninger snarere fremprovokerer opdelinger.<\/p>\n\n<p>Readahead spiller her en afg\u00f8rende rolle: Hvis der l\u00e6ses tilstr\u00e6kkeligt mange data p\u00e5 forh\u00e5nd, og disse data efterf\u00f8lgende rent faktisk bruges, opst\u00e5r der store folioer n\u00e6rmest som en sidegevinst. Hvis applikationer derimod henter data i sm\u00e5, uforudsigelige trin, forbliver cachen granul\u00e6r. Ogs\u00e5 <strong>Writeback<\/strong> interagerer med store sider: Hvis mange sammenh\u00e6ngende \u00bbdirty pages\u00ab skrives tilbage p\u00e5 samme tid, kan det gavne gennemstr\u00f8mningen og IOPS, men burst-st\u00f8rrelserne stiger. Derfor tager jeg h\u00f8jde for \u00bbdirty tuning\u00ab-parametrene (f.eks. <code>vm.dirty_background_bytes<\/code> og <code>vm.dirty_bytes<\/code>), for at undg\u00e5 for store flush-b\u00f8lger.<\/p>\n\n<h2>Filsystemer, I\/O-stier og deres indflydelse<\/h2>\n\n<p>Bufferet I\/O drager direkte fordel af sidecachen, Direct I\/O (<code>O_DIRECT<\/code>) p\u00e5virker det ham stort set ikke. For databaser eller backup-v\u00e6rkt\u00f8jer, der bevidst bruger Direct I\/O, har en transparent sidecache derfor mindre betydning. Ved <code>mmap()<\/code> afh\u00e6nger effekten af adgangsm\u00f8nsteret: sidevis, fremadg\u00e5ende scanninger udnytter st\u00f8rre folioer godt; tilf\u00e6ldige spring g\u00f8r det ikke. Med <code>posix_fadvise()<\/code> kan jeg give kernelen instruktioner (f.eks. <code>SEKVENTIEL<\/code>, <code>WILLNEED<\/code>, <code>RANDOM<\/code>), der styrer readahead og fortr\u00e6ngning. S\u00e5danne hints er ingen garantier, men de \u00f8ger chancerne for, at cachen passer til min arbejdsbyrde.<\/p>\n\n<p>Filsystemer har deres egne heuristiske mekanismer. P\u00e5 nogle systemer reagerer ext4 og XFS meget fornuftigt p\u00e5 sekventielle datastr\u00f8mme, mens Copy-on-Write-filsystemer med deduplikering eller komprimering (f.eks. tr\u00e6strukturer med mange \u00f8jebliksbilleder) udviser andre k\u00f8rselsprofiler. Jeg unders\u00f8ger derfor, om filsystemets layout og fragmentering tillader store sammenh\u00e6ngende omr\u00e5der. En defragmentering af st\u00e6rkt fragmenterede data kan give m\u00e5lbare fordele, men skal altid planl\u00e6gges med forsigtighed og inden for vedligeholdelsesvinduer.<\/p>\n\n<h2>Hardwarefaktorer: arkitektur, NUMA og enheder<\/h2>\n\n<p>Ikke alle arkitekturer bruger 4 KiB som basisside. P\u00e5 systemer med st\u00f8rre basissider \u00e6ndres granulariteten og TLB-adf\u00e6rden allerede som standard. Dette forskydes fordelene ved store folioer i cachen. Derudover tager jeg h\u00f8jde for NUMA-topologier: Store sider fungerer bedst, n\u00e5r de er placeret lokalt i forhold til den CPU, der k\u00f8rer I\/O-tr\u00e5den eller applikationen. Derfor knytter jeg arbejdsprocesser til noder, overv\u00e5ger pro-NUMA-statistikker og forhindrer un\u00f8dvendige fjernadgange. Under Linux hj\u00e6lper node-specifikke m\u00e5linger mig med (<code>\/sys\/devices\/system\/node\/node*\/meminfo<\/code>) og scheduler-pinning for at bevare lokaliteten.<\/p>\n\n<p>P\u00e5 enhedssiden ser jeg p\u00e5 controller-k\u00f8er, NVMe-dybde og latenstidskurven. Store sider fungerer godt med h\u00f8j gennemstr\u00f8mning og stabil latenstid, men er f\u00f8lsomme over for spidsbelastninger i halen af latenstiden. En I\/O-scheduler, der udj\u00e6vner burst-belastninger, kan g\u00f8re en forskel her. Readahead-v\u00e6rdier (<code>blockdev --getra\/--setra<\/code>) kalibrerer jeg omhyggeligt for hver enkelt enhed og arbejdsbelastning.<\/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\/08\/linux-page-cache-differences-3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>M\u00e5lemetodik, KPI'er og observerbarhed<\/h2>\n\n<p>Jeg definerer p\u00e5 forh\u00e5nd nogle f\u00e5, men sigende n\u00f8gletal: Page-Fault-rate, cache-hitrate, CPU-tid pr. foresp\u00f8rgsel, TLB-belastning, readahead-hits, latenstidspercentiler (P50\/P95\/P99) og I\/O-fejltilgange. Til systemoversigten bruger jeg <code>vmstat<\/code>, <code>sar -B<\/code>, <code>iostat<\/code> og <code>pidstat<\/code>, for at identificere tendenser. <code>\/proc\/meminfo<\/code> og <code>smaps<\/code> hj\u00e6lper med at afd\u00e6kke, hvad der aktivt ligger i arbejdshukommelsen; <code>Slabtop<\/code> viser metadata-overhead. Hvis det er n\u00f8dvendigt, m\u00e5ler jeg med <code>perf<\/code> TLB-fejl og CPU-cyklusser under reel belastning for at synligg\u00f8re effekten af store sider.<\/p>\n\n<p>For mig best\u00e5r en testk\u00f8rsel af tre faser: Opvarmning indtil en stabil hitrate, m\u00e5leinterval under kontrolleret belastning, nedk\u00f8ling for at observere eviction og writeback. Jeg gentager k\u00f8rsler med identisk datas\u00e6t og skiftende parametre (f.eks. readahead, THP-tilstand <code>altid\/nogle gange\/aldrig<\/code>), for at f\u00e5 p\u00e5lidelige resultater. Jeg ser ikke gennem fingre med afvigelser: Hvis P99 bliver d\u00e5rligere, selvom gennemsnittet falder, passer ops\u00e6tningen som regel ikke til mit m\u00e5leinterval.<\/p>\n\n<h2>Typiske m\u00f8nstre i praksis<\/h2>\n\n<p>Streaming og mediearbejdsbelastninger l\u00e6ser store filer hovedsageligt fremad. Her udm\u00e6rker store folioer sig ofte, fordi TLB-belastningen og administrationsomkostningerne falder. Backup\/gendannelse og replikering med lange, sekventielle blokke viser lignende fordele, is\u00e6r n\u00e5r flere processer l\u00e6ser de samme omr\u00e5der. Machine learning-pipelines drager fordel af, at datas\u00e6t samles og opbevares; st\u00e6rkt tilf\u00e6ldig udtr\u00e6kning fra mange sm\u00e5 filer d\u00e6mper dog effekten, medmindre man p\u00e5 forh\u00e5nd skifter til containerformater med sammenh\u00e6ngende blokke.<\/p>\n\n<p>Build- og CI-milj\u00f8er med tusindvis af sm\u00e5 filer fungerer som regel bedre med en granularitet p\u00e5 4 KiB. Her er det afg\u00f8rende, at ofte anvendte fragmenter er hurtigt og pr\u00e6cist tilg\u00e6ngelige. Her investerer jeg i en h\u00f8j andel af RAM til Active(file), fornuftig readahead pr. enhed og eventuelt i applikationsn\u00e6re cacher (f.eks. afh\u00e6ngighedscacher) i stedet for at tvinge store sider igennem i kernen.<\/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\/08\/linux_page_cache_tech_4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ressourcestyring: Cgroups og beskyttelse af arbejdsm\u00e6ngden<\/h2>\n\n<p>I multi-tenant-milj\u00f8er begr\u00e6nser og beskytter jeg lagerpladsen pr. tjeneste. Med cgroup v2 kan man n\u00f8jagtigt afgr\u00e6nse processer, der belaster pagecache, og om n\u00f8dvendigt via <code>hukommelse.lav<\/code> beskytte, s\u00e5 vigtige arbejdss\u00e6t sj\u00e6ldnere fortr\u00e6nges. <code>hukommelse.h\u00f8j<\/code> fasts\u00e6tter fleksible \u00f8vre gr\u00e6nser, <code>hukommelse.max<\/code> Strenge gr\u00e6nser. Jeg observerer, hvordan fairness og eviction fungerer, n\u00e5r flere tjenester deler den samme host-cache. Store sider kan her v\u00e6re med til at aflaste CPU\u2019en, men kan ogs\u00e5 f\u00f8re til st\u00f8rre fortr\u00e6ngningsblokke. Derfor justerer jeg beskyttelsesgr\u00e6nserne i sm\u00e5 trin og overv\u00e5ger LRU-dynamikken.<\/p>\n\n<h2>Fejltegn og afhj\u00e6lpende foranstaltninger<\/h2>\n\n<p>N\u00e5r promotion og split forekommer hyppigt, ser jeg svingende latenstid, h\u00f8j kernel-CPU-udnyttelse og varierende hitrate. L\u00f8sning: Juster readahead, undg\u00e5 split-kaskader, adskil arbejdsbelastninger eller reducer aggressiviteten ved store sider. Ved tegn p\u00e5 overfetch (meget i cachen, stigende swap-pres, faldende hitrate for sm\u00e5 hotsets) skifter jeg til en finere granularitet eller isolerer store l\u00e6sere p\u00e5 dedikerede noder. Hvis writeback-bursts \u00f8ger tail-latensen, indstiller jeg strengere gr\u00e6nser for dirty bytes og udj\u00e6vner flush-intervallerne.<\/p>\n\n<p>NUMA-jitter l\u00f8ser jeg ved hj\u00e6lp af CPU\/hukommelses-pinning og en korrekt placering af I\/O-tr\u00e5dene. Hvis der opst\u00e5r TLB-misses, men applikationen fortsat er langsom, unders\u00f8ger jeg lock-contention, filsysteml\u00e5se og effekten af komprimering\/dekryptering i stakken. En ydelsesforbedring ved hj\u00e6lp af store sider er kun en reel succes, hvis den viser sig i applikationens slutpunkt.<\/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\/08\/linux_pagecache_schreibtisch4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktisk tidsplan for pr\u00f8ver<\/h2>\n\n<p>Jeg starter med en baseline: den aktuelle kerne, THP-status (<code>\/sys\/kernel\/mm\/transparent_hugepage\/<\/code>), readahead-v\u00e6rdier, I\/O-scheduler, fil- og disklayout. Derefter definerer jeg to til tre konkrete hypoteser (f.eks. \u201esekventielle mediestreams: -10% CPU, mere stabil P99\u201c). Derefter fastl\u00e6gger jeg faste datas\u00e6t og belastningsprofiler, der afspejler realistiske trafikm\u00f8nstre. Hver testserie har identiske opvarmningstider, identisk varighed og identisk m\u00e5ling af n\u00f8gletal.<\/p>\n\n<p>Jeg \u00e6ndrer kun \u00e9n parameter ad gangen: f\u00f8rst readahead, derefter aggressiviteten ved store sider og til sidst LRU\/Dirty-indstillingerne. Efter hvert trin gemmer jeg m\u00e5linger og noter, s\u00e5 senere kerneopdateringer forbliver sammenlignelige. F\u00f8rst n\u00e5r to uafh\u00e6ngige k\u00f8rsler viser den samme tendens, og P95\/P99-latenserne er stabile, overf\u00f8rer jeg \u00e6ndringen til en begr\u00e6nset produktionsgruppe. En rollback-plan med klare t\u00e6rskelv\u00e6rdier (f.eks. \u201eP99 &gt; +15% i 5 minutter\u201c) er altid en del af processen.<\/p>\n\n<h2>Adgangsm\u00f8nstre og f\u00f8lsomhed<\/h2>\n\n<p>Sekventielle l\u00e6sere, der arbejder med store filer, drager oftere fordel af st\u00f8rre <strong>Sider<\/strong>. Tilf\u00e6ldige adgange til mange sm\u00e5 filer fungerer som regel bedre med 4 KiB, fordi cachen s\u00e5 kun opbevarer de n\u00f8dvendige fragmenter. Blandede belastninger kr\u00e6ver m\u00e5linger med realistiske datas\u00e6t, da syntetiske tests ofte giver for optimistiske resultater. Jeg holder \u00f8je med, om overfetch binder hukommelse, som ellers mangler andre steder. En lille gevinst i CPU-tid er ikke det v\u00e6rd, hvis det medf\u00f8rer \u00f8get LRU-pres og stigende latenstider.<\/p>\n\n<h2>Webhosting-scenarier med mange sm\u00e5 filer<\/h2>\n\n<p>Typisk shared hosting h\u00e5ndterer et utal af sm\u00e5 scripts, billeder og ressourcer, som 4-KiB-cachen nemt kan rumme i <strong>H\u00e5ndtag<\/strong> har. Store sider giver sj\u00e6ldent nogen merv\u00e6rdi her, da filerne ofte er mindre end 2 MiB eller kun bruges sporadisk. I stedet investerer jeg i tilstr\u00e6kkelig RAM, fornuftig readahead pr. enhed og cacher p\u00e5 applikationsniveau s\u00e5som OPCache. Derudover unders\u00f8ger jeg, om statiske ressourcer hentes hurtigere via en HTTP-cache end fra blokenheden. F\u00f8rst n\u00e5r belastningsprofiler viser st\u00f8rre filer, \u00e5bner jeg d\u00f8ren for st\u00f8rre sidecache-sider.<\/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\/08\/linux-page-cache-differences-3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Databaser, cacher og logfiler<\/h2>\n\n<p>In-memory-databaser og store heaps drager ofte fordel af THP i den anonyme <strong>Hukommelse<\/strong>. Ved filbaserede motorer og log-pipelines med lange, sekventielle l\u00e6sninger kan en transparent sidecache ligeledes v\u00e6re en fordel. Jeg tester p\u00e5 en reproducerbar m\u00e5de, om sidefejl falder, og om CPU\u2019en k\u00f8rer mere j\u00e6vnt. Samtidig observerer jeg, om overfetch \u00f8ger den brugte RAM og \u00e6ndrer opstartstiderne. En kort indledning hj\u00e6lper med at komme i gang: Jeg bruger denne vejledning til at <a href=\"https:\/\/webhosting.de\/da\/transparente-huge-pages-ydeevneforbedring-eller-optimeringsproblem-i-linux\/\">Vurdering af THP<\/a> og at vurdere sammenh\u00e6ngene korrekt.<\/p>\n\n<h2>Virtualisering og containere<\/h2>\n\n<p>Flere virtuelle maskiner eller containere deler v\u00e6rtskernel og dermed <strong>Side<\/strong>-Cache. Ofte anvendte bin\u00e6re filer og biblioteker leveres derefter til alle instanser fra den samme cache, hvilket sparer I\/O. THP i g\u00e6sten kan mindske belastningen p\u00e5 CPU\u2019en, men kr\u00e6ver, at der tages h\u00f8jde for NUMA-zoner og overcommit. Jeg m\u00e5ler pr. NUMA-node, s\u00e5 store sider ikke vandrer p\u00e5 tv\u00e6rs af systemet. Hvis der opst\u00e5r jitter under belastning, s\u00e6nker jeg aggressiviteten (madvise) eller deaktiverer THP selektivt, indtil kurverne igen er j\u00e6vne.<\/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\/08\/linux_page_cache_tech_4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kontroller konfigurationen og indstil den hensigtsm\u00e6ssigt<\/h2>\n\n<p>Jeg begynder med en n\u00f8gtern <strong>Inventar<\/strong>: Hvilken kerneversion, hvilke standardindstillinger, hvilke mount-indstillinger, hvilke readahead-v\u00e6rdier? Jeg tjekker THP\u2019s status under \/sys\/kernel\/mm\/transparent_hugepage\/ (f.eks. enabled, defrag, khugepaged). For at se page-cache-adf\u00e6rd kigger jeg p\u00e5 \/proc\/meminfo, per-node-statistikker og blokvis readahead. Jeg implementerer aldrig \u00e6ndringer blindt, men tester dem f\u00f8rst p\u00e5 en staging-milj\u00f8 med reelle data. F\u00f8rst derefter overf\u00f8rer jeg stabile ops\u00e6tninger til produktionsmilj\u00f8et.<\/p>\n\n<h2>Finjustering: Readahead, eviction og overv\u00e5gning<\/h2>\n\n<p>Store sider fungerer kun, hvis readahead, I\/O-scheduler og LRU fungerer godt <strong>sammen<\/strong>k\u00f8re. Jeg holder \u00f8je med page-fault-rate, misses, CPU-tid og eventuelle latenstops ved split\/merge af store sider. Under belastning er jeg interesseret i, hvor hurtigt cachen fortr\u00e6nger gamle sider, og om vigtige filer falder ud. Et godt udgangspunkt for at se n\u00e6rmere p\u00e5 fortr\u00e6ngning er dette indl\u00e6g om <a href=\"https:\/\/webhosting.de\/da\/server-page-cache-eviction-linux-memory-print-optimisation-insight\/\">Uds\u00e6ttelse under pres fra Memory<\/a>, der forklarer det typiske m\u00f8nster. Derefter justerer jeg forsigtigt readahead, filsystemindstillingerne og eventuelt brugen af store sider.<\/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\/08\/linux_pagecache_schreibtisch4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Tjekliste til praksis uden myter<\/h2>\n\n<p>Jeg starter med klare m\u00e5l: mindre CPU-tid, lavere latenstid, passende <strong>Tr\u00e6fprocent<\/strong> i sidecachen. Derefter definerer jeg m\u00e5lepunkter og v\u00e6lger reelle arbejdsbelastninger, der viser spidsbelastninger og blandede belastninger. Herefter tester jeg gradvist st\u00f8rre sider, f\u00f8rst p\u00e5 staging-milj\u00f8et og derefter i begr\u00e6nset omfang i produktionsmilj\u00f8et. Jeg har rollback-planer klar, hvis der opst\u00e5r overfetch, fragmentering eller jitter. Til sidst dokumenterer jeg resultaterne, s\u00e5 ops\u00e6tningen forbliver reproducerbar, og s\u00e5 senere kernelopdateringer kan evalueres.<\/p>\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Den klassiske 4-KiB-cache er stadig den p\u00e5lidelige l\u00f8sning for mange applikationer <strong>Basis<\/strong>, fordi den er detaljeret og bruger RAM sparsomt. En transparent sidecache reducerer TLB-belastningen og metadata, n\u00e5r store filer l\u00e6ses sekventielt. THP adresserer anonyme hukommelsesomr\u00e5der og kan hj\u00e6lpe store heaps, men kr\u00e6ver omhyggelighed p\u00e5 grund af mulige latensspidser. Jeg tr\u00e6ffer beslutningen p\u00e5 baggrund af data: m\u00e5le, sammenligne og derefter implementere. Hvis man g\u00e5r s\u00e5dan til v\u00e6rks, opn\u00e5r man forudsigelige responstider, fornuftig RAM-udnyttelse og en m\u00e6rkbart mere rolig CPU.<\/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\/08\/linux-page-cache-setup-5726.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan Linux\u2019 transparente sidecache fungerer, hvad forskellene er i forhold til den klassiske sidecache, og hvordan du optimerer din hukommelsesstyring for at opn\u00e5 maksimal ydeevne. Fokus: transparent sidecache.<\/p>","protected":false},"author":1,"featured_media":21019,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21026","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"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":"115","_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":"transparent page cache","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":"21019","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21026","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=21026"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21026\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21019"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21026"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21026"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21026"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}