{"id":20540,"date":"2026-08-11T11:56:13","date_gmt":"2026-08-11T09:56:13","guid":{"rendered":"https:\/\/webhosting.de\/linux-page-cache-performance-booster\/"},"modified":"2026-08-11T11:56:13","modified_gmt":"2026-08-11T09:56:13","slug":"prestandafoerbaettrare-foer-linux-sidcache","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/linux-page-cache-performance-booster\/","title":{"rendered":"Att f\u00f6rst\u00e5 Linux sidcache: B\u00e4ttre prestanda tack vare cachen"},"content":{"rendered":"<p><strong>Linux-sidan<\/strong> Jag ser cacheminnet som ett direkt verktyg f\u00f6r snabbare fil\u00e5tkomst, eftersom det hanterar upprepade l\u00e4sningar fr\u00e5n RAM-minnet ist\u00e4llet f\u00f6r fr\u00e5n l\u00e5ngsammare lagringsenheter. Jag visar konkret hur k\u00e4rnan d\u00e4rigenom minskar f\u00f6rdr\u00f6jningarna, p\u00e5skyndar arbetsbelastningar som webbservrar, databaser och WordPress, och hur jag utnyttjar effekten med enkla medel.<\/p>\n\n<h2>Centrala punkter<\/h2>\n\n<p>F\u00f6ljande huvudbudskap hj\u00e4lper mig att <strong>Cache f\u00f6r sidor<\/strong> att bed\u00f6ma och utnyttja p\u00e5 ett m\u00e5linriktat s\u00e4tt.<\/p>\n<ul>\n  <li><strong>RAM-cache<\/strong>: Filuppgifterna lagras i minnet och f\u00f6rkortar \u00e5tkomsttiderna.<\/li>\n  <li><strong>\u00c5terf\u00f6ring<\/strong>: Skrivoperationer grupperas mer effektivt som \u201edirty pages\u201c.<\/li>\n  <li><strong>\u00d6ppenhet<\/strong>: Applikationerna drar nytta av detta utan att koden beh\u00f6ver \u00e4ndras.<\/li>\n  <li><strong>Dynamik<\/strong>: Cachen frig\u00f6r minnesutrymme vid behov.<\/li>\n  <li><strong>Arbetsbelastning<\/strong>: Webb, databaser, CI\/CD och loggar vinner m\u00e4rkbart.<\/li>\n<\/ul>\n\n<h2>Vad \u00e4r Linux Page Cache?<\/h2>\n\n<p>Jag f\u00f6rst\u00e5r det <strong>Cache f\u00f6r sidor<\/strong> som ett lagringsomr\u00e5de i RAM-minnet d\u00e4r k\u00e4rnan lagrar filblock s\u00e5 snart processer via <code>read()<\/code>, <code>write()<\/code> eller . <code>mmap()<\/code> komma \u00e5t filer. Vid varje \u00e5tkomst kontrollerar k\u00e4rnan f\u00f6rst cachen och levererar omedelbart data fr\u00e5n minnet om de redan finns d\u00e4r, vilket m\u00e4tbart minskar svarstiden. Om data inte finns i cachen laddar k\u00e4rnan dem fr\u00e5n lagringsmediet, lagrar dem d\u00e4r och g\u00f6r dem tillg\u00e4ngliga f\u00f6r processen, vilket resulterar i en snabb tr\u00e4ff vid n\u00e4sta \u00e5tkomst. Denna mekanism \u00e4r n\u00e4ra kopplad till det virtuella filsystemet och fungerar transparent f\u00f6r applikationerna, vilket g\u00f6r den universellt anv\u00e4ndbar. Av detta arbetss\u00e4tt f\u00f6ljer en enkel princip: Jag anv\u00e4nder ledigt RAM-minne som <strong>Cache-yta<\/strong> ist\u00e4llet f\u00f6r att l\u00e5ta den ligga oanv\u00e4nd.<\/p>\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-page-cache-performance-5830.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Varf\u00f6r sidcachen ger en m\u00e4rkbar hastighets\u00f6kning<\/h2>\n\n<p>Den st\u00f6rsta effekten uppst\u00e5r eftersom jag <strong>Disk-I\/O<\/strong> minskar drastiskt s\u00e5 snart \u00e5terkommande data finns i cachen och inte beh\u00f6ver l\u00e4sas in fr\u00e5n lagringsmediet p\u00e5 nytt. L\u00e4s\u00e5tkomst sker d\u00e5 fr\u00e5n RAM-minnet, vilket avsev\u00e4rt minskar latenser och k\u00f6er vid styrenheterna. \u00c4ven skrivoperationer gynnas, eftersom k\u00e4rnan markerar \u00e4ndringar som \u201edirty pages\u201c, samlar ihop dem \u00f6ver tid och senare skriver dem effektivt till lagringsmediet. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rsvinner m\u00e5nga sm\u00e5 enskilda \u00e5tkomstf\u00f6rfr\u00e5gningar, som annars skulle belasta lagringsenheten, till f\u00f6rm\u00e5n f\u00f6r f\u00e4rre, st\u00f6rre operationer. Sammantaget k\u00e4nns ett system snabbare efter en kort uppv\u00e4rmningsfas, eftersom mer arbetsdata finns i <strong>Minne<\/strong> kvar.<\/p>\n\n<h2>L\u00e4sning, skrivande, \u201dDirty Pages\u201d: s\u00e5 g\u00e5r det till<\/h2>\n\n<p>En l\u00e4s\u00e5tkomst inleds alltid med en cachekontroll, vilket inneb\u00e4r att tr\u00e4ffar sker utan v\u00e4ntetid och att missar endast kostar en g\u00e5ng. Vid skrivning hamnar det \u00e4ndrade inneh\u00e5llet f\u00f6rst i RAM-minnet och placeras i v\u00e4ntel\u00e4ge som \u201edirty\u201c tills k\u00e4rnan \u00f6verf\u00f6r det samlat till lagringsmediet. Om s\u00e5 \u00f6nskas tvingar jag fram en permanent lagring med <code>fsync()<\/code>, vilket \u00e4r viktigt n\u00e4r det g\u00e4ller data <strong>Samst\u00e4mmighet<\/strong> beh\u00f6ver omedelbart. Denna write-back-v\u00e4g \u00f6kar effektiviteten hos applikationer som hanterar m\u00e5nga sm\u00e5 filer, till exempel PHP-kod, konfigurationsfiler eller tillg\u00e5ngar. Samtidigt \u00e4r jag medveten om att write-back ger b\u00e4ttre prestanda, men att det finns en kort tidsperiod d\u00e5 inte allt \u00e4nnu \u00e4r fysiskt sparat.<\/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_3892.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ledigt RAM-minne \u00e4r cache \u2013 ingen f\u00f6rlust<\/h2>\n\n<p>M\u00e5nga \u00e4r skeptiska till \u201eupptagna\u201c lagringsutrymmen, men jag tolkar v\u00e4rdet korrekt genom att betrakta andelen \u201ebuff\/cache\u201c som en meningsfull <strong>mellanlagring<\/strong> v\u00e4rden. K\u00e4rnan utnyttjar aktivt outnyttjat RAM-minne, \u00e5terl\u00e4mnar det blixtsnabbt till processer vid behov och styr balansen via \u00e5tervinningsmekanismer. Denna dynamik ser till att mitt system reagerar snabbt s\u00e5 l\u00e4nge det finns tillr\u00e4ckligt med arbetsminne i cachen. Om behovet hos en applikation \u00f6kar, ers\u00e4tter k\u00e4rnan gamla cachesidor och skapar utrymme utan att jag beh\u00f6ver ingripa manuellt. N\u00e4r jag g\u00e5r in i perioder med h\u00f6g belastning observerar jag detta med fokus p\u00e5 <a href=\"https:\/\/webhosting.de\/sv\/minnesbelastning-linux-kaernan-webbhotell-systemoptimering-ram\/\">Lagringstryck<\/a>, f\u00f6r att korrekt bed\u00f6ma l\u00e4get och klassificera flaskhalsar.<\/p>\n\n<h2>Arbetsbelastningar som gynnas kraftigt<\/h2>\n\n<p>Jag ser de st\u00f6rsta f\u00f6rdelarna i alla situationer d\u00e4r data \u00e5terkommer ofta och det uppst\u00e5r m\u00e5nga sm\u00e5 \u00e5tkomstf\u00f6rfr\u00e5gningar, vilket <strong>Cache<\/strong> f\u00f6renklas. Klassiska exempel \u00e4r webbservrar med ofta anv\u00e4nda PHP- och HTML-filer samt WordPress-installationer med \u00e5terkommande teman, plugins, media och konfigurationer. Databaser drar nytta av upprepade s\u00f6kningar p\u00e5 filsystemniv\u00e5, f\u00f6rutsatt att de inte medvetet kringg\u00e5r sidcachen. CI\/CD-system med byggartefakter samt verktyg som hanterar m\u00e5nga sm\u00e5 filer blir ocks\u00e5 m\u00e4rkbart snabbare. Till och med logganalyser som l\u00e4ser sekventiellt f\u00e5r ett f\u00f6rspr\u00e5ng tack vare RAM-buffertar, eftersom k\u00e4rnan lagrar \u00e5tkomstm\u00f6nster och tillhandah\u00e5ller dem snabbare.<\/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-performance-3829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>\u00d6vervakning och m\u00e4tning: s\u00e5 utv\u00e4rderar jag cache-effekter<\/h2>\n\n<p>Jag b\u00f6rjar med att kontrollera med <code>fri -h<\/code>, hur stor \u201ebuff\/cache\u201c \u00e4r och hur <strong>belagd<\/strong> Lagring har utvecklats \u00f6ver tid. En titt p\u00e5 <code>\/proc\/meminfo<\/code> visar mig nyckeltal som <code>Cached<\/code>, <code>Smutsig<\/code> och <code>\u00c5terf\u00f6ring<\/code>, som ger information om popul\u00e4ra artiklar och p\u00e5g\u00e5ende skrivuppgifter. Med <code>iostat -x 1<\/code> eller . <code>pidstat -d 1<\/code> ser jag om den fysiska I\/O-belastningen minskar s\u00e5 snart min cache har v\u00e4rmts upp. Verktyg som <code>perf<\/code> eller . <code>bcc<\/code>-baserade skript hj\u00e4lper till att skapa djup, men beh\u00f6vs s\u00e4llan i vardagen n\u00e4r tydliga m\u00f6nster \u00e4r synliga. Dessutom testar jag genom upprepade fil\u00e5tkomster om den andra k\u00f6rningen blir signifikant snabbare, vilket visar effekten av <strong>Cacher<\/strong> bekr\u00e4ftat.<\/p>\n\n<h2>Inst\u00e4llningar: Parametrar och l\u00e4mpliga standardv\u00e4rden<\/h2>\n\n<p>Jag anpassar bara det jag f\u00f6rst\u00e5r och b\u00f6rjar med cache-optimering med n\u00e5gra f\u00e5, l\u00e4ttbegripliga <strong>Justeringsskruvar<\/strong>. Parametrarna vm.dirty styr n\u00e4r skrivoperationer b\u00f6rjar \u00f6verf\u00f6ras fr\u00e5n RAM-minnet till lagringsmediet och hur aggressivt denna process genomf\u00f6rs. <code>vm.vfs_cache_tryck<\/code> best\u00e4mmer i vilken utstr\u00e4ckning k\u00e4rnan f\u00f6rskjuter Dentry- och Inode-cacher, vilket direkt p\u00e5verkar filsystemets operationer. Readahead-v\u00e4rden p\u00e5 blockenhetsniv\u00e5 kan f\u00f6rb\u00e4ttra den sekventiella l\u00e4sprestandan om arbetsbelastningarna gynnas av detta. Jag dokumenterar varje steg, testar under belastning och \u00e5terg\u00e5r vid behov till standardv\u00e4rdena om ingen f\u00f6rb\u00e4ttring uppn\u00e5s.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Parametrar<\/strong><\/th>\n      <th><strong>Standard<\/strong><\/th>\n      <th><strong>Effekt<\/strong><\/th>\n      <th><strong>N\u00e4r ska man \u00e4ndra<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio<\/td>\n      <td>10%<\/td>\n      <td>Start av den asynkrona write-back-fasen<\/td>\n      <td>L\u00e5t m\u00e5nga sm\u00e5 skrivningar ske tidigare<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio<\/td>\n      <td>20%<\/td>\n      <td>Maximal andel \u201edirty\u201c i RAM-minnet<\/td>\n      <td>Till\u00e5t st\u00f6rre buffert vid burst-belastning<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_expire_centisecs<\/td>\n      <td>3000<\/td>\n      <td>\u201eDirty\u201c-tid fram till flush (i 1\/100 s)<\/td>\n      <td>St\u00e4ll in en l\u00e4gre latens f\u00f6r m\u00e5len<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_writeback_centisekunder<\/td>\n      <td>500<\/td>\n      <td>Intervall f\u00f6r skrivning i bakgrunden<\/td>\n      <td>Om lagringsenheten \u00e4r tr\u00f6g, h\u00f6j den n\u00e5got<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.vfs_cache_tryck<\/td>\n      <td>100<\/td>\n      <td>Behov av att rensa dentries\/inodes<\/td>\n      <td>Vid m\u00e5nga fil\u00e5tg\u00e4rder minskar<\/td>\n    <\/tr>\n    <tr>\n      <td>Block-Readahead<\/td>\n      <td>beroende p\u00e5 enhet<\/td>\n      <td>Sekventiell f\u00f6rhandsgranskning<\/td>\n      <td>\u00d6ka vid str\u00f6ml\u00e4sning<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>F\u00f6r att f\u00e5 en djupare inblick i processerna vid \u00e5tervinning och utlagring \u00e4r det v\u00e4rt att ta en titt p\u00e5 <a href=\"https:\/\/webhosting.de\/sv\/server-page-cache-eviction-linux-minne-utskriftsoptimering-insikt\/\">Rensning av sidcache<\/a>, f\u00f6r att kunna g\u00f6ra en v\u00e4lgrundad utv\u00e4rdering av sin egen konfiguration. Jag genomf\u00f6r alltid \u00e4ndringar stegvis, \u00f6vervakar dem med m\u00e4tpunkter och dokumenterar effekterna tydligt, s\u00e5 att varje <strong>Anpassning<\/strong> f\u00f6rblir begripligt.<\/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\/LinuxCachePerformance5678.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sidcache och databaser: n\u00e4r det \u00e4r l\u00e4mpligt att kringg\u00e5 dem<\/h2>\n\n<p>Vissa databaser anv\u00e4nder medvetet <strong>Direkt I\/O<\/strong> f\u00f6r att undvika dubbel buffring och ist\u00e4llet utnyttja sina egna cacher. I s\u00e5dana scenarier arbetar jag med databasens interna parametrar och f\u00f6rlitar mig mindre p\u00e5 Linux sidcache. Om en motor ofta h\u00e4mtar nya data eller hanterar mycket stora arbetsvolymer l\u00f6nar det sig att anv\u00e4nda bypass-modellen f\u00f6r att g\u00f6ra minnesanv\u00e4ndningen mer f\u00f6ruts\u00e4gbar. Om fokus d\u00e4remot ligger p\u00e5 upprepade filavl\u00e4sningar fr\u00e5n samma tabeller eller index \u00e4r filsystemets cache fortfarande anv\u00e4ndbar. Jag fattar beslut utifr\u00e5n det faktiska \u00e5tkomstm\u00f6nstret, inte utifr\u00e5n en generell regel, s\u00e5 att <strong>Effekt<\/strong> verkligen \u00f6kar.<\/p>\n\n<h2>Eviction, Reclaim och lagringstryck<\/h2>\n\n<p>Vid h\u00f6g belastning sorterar k\u00e4rnan sidorna i aktiva och inaktiva <strong>LRU-listor<\/strong> och rensar gradvis bort kandidater fr\u00e5n cachen. Denna \u00e5tervinningsprocess reagerar p\u00e5 belastning som uppst\u00e5r till f\u00f6ljd av \u00f6kande processbehov, cgroup-gr\u00e4nser eller I\/O-v\u00e4ntetider. Om min \u00f6vervakning visar p\u00e5 \u00f6kade evictions och samtidigt stigande I\/O-belastning inser jag att arbetsdataupps\u00e4ttningen \u00e4r st\u00f6rre \u00e4n det tillg\u00e4ngliga RAM-minnet. I s\u00e5dana faser utv\u00e4rderar jag om jag ska isolera arbetsbelastningar, \u00e4ndra cachingstrategier eller ut\u00f6ka minnet. F\u00f6r att f\u00f6rst\u00e5 utrymningsreglerna \u00e4r det till hj\u00e4lp med en strukturerad guide till <a href=\"https:\/\/webhosting.de\/sv\/minnesbelastning-linux-kaernan-webbhotell-systemoptimering-ram\/\">Lagringstryck<\/a>, f\u00f6r att kunna tolka symtomen korrekt och planera \u00e5tg\u00e4rder.<\/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_cache_performance_8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>I praktiken: snabba kontroller och kommandon<\/h2>\n\n<p>F\u00f6r att ge ett f\u00f6rsta intryck b\u00f6rjar jag med <code>fri -h<\/code> och l\u00e4s andelen <strong>buff\/cache<\/strong>, innan jag g\u00e5r in p\u00e5 detaljerna. D\u00e4refter j\u00e4mf\u00f6r jag tv\u00e5 k\u00f6rningar av en filskanning, till exempel med <code>finna<\/code> eller ett j\u00e4mf\u00f6retest, och observera tidsskillnaden mellan kallstart och varmstart. <code>grep -E \"Cached|Dirty|Writeback\" \/proc\/meminfo<\/code> visar mig hur mycket som finns i cachen och vad som fortfarande m\u00e5ste skrivas. <code>iostat -xz 1<\/code> visar hur h\u00e5rt belastade enheterna \u00e4r och om k\u00f6erna minskar s\u00e5 snart cachen tr\u00e4der i kraft. Den som vill l\u00e4sa mer om grunderna i caching hittar en \u00f6versikt i <a href=\"https:\/\/webhosting.de\/sv\/filsystem-caching-linux-sidcache-cacheboost\/\">Cachelagring i filsystemet<\/a> en l\u00e4ttbegriplig introduktion som f\u00f6rklarar samspelet mellan VFS och RAM-buffert.<\/p>\n\n<h2>Att reda ut vanliga missf\u00f6rst\u00e5nd<\/h2>\n\n<p>\u201eRAM-minnet \u00e4r fullt, servern har ett problem\u201c, h\u00f6r jag ofta, men <strong>Cache<\/strong> \u00e4r svaret h\u00e4r, inte orsaken. Linux frig\u00f6r arbetsminne p\u00e5 ett flexibelt s\u00e4tt n\u00e4r program anv\u00e4nder det och tar det i anspr\u00e5k igen s\u00e5 snart nya data lagras tillf\u00e4lligt. Att t\u00f6mma det manuellt med <code>echo 3 &gt; \/proc\/sys\/vm\/drop_caches<\/code> ger s\u00e4llan n\u00e5gon varaktig nytta och f\u00f6rvr\u00e4nger m\u00e4tresultaten. Det \u00e4r b\u00e4ttre att identifiera de verkliga flaskhalsarna och avlasta I\/O-v\u00e4garna just d\u00e4r. Jag skiljer dessutom mellan sidcache och slab-cacher f\u00f6r dentries\/inodes, s\u00e5 att jag inte f\u00e5r tv\u00e5 olika <strong>Mekanismer<\/strong> l\u00e4gger i en kastrull.<\/p>\n\n<h2>Monteringsalternativ och finesser i filsystemet<\/h2>\n\n<p>Jag tar h\u00e4nsyn till att filsystem- och monteringsalternativ har stor inverkan p\u00e5 sidcachens effektivitet. <strong>tid<\/strong>-Uppdateringar genererar ytterligare skrivningar; med <em>relatime<\/em> (numera standard) minskar jag dessa, <em>ingen tid<\/em> sparar \u00e4nnu mer om jag aldrig \u00e4r beroende av \u00f6ppettider. <strong>synkronisering<\/strong> och <strong>dirsync<\/strong> tvingar fram omedelbar best\u00e4ndighet och motverkar f\u00f6rdelarna med write-back \u2013 ber\u00e4ttigat f\u00f6r metadata d\u00e4r latensen \u00e4r avg\u00f6rande, annars undviker jag dem. Journaleringsl\u00e4gen (t.ex. i ext4 <em>data=ordnad<\/em> mot. <em>\u00e5terskrivning<\/em>) p\u00e5verkar om anv\u00e4ndardata sparas f\u00f6re eller efter metadata p\u00e5 lagringsmediet; jag prioriterar s\u00e4kerhet framf\u00f6r skenbar prestanda. XFS och btrfs fungerar annorlunda n\u00e4r det g\u00e4ller metadata och CoW: CoW, komprimering eller deduplicering sparar I\/O, men kan kr\u00e4va mer CPU-resurser. D\u00e4rf\u00f6r m\u00e4ter jag arbetsbelastningarna p\u00e5 ett realistiskt s\u00e4tt och avg\u00f6r om monteringsalternativen passar \u00e5tkomstm\u00f6nstret.<\/p>\n\n<h2>Containrar, virtuella maskiner och dubbla cacher<\/h2>\n\n<p>I containrar delar alla processer samma k\u00e4rna \u2013 och d\u00e4rmed \u00e4ven samma sidcache. Detta underl\u00e4ttar delningen av ofta anv\u00e4nda filer (t.ex. bibliotek), men strikta cgroup-gr\u00e4nser (<em>minne.max<\/em>) kan ers\u00e4tta cachesidor i ett tidigt skede. Jag planerar in utrymme per tj\u00e4nst och anv\u00e4nder <em>minne.l\u00e5g<\/em>, f\u00f6r att ge viktiga cacher ett visst skydd. I virtuella maskiner finns <strong>tv\u00e5<\/strong> Cacheminnen: i g\u00e4sten och eventuellt hos v\u00e4rden (vid filbackup). Detta leder till dubbel buffring. Om jag anv\u00e4nder r\u00e5enheter eller direktlagring slipper jag v\u00e4rdens cache, men g\u00e5r miste om dess f\u00f6rdelar. Ballooning och overcommit p\u00e5verkar \u00e5tervinningen i g\u00e4sten \u2013 jag observerar om st\u00e4ndig ballooning leder till cache-thrashing och justerar resurser eller dimensionering d\u00e4refter. Vid containerlagring (OverlayFS) v\u00e4rmer jag upp ofta anv\u00e4nda lager p\u00e5 ett m\u00e5linriktat s\u00e4tt s\u00e5 att distributioner inte startar fr\u00e5n kallt tillst\u00e5nd.<\/p>\n\n<h2>NUMA, cgroups och isolering<\/h2>\n\n<p>I NUMA-system hanterar k\u00e4rnan LRU-listor per nod. Om tr\u00e5dar huvudsakligen g\u00f6r lokala \u00e5tkomstf\u00f6rs\u00f6k f\u00f6rblir sidcachetr\u00e4ffarna <strong>numa-nah<\/strong> och minskar latensen. Genom CPU- och minnesaffinitet ser jag till att en applikation och dess data ligger n\u00e4ra varandra. Via <strong>memcg<\/strong> (cgroups v2) tilldelas sidcachen till en grupp; med <em>minne.h\u00f6g<\/em> utl\u00f6ser jag en kontrollerad \u00e5tervinning med <em>minne.max<\/em> s\u00e4tter jag tydliga gr\u00e4nser och med <em>minne.l\u00e5g<\/em> Jag prioriterar viktiga tj\u00e4nster. Dessa verktyg bidrar till att ett resurskr\u00e4vande batchjobb inte t\u00f6mmer cachen f\u00f6r en webbtj\u00e4nst som \u00e4r k\u00e4nslig f\u00f6r latens. Isolering g\u00f6r det l\u00e4ttare att planera \u2013 men jag balanserar det s\u00e5 att det inte uppst\u00e5r f\u00f6r m\u00e5nga sm\u00e5 cacher som var f\u00f6r sig ger f\u00f6r f\u00e5 tr\u00e4ffar.<\/p>\n\n<h2>SSD, HDD och readahead i praktiken<\/h2>\n\n<p>Readahead \u00e4r en f\u00f6rdel vid sekventiella m\u00f6nster, men ofta bara en belastning vid slumpm\u00e4ssiga \u00e5tkomstf\u00f6rfr\u00e5gningar. P\u00e5 HDD-enheter \u00f6kar jag vanligtvis readahead f\u00f6r att p\u00e5skynda linj\u00e4ra s\u00f6kningar. P\u00e5 snabba NVMe-SSD-enheter \u00e4r nyttan mindre; f\u00f6r mycket readahead sl\u00f6sar bort RAM-minne och f\u00f6rs\u00e4mrar cachetr\u00e4ffarna, eftersom oanv\u00e4nda sidor tr\u00e4nger undan andra. Jag anpassar readahead per enhet och kontrollerar genom upprepade k\u00f6rningar om genomstr\u00f6mningen eller latenserna f\u00f6rb\u00e4ttras. Dessutom tar jag h\u00e4nsyn till I\/O-schemal\u00e4ggaren: F\u00f6r NVMe \u00e4r \u201enone\u201c\/\u201emq-deadline\u201c vanligt, medan HDD-enheter kan dra nytta av deadline-schemal\u00e4ggning. Sidcachen j\u00e4mnar ut I\/O-profilerna, men blocklagret m\u00e5ste passa in i detta. M\u00e5let \u00e4r fortfarande att cachen huvudsakligen ska inneh\u00e5lla anv\u00e4ndbara, \u00e5teranv\u00e4nda data \u2013 inte bara f\u00f6rhandsh\u00e4mtade byte.<\/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-performance-4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kallstart, f\u00f6rv\u00e4rmning och drifts\u00e4ttningar<\/h2>\n\n<p>Varje cache beh\u00f6ver en uppv\u00e4rmningsfas. Efter omstarter eller utrullningar l\u00e4ser jag in specifika hotsets, till exempel genom att g\u00e5 igenom viktiga kataloger i tur och ordning. Detta minskar m\u00e4rkbart den \u201ekalla minuten\u201c efter drifts\u00e4ttningar. Vid rullande strategier h\u00e5ller jag minst en uppv\u00e4rmd instans online s\u00e5 att tj\u00e4nsten som helhet svarar snabbt medan nya instanser fyller sin cache. Jag undviker mass\u00e4ndringar i filstrukturen (t.ex. \u00e4ndrade s\u00f6kv\u00e4gar), eftersom det g\u00f6r dentries\/inodes \u201dkalla\u201d. Ist\u00e4llet arbetar jag med atom\u00e4ra syml\u00e4nkbyten eller Copy-on-Write-strategier, d\u00e4r filinneh\u00e5ll och s\u00f6kv\u00e4gar i stort sett f\u00f6rblir stabila. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir inte bara sidcachen effektiv, utan \u00e4ven metadatacacherna beh\u00e5ller sin verkan.<\/p>\n\n<h2>M\u00e4tv\u00e4rden p\u00e5 djupet<\/h2>\n\n<p>F\u00f6rutom <code>\/proc\/meminfo<\/code> f\u00f6r att st\u00e4lla en noggrann diagnos tittar jag i <code>\/proc\/vmstat<\/code>: M\u00e4tare som <em>pgfault<\/em> och <em>pgmajfault<\/em> skiljer mellan l\u00e4tta och allvarliga sidfel, <em>nr_active_file<\/em>\/<em>nr_inaktiv_fil<\/em> visar storleken p\u00e5 den filbaserade arbetsupps\u00e4ttningen, och <em>arbetsupps\u00e4ttning_fel<\/em> hj\u00e4lper till att uppt\u00e4cka thrashing. Om antalet refaults \u00f6kar samtidigt som enhetens I\/O-hastighet f\u00f6rblir h\u00f6g, ryms inte arbetssatsen i RAM-minnet. Jag testar med tv\u00e5 k\u00f6rningar av samma arbetsbelastning: Den andra k\u00f6rningen b\u00f6r vara betydligt snabbare om cachen fungerar. F\u00f6r att kunna utf\u00f6ra reproducerbara kallstartstester t\u00f6mmer jag cacheminnena uteslutande i laboratoriemilj\u00f6 och dokumenterar detta noggrant f\u00f6r att inte f\u00f6rvr\u00e4nga produktionsm\u00e4tningarna. F\u00f6r mig \u00e4r det viktigt att inte \u00f6verinterprettera en enskild nyckeltal, utan att ist\u00e4llet identifiera m\u00f6nster \u00f6ver tidsserier.<\/p>\n\n<h2>Undvika swap, swappiness och thrashing<\/h2>\n\n<p>N\u00e4r trycket \u00f6kar t\u00f6mmer Linux f\u00f6rst sidcachen innan det g\u00e5r \u00f6ver till anonyma sidor \u2013 s\u00e5 l\u00e4nge det \u00e4r l\u00e4mpligt. Om arbetsminnet b\u00f6rjar ta slut f\u00f6r processerna och det inte finns tillr\u00e4ckligt med ledigt utrymme p\u00e5 de anonyma sidorna b\u00f6rjar systemet att swappa. En <strong>f\u00f6r l\u00e5g<\/strong> Swappiness kan leda till att viktigt anonymt minne (heaps\/stacks) h\u00e5lls kvar p\u00e5 ett aggressivt s\u00e4tt, vilket i sin tur tr\u00e4nger undan anv\u00e4ndbara cachesidor och d\u00e4rmed \u00f6kar I\/O-belastningen. En <strong>f\u00f6r h\u00f6g<\/strong> Swappiness leder tv\u00e4rtom till att data flyttas ut tidigare och till latensspikar. Jag v\u00e4ljer m\u00e5ttliga v\u00e4rden, m\u00e4ter och observerar: M\u00e5let \u00e4r att min hotset ska stanna kvar i RAM-minnet och att endast kalla, s\u00e4llan anv\u00e4nda data ska flyttas ut till swap-utrymmet \u2013 aldrig de heta.<\/p>\n\n<h2>S\u00e4kerhet och h\u00e5llbarhet: Data p\u00e5 lagringsmediet<\/h2>\n\n<p>\u00c5terinskrivning f\u00f6rb\u00e4ttrar prestandan, men skapar ett kort tidsf\u00f6nster d\u00e4r \u00e4ndringarna endast finns i RAM-minnet. F\u00f6r data som m\u00e5ste vara best\u00e4ndiga omedelbart anv\u00e4nder jag <code>fsync()<\/code> eller . <code>fdatasync()<\/code>. Jag f\u00f6rlitar mig dessutom p\u00e5 s\u00e4kra standardinst\u00e4llningar som skrivskydd och journalf\u00f6ring; riskfyllda alternativ som inaktiverar skyddet undviker jag. P\u00e5 lagringsniv\u00e5 beaktar jag kontrollercacher: Write-back-policyer med batteri\/kondensator \u00e4r snabba och s\u00e4kra, medan os\u00e4kra cacher utan skydd \u00e4r k\u00e4nsliga. Systemomfattande tvingar <code>synkronisering<\/code> Rensning av all data \u2013 ett grovt verktyg som jag anv\u00e4nder medvetet och s\u00e4llan. P\u00e5 s\u00e5 s\u00e4tt kombinerar jag hastighet genom sidcachen med ren persistens d\u00e4r det \u00e4r aff\u00e4rskritiskt.<\/p>\n\n<h2>WordPress och webbstackar: praktiska tips<\/h2>\n\n<p>I webbstacken l\u00e4ggs olika cacher till varandra: Linux Page Cache p\u00e5skyndar statiska tillg\u00e5ngar, PHP-filer och konfigurationer, medan en PHP-OpCode-cache h\u00e5ller exekveringsv\u00e4gen och bytecode i minnet. Jag ser till att distributioner inte st\u00e4ndigt \u00e4ndrar kodv\u00e4gen och minskar fil\u00e5tkomsten genom att sl\u00e5 samman resurser. Ett best\u00e4ndigt objektcache-lager minskar databas-I\/O, vilket g\u00f6r att filsystemcachen kan hantera de \u00e5terst\u00e5ende ofta anv\u00e4nda filerna \u00e4nnu effektivare. N\u00e4r det \u00e4r m\u00f6jligt lagrar jag inte sessioner och transienter p\u00e5 den lokala h\u00e5rddisken, utan i minnes- eller n\u00e4tverkscacher, s\u00e5 att sidcachen kan utnyttja sin styrka f\u00f6r de \u00f6vriga, ofta l\u00e4sta filerna. Resultat: mindre fysisk I\/O, snabbare svar och stabilare latenser.<\/p>\n\n<h2>Kortfattat sammanfattat<\/h2>\n\n<p>Linux-sidcachen ger mig snabba svar p\u00e5 filf\u00f6rfr\u00e5gningar <strong>RAM<\/strong> och minskar avsev\u00e4rt antalet kostsamma \u00e5tkomstf\u00f6rfr\u00e5gningar till datamediet. L\u00e4s-hits p\u00e5skyndar applikationer, medan write-back sammanf\u00f6r m\u00e5nga enskilda skrivningar och \u00f6kar effektiviteten. Ledigt minne f\u00f6rblir inte outnyttjat, utan fungerar som cache f\u00f6r en responsiv plattform. Med m\u00e4tpunkter som <code>fri -h<\/code>, <code>\/proc\/meminfo<\/code> och <code>iostat<\/code> ser jag effekten innan jag tar h\u00e4nsyn till parametrar som <code>vm.dirty_ratio<\/code> eller . <code>vm.vfs_cache_tryck<\/code> G\u00e5 vidare. Den som k\u00e4nner till arbetsbelastningar, testar \u00e4ndringar p\u00e5 ett kontrollerat s\u00e4tt och anv\u00e4nder cachen p\u00e5 ett m\u00e5linriktat s\u00e4tt uppn\u00e5r en m\u00e4rkbart b\u00e4ttre <strong>Prestanda<\/strong> utan att \u00e4ndra koden.<\/p>","protected":false},"excerpt":{"rendered":"<p>Linux Page Cache anv\u00e4nder RAM-minnet som cache och f\u00f6rb\u00e4ttrar d\u00e4rmed serverns prestanda vid webbhotell, WordPress och fil\u00e5tkomst.<\/p>","protected":false},"author":1,"featured_media":20533,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20540","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":"179","_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":null,"_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":"Linux Page","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":"20533","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/20540","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=20540"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/20540\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/20533"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=20540"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=20540"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=20540"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}