{"id":21087,"date":"2026-08-27T18:20:06","date_gmt":"2026-08-27T16:20:06","guid":{"rendered":"https:\/\/webhosting.de\/zfs-arc-cache-speicherverbrauch-erklaerung-tuning-io\/"},"modified":"2026-08-27T18:20:06","modified_gmt":"2026-08-27T16:20:06","slug":"zfs-arc-cache-minnesanvaendning-foerklaring-optimering-io","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/zfs-arc-cache-speicherverbrauch-erklaerung-tuning-io\/","title":{"rendered":"ZFS ARC-cache: Att f\u00f6rst\u00e5 minnesanv\u00e4ndningen p\u00e5 r\u00e4tt s\u00e4tt"},"content":{"rendered":"<p><strong>ZFS ARC<\/strong> utnyttjar RAM-minnet aggressivt f\u00f6r att snabbt g\u00f6ra ofta l\u00e4sta block tillg\u00e4ngliga och samtidigt dynamiskt anpassa den faktiska minnesanv\u00e4ndningen efter belastningen. Jag f\u00f6rklarar hur jag tolkar den till synes h\u00f6ga minnesanv\u00e4ndningen p\u00e5 r\u00e4tt s\u00e4tt, vilka nyckeltal som \u00e4r viktiga och hur jag s\u00e4kert styr cacheminnets storlek utan att <strong>Prestanda<\/strong> ...att f\u00f6rlora.<\/p>\n\n<h2>Centrala punkter<\/h2>\n\n<p>F\u00f6r att underl\u00e4tta orienteringen sammanfattar jag de viktigaste punkterna och markerar avg\u00f6rande nyckelord f\u00f6r att skapa en tydlig <strong>\u00d6versikt<\/strong>.<\/p>\n<ul>\n  <li><strong>ARC-storlek<\/strong>: Dynamisk, kan st\u00e4llas in via zfs_arc_max\/min<\/li>\n  <li><strong>\u00c5tervinningsbar<\/strong>: Cache-RAM frig\u00f6rs omedelbart vid behov<\/li>\n  <li><strong>Tr\u00e4fffrekvens<\/strong>: En h\u00f6g tr\u00e4fffrekvens visar att cacheminnet anv\u00e4nds p\u00e5 ett effektivt s\u00e4tt<\/li>\n  <li><strong>L2ARC<\/strong>: Till\u00e4gg till SSD\/NVMe, ers\u00e4tter inte RAM-minnet<\/li>\n  <li><strong>Regler f\u00f6r datam\u00e4ngder<\/strong>: finjustering av prim\u00e4rcache\/sekund\u00e4rcache<\/li>\n<\/ul>\n<p>Jag anv\u00e4nder dessa tips i vardagen f\u00f6r att h\u00e5lla l\u00e4sv\u00e4garna korta och utnyttja minnet p\u00e5 ett rimligt s\u00e4tt <strong>dela<\/strong>. En full ARC tyder p\u00e5 aktiv anv\u00e4ndning och inte p\u00e5 ett fel eller ett dolt <strong>L\u00e4ckage<\/strong>. F\u00f6rst n\u00e4r swapping eller OOM-h\u00e4ndelser intr\u00e4ffar s\u00e4tter jag tydliga gr\u00e4nser. D\u00e4refter validerar jag \u00e4ndringarna med m\u00e4tv\u00e4rden och justerar stegvis <strong>Ram<\/strong>. P\u00e5 s\u00e5 s\u00e4tt h\u00e5ller jag systemen ig\u00e5ng utan att bromsa andra tj\u00e4nster eller ta riskfyllda f\u00f6rhastade beslut <strong>v\u00e4lja<\/strong>.<\/p>\n\n<h2>Vad ARC egentligen g\u00f6r i minnet<\/h2>\n\n<p>ARC \u00e4r en adaptiv l\u00e4scache och kombinerar <strong>MRU<\/strong> (senast anv\u00e4nd) med <strong>MFU<\/strong> (anv\u00e4nds ofta). Denna kombination anpassar sig automatiskt efter det m\u00f6nster som mina arbetsbelastningar skapar och h\u00e5ller just de block tillg\u00e4ngliga som ger st\u00f6rst effekt. Detta minskar latensen m\u00e4rkbart, eftersom \u00e5tkomsten sker direkt fr\u00e5n RAM-minnet och inte fr\u00e5n <strong>skivor<\/strong> eller SSD-enheter. Jag drar framf\u00f6r allt nytta av detta vid upprepade \u00e5tkomstf\u00f6rs\u00f6k, eftersom tr\u00e4fffrekvensen \u00f6kar f\u00f6r varje matchande <strong>F\u00f6rfr\u00e5gan<\/strong>. Cachen visar s\u00e4rskilt sin styrka n\u00e4r det g\u00e4ller VM-avbildningar, databaser och m\u00e5nga sm\u00e5 filer.<\/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\/zfs-arc-cache-5723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<p>Just p\u00e5 grund av detta tillv\u00e4gag\u00e5ngss\u00e4tt verkar RAM-minnet vara \u201efullt\u201c, \u00e4ven om jag fortfarande <strong>Reserver<\/strong> har. Den upptagna cachen kan frig\u00f6ras n\u00e4r som helst s\u00e5 snart processer beg\u00e4r minne. P\u00e5 s\u00e5 s\u00e4tt utnyttjar systemet ledig kapacitet aktivt, ist\u00e4llet f\u00f6r att l\u00e5ta den ligga outnyttjad, och h\u00e5ller \u00e4nd\u00e5 belastningstoppar under <strong>Kontroll<\/strong>. Den som \u00e4r intresserad av en direkt j\u00e4mf\u00f6relse av filsystem kan ta en titt p\u00e5 min kortfattade <a href=\"https:\/\/webhosting.de\/sv\/ext4-xfs-zfs-hosting-prestanda-jaemfoerelse-lagring\/\">J\u00e4mf\u00f6relse av prestanda<\/a> . D\u00e4r visar jag varf\u00f6r en smart cache ofta verkar viktigare \u00e4n ren <strong>Teori<\/strong>.<\/p>\n\n<h2>Varf\u00f6r h\u00f6gt RAM-utnyttjande \u00e4r avsiktligt<\/h2>\n\n<p>Jag ser det som n\u00e5got positivt att RAM-minnet \u00e4r \u201efullt\u201c i ARC, s\u00e5 l\u00e4nge systemet inte drabbas av verklig minnesbrist <strong>lider<\/strong>. ZFS frig\u00f6r omedelbart cacheminne n\u00e4r applikationer v\u00e4xer och anpassar m\u00e5lstorleken l\u00f6pande. I vanliga verktyg visas detta RAM-minne som \u201eupptaget\u201c, \u00e4ven om det utan dr\u00f6jsm\u00e5l kan anv\u00e4ndas f\u00f6r nya processer <strong>Disposition<\/strong> . En verklig flaskhals visar sig f\u00f6rst genom swapping, m\u00e4rkbara f\u00f6rdr\u00f6jningar eller OOM-killer-aktivitet. F\u00f6r att b\u00e4ttre f\u00f6rst\u00e5 detta kan man ta en titt p\u00e5 <a href=\"https:\/\/webhosting.de\/sv\/linux-transparent-sidcache-skillnader-mellan-sidcacher-optimering-datacache\/\">Skillnader i sidcache<\/a>, eftersom operativsystemets cache och ARC h\u00e4nger ihop och b\u00e5da p\u00e5verkar den synliga f\u00f6rbrukningen <strong>pr\u00e4glat<\/strong>.<\/p>\n\n<p>Det avg\u00f6rande \u00e4r d\u00e4rf\u00f6r sammanhanget, inte en enskild sk\u00e4rmdump fr\u00e5n ett \u00f6vervakningsverktyg som visar \u201e0 GB ledigt utrymme\u201c som <strong>Skr\u00e4ck<\/strong>. Jag kontrollerar dessutom I\/O-v\u00e4ntetider, utvecklingen av swap-minnet och belastningsprofilerna f\u00f6r de viktigaste tj\u00e4nsterna. Om dessa v\u00e4rden ser normala ut ger jag ARC utrymme att maximera \u00e5terkommande l\u00e4soperationer <strong>p\u00e5skynda<\/strong>. Om det uppst\u00e5r flaskhalsar h\u00f6jer jag taket n\u00e5got, ist\u00e4llet f\u00f6r att sk\u00e4rpa ARC-kraven kraftigt <strong>avsk\u00e4ra<\/strong>. P\u00e5 s\u00e5 s\u00e4tt uppr\u00e4tth\u00e5lls balansen mellan cachingvinster och applikationens behov.<\/p>\n\n<h2>Hur ZFS fastst\u00e4ller ARC-storleken<\/h2>\n\n<p>Om inga inst\u00e4llningar anges s\u00e4tter ZFS en rimlig \u00f6vre gr\u00e4ns baserat p\u00e5 det tillg\u00e4ngliga <strong>RAM<\/strong>. Jag styr denna dynamik med tv\u00e5 parametrar: <strong>zfs_arc_max<\/strong> som \u00f6vre gr\u00e4ns och <strong>zfs_arc_min<\/strong> som l\u00e4gsta gr\u00e4ns. Om zfs_arc_max \u00e4r inst\u00e4llt p\u00e5 0 eller inte \u00e4r angivet v\u00e4ljer ZFS automatiskt ett l\u00e4mpligt intervall, ofta ungef\u00e4r h\u00e4lften av <strong>minne<\/strong>. Vid belastningstoppar krymper ARC, men inte under zfs_arc_min, s\u00e5 att viktiga block f\u00f6rblir i RAM-minnet. Om jag st\u00e4ller in gr\u00e4nserna f\u00f6r sn\u00e4vt sjunker tr\u00e4fffrekvensen och l\u00e4s-I\/O \u00e5terg\u00e5r oftare till <strong>Platta<\/strong> tillbaka.<\/p>\n\n<p>I detta sammanhang inneb\u00e4r \u201dpraktiskt\u201d: Mycket RAM m\u00f6jligg\u00f6r en stor cache, vilket har stor betydelse f\u00f6r databaser och VM-hosting <strong>verk<\/strong>. Om det saknas lagringsutrymme f\u00f6r andra tj\u00e4nster begr\u00e4nsar jag medvetet zfs_arc_max och h\u00e5ller zfs_arc_min flexibelt. Jag testar i etapper, observerar effekterna och justerar utifr\u00e5n faktiska trendv\u00e4rden. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rhindrar jag att en eng\u00e5ngstopp p\u00e5verkar <strong>Konfiguration<\/strong> dominerar. En gradvis anpassning leder till p\u00e5litligt beteende utan negativa <strong>\u00d6verraskningar<\/strong>.<\/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\/zfs_arc_cache_meeting_3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Att tolka ARC-nyckeltal p\u00e5 r\u00e4tt s\u00e4tt<\/h2>\n\n<p>F\u00f6r att f\u00e5 en \u00f6verblick granskar jag regelbundet de viktigaste nyckeltalen och sammanst\u00e4ller sambanden i en \u00f6versk\u00e5dlig <strong>Tabell<\/strong> fast. Verktyg som arcstat eller arc_summary levererar kontinuerligt data som jag kopplar samman med pool-I\/O och applikationsmetriker. H\u00e4r \u00e4r helhetsbilden viktigare \u00e4n en enskild avvikelse i <strong>Diagram<\/strong>. Just f\u00f6rh\u00e5llandet mellan tr\u00e4ffar och missar visar om cachen t\u00e4cker arbetsbelastningen p\u00e5 ett l\u00e4mpligt s\u00e4tt. H\u00f6ga tr\u00e4ffprocent tyder p\u00e5 stabil prestanda och korta l\u00e4sv\u00e4gar i <strong>RAM<\/strong> d\u00e4r.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Nyckeltal<\/th>\n      <th>Beskrivning av<\/th>\n      <th>Vad jag uppm\u00e4rksammar<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>ARC-storlek<\/td>\n      <td>Aktuell cache-storlek i <strong>RAM<\/strong><\/td>\n      <td>Expanderar under belastning, krymper m\u00e4rkbart vid behov<\/td>\n    <\/tr>\n    <tr>\n      <td>ARC c \/ c_max<\/td>\n      <td>M\u00e5lstorlek och maximal m\u00e5lstorlek<\/td>\n      <td>N\u00e4rmar sig c_max vid h\u00f6g belastning, luft vid vila<\/td>\n    <\/tr>\n    <tr>\n      <td>Framg\u00e5ngar \/ Misslyckanden<\/td>\n      <td>Tr\u00e4ffar respektive missar sedan <strong>Start<\/strong><\/td>\n      <td>\u00c4r miss-v\u00e4rdet konstant h\u00f6gt? Kontrollera arbetsvolymen eller cache-policyn<\/td>\n    <\/tr>\n    <tr>\n      <td>tr\u00e4ffkvot<\/td>\n      <td>Hits i f\u00f6rh\u00e5llande till totalt antal bes\u00f6k i <strong>%<\/strong><\/td>\n      <td>M\u00e5nga repetitioner: 80\u201390 % \u00e4r realistiskt, annars f\u00e4rre<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Utifr\u00e5n dessa v\u00e4rden vidtar jag konkreta \u00e5tg\u00e4rder: Om tr\u00e4fffrekvensen f\u00f6rblir l\u00e5g trots att det finns tillr\u00e4ckligt med ledigt RAM-minne h\u00f6jer jag f\u00f6rsiktigt v\u00e4rdet p\u00e5 zfs_arc_max och observerar <strong>Trender<\/strong>. Om applikationerna uts\u00e4tts f\u00f6r belastning s\u00e4nker jag gr\u00e4nsv\u00e4rdet och m\u00e4ter latenserna och I\/O-belastningen p\u00e5 nytt. Om en st\u00f6rre cache inte ger n\u00e5gon avlastning beror det ofta p\u00e5 ett mycket slumpm\u00e4ssigt \u00e5tkomstm\u00f6nster som f\u00f6rs\u00e4mrar cachelagringen <strong>serverar<\/strong>. D\u00e5 har andra \u00e5tg\u00e4rder, som b\u00e4ttre datalokalitet eller arbetsbelastningsf\u00f6rdelning, oftast st\u00f6rre effekt. Att enbart \u00f6ka cacheminnet l\u00f6ser inte alla <strong>Problem<\/strong>.<\/p>\n\n<h2>Hur ARC fattar beslut: \u201dGhost-listor\u201d och anpassning<\/h2>\n\n<p>F\u00f6rutom <strong>MRU<\/strong> och <strong>MFU<\/strong> ARC anv\u00e4nder s\u00e5 kallade <strong>Ghost-listor<\/strong> (MRU-\/MFU-Ghost). De inneh\u00e5ller endast metadata f\u00f6r block som nyligen har f\u00f6rskjutits. Om just dessa block dyker upp igen kort efter att de har ersatts tolkar ZFS detta som ett tecken p\u00e5 att det aktuella omr\u00e5det var f\u00f6r litet och omf\u00f6rdelar kapacitet mellan MRU och MFU. S\u00e5 <strong>l\u00e4r sig<\/strong> Cachen aktiveras automatiskt vid felbed\u00f6mningar. I praktiken inneb\u00e4r det att fluktuerande m\u00f6nster (t.ex. batchf\u00f6nster p\u00e5 kv\u00e4llen) hanteras b\u00e4ttre efter n\u00e5gra cykler, utan att jag beh\u00f6ver ingripa manuellt.<\/p>\n\n<p>I detta sammanhang observerar jag framf\u00f6r allt om missar upptr\u00e4der i v\u00e5gor och om tr\u00e4ffprocenten d\u00e4refter synligt <strong>drar \u00e5t<\/strong>. Om detta intr\u00e4ffar fungerar ARC-logiken som avsett. Om antalet missar f\u00f6rblir h\u00f6gt trots upprepningar \u00e4r arbetssatsen ofta st\u00f6rre \u00e4n den tillg\u00e4ngliga cachen eller s\u00e5 \u00e4r \u00e5tkomstm\u00f6nstren f\u00f6r <strong>slumpm\u00e4ssig<\/strong>.<\/p>\n\n<h2>N\u00e4r ARC faktiskt st\u00f6r<\/h2>\n\n<p>I delade webbhotell-milj\u00f6er delar jag lagringsutrymme med m\u00e5nga andra tj\u00e4nster, och d\u00e4r kan en dominerande ARC ta luften ur systemet och orsaka swapping <strong>fr\u00e4mja<\/strong>. De som driver virtualiseringsv\u00e4rdar k\u00e4nner till den h\u00e4r balansg\u00e5ngen: Varje virtuell maskin (VM) vill g\u00e4rna ha mer RAM, samtidigt som ZFS ocks\u00e5 vill utnyttja cache-resurserna. P\u00e5 sm\u00e5 system med bara n\u00e5gra gigabyte s\u00e4tter jag gr\u00e4nserna stramare, s\u00e5 att tj\u00e4nsternas svarstid inte uts\u00e4tts f\u00f6r p\u00e5frestningar <strong>enhet<\/strong>. Problem m\u00e4rks genom tr\u00f6ga applikationer, \u00f6kad anv\u00e4ndning av swap-minne eller varningar fr\u00e5n OOM-Killer. I s\u00e5dana situationer s\u00e4tter jag tydliga \u00f6vre gr\u00e4nser och l\u00e5ter sedan systemet ha n\u00e5gra dagar p\u00e5 sig f\u00f6r <strong>J\u00e4mf\u00f6relser<\/strong>.<\/p>\n\n<p>Jag dokumenterar symtom, tidpunkter och vilka som drabbats <strong>Tj\u00e4nster<\/strong>. Om flaskhalsen uppst\u00e5r g\u00e5ng p\u00e5 g\u00e5ng under samma tidsf\u00f6nster planerar jag \u00e5tg\u00e4rder som reservf\u00f6nster, begr\u00e4nsning av indexeringar eller oml\u00e4ggning av stora skanningar. F\u00f6rst n\u00e4r organisatoriska \u00e5tg\u00e4rder inte lyckas d\u00e4mpa toppen anpassar jag tekniken och gr\u00e4nsv\u00e4rdena <strong>p\u00e5<\/strong>. Denna ordningsf\u00f6ljd ger utrymme f\u00f6r flexibilitet och f\u00f6rhindrar f\u00f6rhastade ingrepp i k\u00e4nsliga produktionsmilj\u00f6er. P\u00e5 s\u00e5 s\u00e4tt beh\u00e5lls \u00f6verblicken \u00f6ver samspelet mellan cache, I\/O och applikationer <strong>klar<\/strong>.<\/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\/zfs-arc-cache-speicherverbrauch-verstehen-8237.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Containrar, cgroups och s\u00e4rdrag hos NUMA<\/h2>\n\n<p>I container-milj\u00f6er g\u00e4ller f\u00f6ljande: ARC \u00e4r <strong>\u00f6ver hela v\u00e4rden<\/strong> och inte begr\u00e4nsad av cgroup. Om en pod\/container n\u00e5r sin minnesgr\u00e4ns skyddar det inte den fr\u00e5n att v\u00e4rddatorn hamnar under press p\u00e5 grund av ARC och andra processer. Jag planerar d\u00e4rf\u00f6r in en fast buffert p\u00e5 v\u00e4rddatorn f\u00f6r systemtj\u00e4nster och ZFS och st\u00e4ller in containergr\u00e4nserna s\u00e5 att det fysiska RAM-minnet inte utnyttjas till bristningsgr\u00e4nsen. P\u00e5 NUMA-system ser jag dessutom till att kraftig \u00e5tkomst mellan noder undviks, eftersom latensen annars \u00f6kar. J\u00e4mn f\u00f6rdelning av stora virtuella maskiner och en realistisk ARC-gr\u00e4ns per <strong>V\u00e4rd<\/strong> f\u00f6rhindrar m\u00e5nga \u00f6verraskningar h\u00e4r.<\/p>\n\n<h2>B\u00e4sta praxis f\u00f6r dimensionering<\/h2>\n\n<p>P\u00e5 dedikerade filservrar tilldelar jag g\u00e4rna ARC 60\u201380 % RAM, eftersom andra processer anv\u00e4nder lite minne <strong>efterfr\u00e5gan<\/strong>. Om det samtidigt k\u00f6rs en stack med containrar eller mindre tj\u00e4nster, b\u00f6rjar jag med 50\u201360 % och f\u00f6ljer den dynamiska belastningen. P\u00e5 hypervisorer anv\u00e4nder jag ofta 30\u201340 %, s\u00e5 att virtuella maskiner f\u00e5r tillr\u00e4ckligt med eget RAM-minne <strong>har<\/strong>. Jag brukar l\u00e5ta zfs_arc_min ligga p\u00e5 25\u201350 % av zfs_arc_max, s\u00e5 att cachen fortfarande kan krympa vid belastningstoppar. Jag genomf\u00f6r \u00e4ndringarna stegvis och utv\u00e4rderar m\u00e4tv\u00e4rdena under flera dagar <strong>fr\u00e5n<\/strong>.<\/p>\n\n<p>Jag planerar in en buffert f\u00f6r toppar ist\u00e4llet f\u00f6r att s\u00e4tta den \u00f6vre gr\u00e4nsen precis p\u00e5 gr\u00e4nsen <strong>sy<\/strong>. F\u00f6r skrivf\u00f6nster, s\u00e4kerhetskopieringar eller omindexering l\u00e4mnar jag medvetet utrymme s\u00e5 att systemet inte hamnar i oers\u00e4ttbar swap. Efter varje \u00e4ndring kontrollerar jag om tr\u00e4fffrekvensen fortfarande st\u00e4mmer och om applikationerna reagerar snabbare. Om l\u00e4sprestandan f\u00f6rblir h\u00f6g och flaskhalsarna f\u00f6rsvinner bekr\u00e4ftar jag v\u00e4rdena och noterar <strong>Anledning<\/strong>. Denna dokumentation \u00e4r till stor hj\u00e4lp n\u00e4r det g\u00e4ller framtida kapacitetsfr\u00e5gor.<\/p>\n\n<h2>Komprimerad ARC och finjustering av prefetch<\/h2>\n\n<p>M\u00e5nga arbetsbelastningar drar nytta av <strong>Komprimerad ARC<\/strong>: ZFS lagrar data komprimerade i cachen och dekomprimerar dem f\u00f6rst n\u00e4r de anv\u00e4nds. Det sparar RAM-minne och \u00f6kar den effektiva cachekapaciteten. Jag beh\u00e5ller d\u00e4rmed <strong>CPU<\/strong>-Belastningen i \u00e5tanke \u2013 i system som \u00e4r mycket CPU-beroende \u00e4r det inte alltid s\u00e5 att f\u00f6rdelarna \u00f6verv\u00e4ger. F\u00f6r att tydligt <strong>komprimerbara<\/strong> F\u00f6r data (loggar, text, VM-avbilder med l\u00e5g entropi) \u00e4r effekten oftast tydlig. Dessutom beaktar <strong>ZFS-f\u00f6rh\u00e4mtning<\/strong> (zfetch) letar efter sekventiella m\u00f6nster och f\u00f6rladdar efterf\u00f6ljande block. Vid l\u00e5nga str\u00f6mavl\u00e4sningar, som jag \u00e4nd\u00e5 inte vill cacha (s\u00e4kerhetskopior, mediepipelines), anv\u00e4nder jag primarycache fr\u00e4mst f\u00f6r metadata enligt beskrivningen och l\u00e5ter zfetch i \u00f6vrigt hantera <strong>Standardinst\u00e4llningar<\/strong>. Att helt st\u00e4nga av prefetch leder ofta till fler missar vid blandad belastning och \u00e4r f\u00f6r mig undantaget, inte regeln.<\/p>\n\n<h2>Genomf\u00f6ra best\u00e4ndiga inst\u00e4llningar p\u00e5 ett s\u00e4kert s\u00e4tt<\/h2>\n\n<p>Jag fastst\u00e4ller gr\u00e4nsv\u00e4rden f\u00f6r ARC <strong>ih\u00e5llande<\/strong>, s\u00e5 att de bevaras \u00e4ven efter omstarter, och \u00e4ndra dem endast i f\u00f6rsiktiga steg. \u00d6kningar \u00e4r inte kritiska, systemet utnyttjar det extra utrymmet gradvis. <strong>S\u00e4nkningar<\/strong> kan tillf\u00e4lligt leda till \u00f6kad eviction och mer I\/O \u2013 d\u00e4rf\u00f6r s\u00e4nker jag v\u00e4rdena i steg om 10\u201320-% och \u00f6vervakar systemet i 24\u201348 timmar. Efter st\u00f6rre ombyggnader eller uppdateringar av k\u00e4rnan\/ZFS kontrollerar jag om v\u00e4rdena fortfarande \u00e4r rimliga, eftersom automatiska heuristiker kan f\u00f6r\u00e4ndras med nya versioner <strong>F\u00f6r\u00e4ndring<\/strong>.<\/p>\n\n<h2>Anv\u00e4nd L2ARC p\u00e5 ett smart s\u00e4tt<\/h2>\n\n<p>L2ARC p\u00e5 SSD\/NVMe ut\u00f6kar cachen och ger en m\u00e4rkbar f\u00f6rb\u00e4ttring, s\u00e4rskilt vid stora datam\u00e4ngder som l\u00e4mpar sig v\u00e4l f\u00f6r cachning <strong>Tryckkraft<\/strong>. Jag anv\u00e4nder den f\u00f6rst n\u00e4r m\u00e4tv\u00e4rdena visar att RAM-ARC kontinuerligt k\u00f6rs p\u00e5 gr\u00e4nsen och att flash-sidan fortfarande har utrymme. Viktigt: L2ARC ers\u00e4tter inte RAM, eftersom metadata f\u00f6r de cachade blocken m\u00e5ste lagras i huvud-ARC <strong>stanna<\/strong>. En mycket stor L2ARC \u00f6kar d\u00e4rf\u00f6r RAM-behovet och kan till och med orsaka prestandaf\u00f6rs\u00e4mringar vid en ol\u00e4mplig konfiguration. Skrivning till L2ARC kr\u00e4ver I\/O-bandbredd och <strong>CPU<\/strong>, det ser jag inte \u00f6ver.<\/p>\n\n<p>L2ARC fungerar bra n\u00e4r arbetsvolymen \u00e4r st\u00f6rre \u00e4n RAM-minnet, men g\u00e4ller filer av samma typ om och om igen, till exempel VM-avbildningar eller m\u00e5nga sm\u00e5 <strong>objekt<\/strong>. Innan jag g\u00f6r \u00e4ndringarna kontrollerar jag med hj\u00e4lp av I\/O-statistik om flash-sidan har ledig kapacitet och inte redan ligger p\u00e5 gr\u00e4nsen. Om dessa f\u00f6ruts\u00e4ttningar st\u00e4mmer ger L2ARC ofta genomg\u00e5ende l\u00e4gre latenser. Det \u00e4r f\u00f6rst kombinationen av noggrann \u00f6vervakning, tillr\u00e4cklig RAM-reserv och en korrekt dimensionerad L2ARC som ger den \u00f6nskade <strong>Effekt<\/strong>. Att bara l\u00e4gga till st\u00f6rre SSD-enheter l\u00f6ser s\u00e4llan de verkliga flaskhalsarna.<\/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\/ZFS_ARC_Cache_Office_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>L2ARC-detaljer: Uppv\u00e4rmningsfas och best\u00e4ndighet<\/h2>\n\n<p>L2ARC har en <strong>Uppv\u00e4rmningsfas<\/strong>: Direkt efter att den skapats eller efter en omstart \u00e4r den f\u00f6rst tom respektive \u00e4nnu inte fullt anv\u00e4ndbar. Moderna implementeringar kan lagra metadata permanent, s\u00e5 att L2ARC snabbare \u00e5ter <strong>verk<\/strong>. \u00c4nd\u00e5 tar fyllningen tid och kr\u00e4ver I\/O-bandbredd. Jag stryper inte fl\u00f6det i on\u00f6dan, men l\u00e4mnar tillr\u00e4ckliga reserver f\u00f6r prim\u00e4ra arbetsbelastningar. S\u00e4rskilt viktigt: L2ARC b\u00f6r inte belasta samma SSD-enheter som logg- eller transaktionsarbetsbelastningar. Egna enheter med l\u00e5g latens och en realistiskt ber\u00e4knad RAM-andel f\u00f6r L2ARC-<strong>Huvud<\/strong> \u00e4r obligatoriska.<\/p>\n\n<h2>Inst\u00e4llningar f\u00f6r dataset: primarycache och secondarycache<\/h2>\n\n<p>Jag finjusterar cachen via dataset-inst\u00e4llningarna s\u00e5 att ARC och L2ARC h\u00e4mtar r\u00e4tt inneh\u00e5ll <strong>h\u00e5ll<\/strong>. primarycache styr om data och\/eller metadata ska lagras i huvud-ARC, medan secondarycache best\u00e4mmer inneh\u00e5llet f\u00f6r L2ARC. Vid stora, sekventiella str\u00f6mmar (till exempel mediearkiv) r\u00e4cker det ofta att lagra metadata i ARC och inte lagra sj\u00e4lva datastr\u00f6mmen i <strong>Buffert<\/strong>. Vid arbetsbelastningar med mycket metadata lagrar jag data och metadata i cache f\u00f6r att minska latensen. Denna \u00e5tskillnad f\u00f6rhindrar sl\u00f6seri och st\u00e4rker de relevanta <strong>Tilltr\u00e4den<\/strong>.<\/p>\n\n<p>Jag testar varje dataset specifikt, ist\u00e4llet f\u00f6r att till\u00e4mpa samma regel generellt f\u00f6r alla pooler <strong>st\u00e4lla in<\/strong>. En korrekt inst\u00e4lld primarycache\/secondarycache minskar on\u00f6dig I\/O och h\u00f6jer tr\u00e4fffrekvensen. Sammantaget leder detta ofta till ett stabilare system med mer f\u00f6ruts\u00e4gbara svarstider. \u00c4ven h\u00e4r g\u00e4ller: m\u00e4ta, justera, upprepa <strong>m\u00e5tt<\/strong>. Det \u00e4r ofta de sm\u00e5 justeringarna som ger den avg\u00f6rande finputsningen.<\/p>\n\n<h2>S\u00e4rskilt fall: deduplicering (DDT) och RAM-behov<\/h2>\n\n<p>Aktivera <strong>Deduplicering<\/strong>, \u00f6kar minnesbehovet m\u00e4rkbart eftersom dedupliceringstabellen (DDT) m\u00e5ste h\u00e5llas i RAM-minnet f\u00f6r att f\u00f6rbli effektiv. Metadata genereras f\u00f6r varje unikt block; med typiska blockstorlekar summeras detta snabbt till flera gigabyte. Om RAM-minnet inte r\u00e4cker till flyttar ZFS DDT-\u00e5tkomsten till h\u00e5rddiskarna, vilket \u00f6kar latensen och tr\u00e4nger undan ARC. Min tumregel: Aktivera deduplicering endast d\u00e4r h\u00f6g redundans \u00e4r s\u00e4kerst\u00e4lld (t.ex. VDI, identiska VM-avbildningar) och d\u00e4r det finns tillr\u00e4ckligt med <strong>RAM<\/strong> finns tillg\u00e4ngligt. Annars \u00e4r <strong>Kompression<\/strong> ofta det klart b\u00e4ttre verktyget.<\/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\/zfs_arc_cache_9823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>\u00d6vervakning och fels\u00f6kning<\/h2>\n\n<p>F\u00f6r att s\u00e4kerst\u00e4lla en stabil drift kontrollerar jag l\u00f6pande ARC-storlek, tr\u00e4fffrekvens, I\/O-profiler och de systemomfattande <strong>F\u00f6rvaringsbelastning<\/strong>. Om ARC st\u00e4ndigt ligger p\u00e5 gr\u00e4nsen utan att applikationerna p\u00e5verkas negativt, l\u00e5ter jag den ha utrymme. Om jag ser att det f\u00f6rekommer swapping eller att det g\u00e5r mot OOM, begr\u00e4nsar jag utrymmet och analyserar de fr\u00e4msta orsakerna. Det \u00e4r dessutom bra att ta en titt p\u00e5 <a href=\"https:\/\/webhosting.de\/sv\/vm-vfs-cache-belastning-linux-filsystem-cache-justering-optimering\/\">vm.vfs_cache_tryck<\/a>, f\u00f6r att ber\u00e4kna f\u00f6rh\u00e5llandet mellan dentry-\/inode-cachen och det \u00f6vriga minnet <strong>balans<\/strong>. Jag betraktar v\u00e4rdena i sitt sammanhang, aldrig isolerat.<\/p>\n\n<p>Verktyg som arcstat\/arc_summary, zpool, iostat samt top\/htop\/free\/vmstat ger mig den information jag beh\u00f6ver <strong>indicium<\/strong>. Jag j\u00e4mf\u00f6r toppar med arbetsf\u00f6nster och kontrollerar om problemen g\u00e5r att \u00e5terskapa. Om flaskhalsen uppst\u00e5r upprepade g\u00e5nger justerar jag tidsf\u00f6nster, begr\u00e4nsningar eller cachegr\u00e4nser. Om kurvan planar ut och applikationerna f\u00f6rblir snabba beh\u00e5ller jag <strong>Inst\u00e4llning<\/strong>. P\u00e5 s\u00e5 s\u00e4tt bygger jag upp erfarenheter under veckor och m\u00e5nader, ist\u00e4llet f\u00f6r att bara reagera p\u00e5 \u00f6gonblicksbilder.<\/p>\n\n<h2>Att skilja mellan ARC, Dirty Data och ZIL\/SLOG<\/h2>\n\n<p>En del av helhetsbilden \u00e4r att f\u00f6rutom ARC \u00e4ven <strong>Felaktiga data<\/strong> (\u00e4ndrade block som \u00e4nnu inte har skrivits till skivorna) upptar RAM-minne. Detta omr\u00e5de v\u00e4xer upp till en \u00f6vre gr\u00e4ns och t\u00f6ms sedan asynkront. Vid h\u00f6g skrivbelastning kan \u201dDirty Data\u201d tillf\u00e4lligt bli stort och bromsa systemet innan ZFS reagerar med begr\u00e4nsningsmekanismer. Dessutom buffrar <strong>ZIL<\/strong> (ZFS Intent Log) synkrona skrivningar; en snabb SLOG hj\u00e4lper, men minskar inte ARC:s RAM-f\u00f6rbrukning. Jag g\u00f6r en tydlig \u00e5tskillnad mellan dessa aspekter: M\u00e4rkbara skrivf\u00f6rdr\u00f6jningar trots en bra tr\u00e4fffrekvens tyder ofta p\u00e5 flaskhalsar i form av smutsiga data eller loggar snarare \u00e4n p\u00e5 en f\u00f6r stor <strong>ARC<\/strong> d\u00e4r.<\/p>\n\n<h2>M\u00e4tmetodik: tidsf\u00f6nster och trendanalys<\/h2>\n\n<p>Eftersom m\u00e5nga ZFS-r\u00e4knare har ackumulerats sedan <strong>B\u00e5t<\/strong> N\u00e4r de k\u00f6rs utv\u00e4rderar jag dem inom ett dygns- eller veckof\u00f6nster. Jag ber\u00e4knar frekvenser (tr\u00e4ffar\/s, missar\/s) och j\u00e4mf\u00f6r dem med I\/O-v\u00e4ntetider och CPU-belastning. Efter st\u00f6rre konfigurations\u00e4ndringar \u201enollst\u00e4ller\u201c jag mina j\u00e4mf\u00f6relsev\u00e4rden eller markerar tidpunkten s\u00e5 att effekterna kan tillskrivas korrekt. Jag utv\u00e4rderar tr\u00e4fffrekvensen per arbetsbelastningsf\u00f6nster (produktionsk\u00e4rntid, nattf\u00f6nster, batchk\u00f6rningar) \u2013 annars d\u00f6ljer ett enda sammanlagt tal de verkliga <strong>Flaskhalsar<\/strong>.<\/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\/zfs-arc-serverraum-4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktiskt exempel: Allround-server med 64 GB RAM<\/h2>\n\n<p>En server med en blandning av webbapplikationer, databaser och s\u00e4kerhetskopior tar snabbt upp 30\u201340 GB utan noggrann finjustering <strong>ARC<\/strong>. Databasen kr\u00e4ver dock en hel del eget RAM-minne, s\u00e5 jag st\u00e4ller in zfs_arc_max p\u00e5 cirka 24\u201328 GB och zfs_arc_min p\u00e5 8\u201312 GB. Efter n\u00e5gra dagar m\u00e4rker jag l\u00e4gre andel swap och stabilare latenser, medan ofta anv\u00e4nda data fortfarande finns i cachen <strong>ligga<\/strong>. Systemet k\u00e4nns snabbare eftersom trycktoppar inte l\u00e4ngre intr\u00e4ffar samtidigt i databasen och ARC. Denna m\u00e5ttliga avmattning uppr\u00e4tth\u00e5ller genomstr\u00f6mningen och f\u00f6rb\u00e4ttrar svarstiden m\u00e4rkbart i <strong>dagliga verksamhet<\/strong>.<\/p>\n\n<p>I n\u00e4sta steg optimerar jag datam\u00e4ngderna: F\u00f6r stora sekventiella s\u00e4kerhetskopior minskar jag andelen ren data i ARC och prioriterar metadata <strong>till<\/strong>. Tr\u00e4fffrekvensen \u00e4r fortfarande tillfredsst\u00e4llande, samtidigt som belastningen p\u00e5 RAM minskar under nattperioderna. N\u00e4r ombyggnaden \u00e4r klar kommer jag att f\u00f6lja utvecklingen i \u00f6vervakningssystemet och ingripa endast vid ih\u00e5llande <strong>Trender<\/strong>. L\u00e5ngsiktig stabilitet sl\u00e5r kortsiktiga j\u00e4mf\u00f6relsev\u00e4rden i produktionsmilj\u00f6er. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir cachen en vinstk\u00e4lla och ingen anledning till oro eller h\u00e5rda <strong>Strypning<\/strong>.<\/p>\n\n<h2>Kortfattat sammanfattat<\/h2>\n\n<p>Jag tolkar ARC:s h\u00f6ga minnesf\u00f6rbrukning som ett tecken p\u00e5 aktiv <strong>Anv\u00e4nd<\/strong> och inte som en brist. ZFS frig\u00f6r cachen vid behov, medan zfs_arc_max och zfs_arc_min tydligt avgr\u00e4nsar intervallet <strong>Definiera<\/strong>. Setups blir f\u00f6rst meningsfulla genom l\u00e4mpliga nyckeltal som tr\u00e4fffrekvens, ARC-storlek och I\/O-profiler. L2ARC och dataset-alternativ ger mig ytterligare verktyg n\u00e4r RAM-minnet b\u00f6rjar ta slut eller datam\u00e4ngderna blir betydligt st\u00f6rre <strong>\u00e4r<\/strong>. Den som f\u00f6ljer dessa grundprinciper kan anv\u00e4nda ZFS p\u00e5 l\u00e5ng sikt p\u00e5 ett snabbt, resurssn\u00e5lt och tillf\u00f6rlitligt s\u00e4tt <strong>Svarstid<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e4r dig hur ZFS ARC-cachen fungerar, varf\u00f6r h\u00f6g RAM-anv\u00e4ndning \u00e4r normalt och hur du st\u00e4ller in minnesanv\u00e4ndningen p\u00e5 r\u00e4tt s\u00e4tt f\u00f6r att f\u00f6rb\u00e4ttra ZFS-prestandan.<\/p>","protected":false},"author":1,"featured_media":21080,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21087","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":"135","_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":"ZFS ARC","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":"21080","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/21087","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=21087"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/21087\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/21080"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=21087"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=21087"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=21087"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}