{"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-geheugengebruik-uitleg-tuning-io","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/zfs-arc-cache-speicherverbrauch-erklaerung-tuning-io\/","title":{"rendered":"ZFS ARC-cache: het geheugengebruik goed begrijpen"},"content":{"rendered":"<p><strong>ZFS ARC<\/strong> maakt intensief gebruik van RAM om vaak gelezen blokken snel beschikbaar te maken en daarbij het daadwerkelijke geheugengebruik dynamisch aan te passen aan de belasting. Ik leg uit hoe ik het ogenschijnlijk hoge verbruik op de juiste manier interpreteer, welke statistieken van belang zijn en hoe ik de cachegrootte veilig beheer, zonder <strong>Prestaties<\/strong> te verliezen.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<p>Om snel een overzicht te krijgen, vat ik de belangrijkste punten samen en markeer ik cruciale trefwoorden voor een duidelijk <strong>Overzicht<\/strong>.<\/p>\n<ul>\n  <li><strong>ARC-maat<\/strong>: Dynamisch, instelbaar via zfs_arc_max\/min<\/li>\n  <li><strong>Terugvorderbaar<\/strong>: Cache-RAM wordt indien nodig onmiddellijk vrijgegeven<\/li>\n  <li><strong>Trefkans<\/strong>: Een hoge hit-ratio wijst op een zinvol gebruik van de cache<\/li>\n  <li><strong>L2ARC<\/strong>: Aanvulling op SSD\/NVMe, geen vervanging voor RAM<\/li>\n  <li><strong>Regels voor datasets<\/strong>: primarycache\/secondarycache nauwkeurig afstemmen<\/li>\n<\/ul>\n<p>Ik pas deze punten in het dagelijks leven toe om leeswegen kort te houden en het geheugen eerlijk te <strong>delen<\/strong>. Een volle ARC duidt op actief gebruik en niet op een defect of een verborgen <strong>Lek<\/strong>. Pas wanneer er swapping of OOM-gebeurtenissen optreden, stel ik duidelijke grenzen. Daarna controleer ik de wijzigingen aan de hand van meetwaarden en pas ik stapsgewijs de <strong>Frame<\/strong>. Zo houd ik systemen soepel draaiend, zonder andere diensten te vertragen of riskante overhaaste beslissingen te nemen <strong>kiezen<\/strong>.<\/p>\n\n<h2>Wat de ARC in het geheugen eigenlijk doet<\/h2>\n\n<p>De ARC is een adaptieve leescache en combineert <strong>MRU<\/strong> (recent gebruikt) met <strong>MFU<\/strong> (vaak gebruikt). Deze mix past zich automatisch aan het patroon aan dat mijn workloads genereren en houdt precies die blokken beschikbaar die het grootste effect opleveren. Hierdoor nemen de latenties merkbaar af, omdat de gegevens rechtstreeks uit het RAM worden opgehaald en niet vanuit <strong>platen<\/strong> of SSD\u2019s. Ik profiteer vooral bij herhaalde toegangen, want het succespercentage stijgt met elke overeenkomende <strong>Aanvraag<\/strong>. Vooral bij VM-images, databases en veel kleine bestanden komt de cache goed tot zijn recht.<\/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>Juist door deze werkwijze lijkt het RAM-geheugen \u201evol\u201c, hoewel ik nog steeds <strong>Reserves<\/strong> heb. De bezette cache kan op elk moment worden vrijgegeven zodra processen geheugen aanvragen. Zo maakt het systeem actief gebruik van onbenutte capaciteit, in plaats van deze ongebruikt te laten, en houdt het pieken in de belasting toch onder <strong>Controle<\/strong>. Wie een directe vergelijking van bestandssystemen interessant vindt, kan mijn beknopte <a href=\"https:\/\/webhosting.de\/nl\/ext4-xfs-zfs-hosting-prestaties-vergelijking-opslag\/\">Prestatievergelijking<\/a> . Daar laat ik zien waarom een slimme cache bij re\u00eble werklast vaak een grotere rol speelt dan louter <strong>Theorie<\/strong>.<\/p>\n\n<h2>Waarom een hoog RAM-gebruik wenselijk is<\/h2>\n\n<p>Ik beschouw een \u201evol\u201c RAM-geheugen bij de ARC als positief, zolang het systeem niet met een daadwerkelijk geheugentekort te kampen heeft <strong>lijdt<\/strong>. ZFS maakt cachegeheugen onmiddellijk vrij wanneer applicaties groeien en past de doelgrootte voortdurend aan. In gangbare tools wordt dit RAM-geheugen als \u201ebezet\u201c weergegeven, hoewel het zonder vertraging beschikbaar is voor nieuwe processen <strong>Dispositie<\/strong> staat. Een echte bottleneck komt pas aan het licht door swapping, merkbare vertragingen of OOM-killer-activiteit. Om dit beter te begrijpen, helpt het om eens te kijken naar <a href=\"https:\/\/webhosting.de\/nl\/linux-transparante-paginacache-verschillen-tussen-paginacaches-optimalisatie-gegevenscache\/\">Verschillen in de paginacache<\/a>, omdat de cache van het besturingssysteem en de ARC met elkaar verweven zijn en beide het zichtbare verbruik <strong>vormen<\/strong>.<\/p>\n\n<p>De context is daarom doorslaggevend, niet een enkele schermafbeelding van een monitoringtool met \u201e0 GB vrij\u201c als <strong>Angst<\/strong>. Daarnaast controleer ik de I\/O-wachttijden, de ontwikkeling van het swapgeheugen en de belastingprofielen van de belangrijkste diensten. Als deze waarden normaal blijken te zijn, geef ik de ARC de ruimte om terugkerende leesbewerkingen maximaal te <strong>versnellen<\/strong>. Als er knelpunten ontstaan, verhoog ik de bovengrenzen enigszins, in plaats van de ARC drastisch te <strong>afsnijden<\/strong>. Zo blijft het evenwicht tussen de voordelen van caching en de behoeften van de toepassing behouden.<\/p>\n\n<h2>Hoe ZFS de ARC-grootte bepaalt<\/h2>\n\n<p>Zonder instellingen stelt ZFS een redelijke bovengrens in op basis van de beschikbare <strong>RAM<\/strong>. Ik stuur deze dynamiek aan met twee parameters: <strong>zfs_arc_max<\/strong> als bovengrens en <strong>zfs_arc_min<\/strong> als ondergrens. Als zfs_arc_max op 0 staat of niet is ingesteld, kiest ZFS automatisch een geschikt bereik, vaak ongeveer de helft van de <strong>geheugen<\/strong>. Bij piekbelastingen krimpt de ARC, maar niet onder zfs_arc_min, zodat belangrijke blokken in het RAM blijven. Als ik de limieten te krap instel, daalt het hitpercentage en keert lees-I\/O vaker terug naar de <strong>Plaat<\/strong> terug.<\/p>\n\n<p>In de praktijk betekent dit: veel RAM maakt een grote cache mogelijk, wat bij databases en VM-hosting een groot <strong>werkt<\/strong>. Als er onvoldoende opslagruimte is voor andere diensten, beperk ik zfs_arc_max bewust en houd ik zfs_arc_min flexibel. Ik test in fasen, observeer de effecten en pas de instellingen aan op basis van werkelijke trendwaarden. Zo voorkom ik dat een eenmalige piek de <strong>Configuratie<\/strong> domineert. Een stapsgewijze aanpassing leidt tot betrouwbaar gedrag zonder vervelende <strong>Verrassingen<\/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>ARC-kerncijfers correct interpreteren<\/h2>\n\n<p>Om een beeld te krijgen, bekijk ik regelmatig de belangrijkste statistieken en breng ik de verbanden in kaart in een overzichtelijke <strong>Tabel<\/strong> vast. Tools zoals arcstat of arc_summary leveren voortdurend gegevens die ik koppel aan pool-I\/O en applicatiestatistieken. Daarbij is het totaalbeeld belangrijker dan een enkele uitschieter in de <strong>Diagram<\/strong>. Juist de verhouding tussen hits en misses laat zien of de cache de werklast op een zinvolle manier afdekt. Hoge hitpercentages duiden op stabiele prestaties en korte leeswegen in de <strong>RAM<\/strong> daar.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Sleutelfiguur<\/th>\n      <th>Beschrijving<\/th>\n      <th>Waar ik op let<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>ARC-grootte<\/td>\n      <td>Huidige cachegrootte in de <strong>RAM<\/strong><\/td>\n      <td>Groeit onder belasting, krimpt merkbaar wanneer dat nodig is<\/td>\n    <\/tr>\n    <tr>\n      <td>ARC c \/ c_max<\/td>\n      <td>Doelwaarde en maximale doelwaarde<\/td>\n      <td>Nadering van c_max bij hoge belasting, lucht in rusttoestand<\/td>\n    <\/tr>\n    <tr>\n      <td>Successen \/ Mislukkingen<\/td>\n      <td>Treffers of missers sinds <strong>Start<\/strong><\/td>\n      <td>Blijft de belasting hoog? Controleer de werklast of het cachebeleid<\/td>\n    <\/tr>\n    <tr>\n      <td>hitratio<\/td>\n      <td>Hits ten opzichte van het totale aantal bezoeken in <strong>%<\/strong><\/td>\n      <td>Veel herhalingen: 80\u201390 % is realistisch, anders minder<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Op basis van deze waarden neem ik concrete maatregelen: als de hit-ratio laag blijft, terwijl er voldoende vrij RAM is, verhoog ik voorzichtig de waarde van zfs_arc_max en houd ik de <strong>Trends<\/strong>. Als applicaties onder druk staan, verlaag ik de limiet en meet ik de latentie en de I\/O-belasting opnieuw. Als een grotere cache geen verlichting biedt, is er vaak sprake van een zeer willekeurig toegangs patroon, waardoor caching minder goed werkt <strong>serveert<\/strong>. Dan hebben andere maatregelen, zoals een betere gegevenslocatie of het verdelen van de werklast, meestal een groter effect. Het louter vergroten van de cache lost niet elk probleem op <strong>Probleem<\/strong>.<\/p>\n\n<h2>Hoe de ARC beslissingen neemt: \u2018ghost-lijsten\u2019 en aanpassing<\/h2>\n\n<p>Naast <strong>MRU<\/strong> en <strong>MFU<\/strong> maakt de ARC gebruik van zogenaamde <strong>Ghost-lijsten<\/strong> (MRU-\/MFU-Ghost). Ze bevatten uitsluitend metagegevens van blokken die onlangs zijn verdrongen. Als precies deze blokken kort na het verdringen weer opduiken, interpreteert ZFS dit als een aanwijzing dat het betreffende gebied te klein was, en verplaatst het capaciteit tussen MRU en MFU. Zo <strong>leert<\/strong> de cache wordt actief bijgesteld op basis van verkeerde inschattingen. In de praktijk betekent dit: schommelende patronen (bijvoorbeeld batchvensters \u2019s avonds) worden na enkele cycli beter verwerkt, zonder dat ik handmatig hoef in te grijpen.<\/p>\n\n<p>In dit verband let ik vooral op of er fouten in golven voorkomen en of het slagingspercentage daarna zichtbaar is <strong>trekt aan<\/strong>. Als dat gebeurt, werkt de ARC-logica zoals bedoeld. Als het aantal missers ondanks herhalingen hoog blijft, is de werk set vaak groter dan de beschikbare cache of zijn de toegangspatronen te <strong>willekeurige<\/strong>.<\/p>\n\n<h2>Wanneer de ARC daadwerkelijk storend is<\/h2>\n\n<p>Bij shared hosting deel ik opslagruimte met veel andere diensten; een dominante ARC kan dan de ruimte inperken en swapping veroorzaken <strong>bevorderen<\/strong>. Beheerders van virtualisatiehosts kennen deze spagaat: elke VM kan wel wat extra RAM gebruiken, terwijl ZFS ook cache-bronnen wil benutten. Op kleine systemen met slechts enkele gigabyte houd ik de limieten strakker, zodat de responstijd van de diensten niet onder druk komt te staan <strong>apparaat<\/strong>. Problemen worden merkbaar door trage applicaties, een toename van het gebruik van swapruimte of waarschuwingen van de OOM-killer. In dergelijke situaties stel ik duidelijke bovengrenzen in en geef ik het systeem daarna een paar dagen de tijd om <strong>Vergelijkingen<\/strong>.<\/p>\n\n<p>Ik noteer symptomen, tijdstippen en de betrokkenen <strong>Diensten<\/strong>. Als de bottleneck steeds weer in dezelfde tijdsvensters optreedt, plan ik aanpassingen zoals back-upvensters, het afremmen van indexeringen of het uitstellen van grote scans. Pas als organisatorische maatregelen de piek niet kunnen opvangen, pas ik de techniek en de limieten aan <strong>op<\/strong>. Deze volgorde biedt speelruimte en voorkomt overhaaste ingrepen in gevoelige productieomgevingen. Zo blijft het overzicht behouden over de wisselwerking tussen cache, I\/O en applicaties <strong>duidelijk<\/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>Containers, cgroups en NUMA-bijzonderheden<\/h2>\n\n<p>In containeromgevingen geldt het volgende: de ARC is <strong>op de hele host<\/strong> en niet beperkt door cgroups. Als een pod\/container zijn geheugenlimiet bereikt, beschermt dat hem niet tegen het feit dat de host onder druk komt te staan door ARC en andere processen. Daarom reserveer ik op de host een vaste buffer voor systeemdiensten en ZFS en stel ik de containerlimieten zo in dat het fysieke RAM-geheugen niet tot het uiterste wordt benut. Op NUMA-systemen let ik er bovendien op dat intensieve cross-node-toegang wordt vermeden, omdat anders de latentie toeneemt. Een gelijkmatige verdeling van grote VM\u2019s en een realistische ARC-limiet per <strong>Gastheer<\/strong> voorkomen hier veel verrassingen.<\/p>\n\n<h2>Best practices voor de dimensionering<\/h2>\n\n<p>Op speciale bestandsservers wijs ik de ARC graag 60\u201380 % aan RAM toe, omdat andere processen weinig geheugen gebruiken <strong>vraag<\/strong>. Als er daarnaast een stack met containers of kleinere diensten draait, begin ik met 50\u201360 % en houd ik de dynamische belasting in de gaten. Op hypervisors stel ik vaak 30\u201340 % in, zodat VM\u2019s voldoende eigen RAM hebben <strong>hebben<\/strong>. Ik stel zfs_arc_min meestal in op 25\u201350 % van zfs_arc_max, zodat de cache bij piekbelastingen nog kan krimpen. Ik voer wijzigingen stapsgewijs door en analyseer de meetwaarden over een periode van meerdere dagen <strong>van<\/strong>.<\/p>\n\n<p>Ik houd rekening met buffers voor pieken, in plaats van de bovengrens tot op het uiterste te benutten <strong>naaien<\/strong>. Voor schrijfvensters, back-ups of het opnieuw indexeren laat ik bewust ruimte over, zodat het systeem niet in onvermijdelijk swappen terechtkomt. Na elke wijziging controleer ik of de hit-ratio nog steeds klopt en of applicaties sneller reageren. Als de leesprestaties hoog blijven en knelpunten verdwijnen, bevestig ik de waarden en noteer ik de <strong>Reden<\/strong>. Deze documentatie is van groot nut bij toekomstige capaciteitsvraagstukken.<\/p>\n\n<h2>ARC-compressie en fijnafstemming van prefetch<\/h2>\n\n<p>Veel workloads profiteren van de <strong>Gecomprimeerde ARC<\/strong>: ZFS slaat gegevens gecomprimeerd op in de cache en decomprimeert ze pas wanneer ze worden opgevraagd. Dit bespaart RAM en vergroot de effectieve cachecapaciteit. Ik behoud daarbij de <strong>CPU<\/strong>-Belasting in het oog houden \u2013 bij systemen die sterk afhankelijk zijn van de CPU weegt het voordeel niet altijd op tegen de nadelen. Voor duidelijk <strong>comprimeerbaar<\/strong> Bij gegevens (logbestanden, tekst, VM-images met weinig entropie) is het effect meestal duidelijk merkbaar. Daarnaast let de <strong>ZFS-prefetch<\/strong> (zfetch) zoekt naar sequenti\u00eble patronen en laadt blokken vooraf in. Bij lange stream-reads, die ik sowieso niet in de cache wil opslaan (back-ups, mediapijplijnen), richt ik primarycache zoals beschreven vooral op metadata en laat ik zfetch verder de <strong>Standaard<\/strong>. Het abrupt uitschakelen van prefetch leidt vaak tot meer misses bij gemengde werklasten en is voor mij eerder uitzondering dan regel.<\/p>\n\n<h2>Permanente instellingen veilig doorvoeren<\/h2>\n\n<p>Ik stel de grenswaarden voor de ARC vast <strong>hardnekkig<\/strong>, zodat ze na een herstart behouden blijven, en pas ze alleen in voorzichtige stappen aan. Verhogingen zijn niet kritisch; het systeem maakt de extra ruimte geleidelijk aan gebruik. <strong>Verlaagingen<\/strong> kunnen tijdelijk leiden tot meer eviction en meer I\/O \u2013 daarom verlaag ik de waarden in stappen van 10\u201320-% en houd ik de situatie 24\u201348 uur in de gaten. Na grote aanpassingen of kernel-\/ZFS-updates controleer ik of de waarden nog steeds aannemelijk zijn, omdat automatische heuristieken bij nieuwe versies kunnen veranderen <strong>Verander<\/strong>.<\/p>\n\n<h2>L2ARC slim gebruiken<\/h2>\n\n<p>De L2ARC op SSD\/NVMe breidt de cache uit en zorgt vooral bij grote, goed in de cache op te slaan hoeveelheden gegevens voor een merkbare <strong>Stuwkracht<\/strong>. Ik gebruik het pas als uit de meetwaarden blijkt dat de RAM-ARC continu op zijn limiet draait en de flash-pagina nog ruimte over heeft. Belangrijk: L2ARC is geen vervanging voor RAM, want de metagegevens van de in de cache opgeslagen blokken moeten in de hoofd-ARC <strong>blijf<\/strong>. Een zeer grote L2ARC verhoogt daarom de benodigde RAM-capaciteit en kan bij een onjuiste configuratie zelfs tot vertraging leiden. Het schrijven naar de L2ARC kost I\/O-bandbreedte en <strong>CPU<\/strong>, dat zie ik wel.<\/p>\n\n<p>L2ARC werkt goed wanneer de hoeveelheid gegevens groter is dan het RAM-geheugen, maar het steeds weer om soortgelijke bestanden gaat, zoals VM-images of veel kleine <strong>objecten<\/strong>. Voordat ik de uitbreiding doorvoer, controleer ik aan de hand van I\/O-statistieken of de flash-pagina nog vrije capaciteit heeft en niet toch al tegen de limiet aan zit. Als aan deze voorwaarden is voldaan, levert L2ARC vaak constant lagere latenties op. Alleen de combinatie van nauwkeurige monitoring, voldoende RAM-reserve en een goed gedimensioneerde L2ARC levert het verhoopte resultaat op <strong>Effect<\/strong>. Het klakkeloos toevoegen van grotere SSD\u2019s lost zelden echte knelpunten op.<\/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-details: opwarmfase en persistentie<\/h2>\n\n<p>De L2ARC heeft een <strong>Opwarmfase<\/strong>: Direct na het aanmaken of na een herstart is hij aanvankelijk leeg of nog niet volledig bruikbaar. Moderne implementaties kunnen metadata permanent opslaan, zodat de L2ARC sneller weer <strong>werkt<\/strong>. Toch kost het vullen tijd en neemt het I\/O-bandbreedte in beslag. Ik beperk de feed niet onnodig, maar houd voldoende reserves over voor primaire workloads. Bijzonder belangrijk: de L2ARC mag niet dezelfde SSD\u2019s belasten als log- of transactionele workloads. Eigen apparaten met lage latentie en een realistisch berekend RAM-aandeel voor de L2ARC-<strong>Kop<\/strong> zijn verplicht.<\/p>\n\n<h2>Instellingen voor datasets: primarycache en secondarycache<\/h2>\n\n<p>Ik optimaliseer de cache via de dataset-opties, zodat ARC en L2ARC de juiste inhoud <strong>houd<\/strong>. primarycache bepaalt of gegevens en\/of metagegevens in de hoofd-ARC worden opgeslagen, terwijl secondarycache de inhoud voor de L2ARC vastlegt. Bij grote, sequenti\u00eble streams (bijvoorbeeld media-archieven) volstaat het vaak om metagegevens in de ARC te bewaren en de eigenlijke gegevensstroom niet te <strong>Buffer<\/strong>. Bij workloads met veel metadata sla ik gegevens en metadata op in de cache om de latentie te verminderen. Deze scheiding voorkomt verspilling en versterkt de relevante <strong>Toegang tot<\/strong>.<\/p>\n\n<p>Ik test per dataset gericht, in plaats van voor alle pools zonder onderscheid dezelfde regel toe te passen <strong>stel  in<\/strong>. Een correct ingestelde primarycache\/secondarycache vermindert onnodige I\/O en verhoogt de hitrate. Al met al leidt dit vaak tot een stabieler systeemgedrag met beter voorspelbare reactietijden. Ook hier geldt: meten, aanpassen, opnieuw <strong>maatregel<\/strong>. De kleine afstelschroeven zorgen vaak voor de beslissende laatste afwerking.<\/p>\n\n<h2>Het speciale geval van deduplicatie (DDT) en RAM-behoefte<\/h2>\n\n<p>Activeer <strong>Deduplicatie<\/strong>, neemt het geheugengebruik merkbaar toe, omdat de deduplicatietabel (DDT) in het RAM moet worden bewaard om effici\u00ebnt te blijven. Per uniek blok worden metagegevens gegenereerd; bij typische blokgroottes loopt dit al snel op tot meerdere gigabyte. Als er onvoldoende RAM beschikbaar is, verplaatst ZFS de DDT-toegangen naar de schijven, wat de latentie verhoogt en de ARC verdringt. Mijn vuistregel: schakel deduplicatie alleen in wanneer een hoge mate van redundantie gegarandeerd is (bijv. VDI, identieke VM-images) en er voldoende <strong>RAM<\/strong> beschikbaar is. Anders is <strong>Compressie<\/strong> vaak een veel betere hefboom.<\/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>Monitoring en probleemoplossing<\/h2>\n\n<p>Om een soepele werking te garanderen, controleer ik voortdurend de ARC-grootte, de hit-ratio, de I\/O-profielen en de systeembrede <strong>Opslaglading<\/strong>. Als de ARC constant op de limiet zit zonder dat applicaties daaronder lijden, geef ik hem de ruimte. Als ik swapping zie of een tendens naar OOM, beperk ik de ruimte en analyseer ik de belangrijkste oorzaken. Daarnaast is het nuttig om te kijken naar <a href=\"https:\/\/webhosting.de\/nl\/vm-vfs-cachebelasting-linux-bestandssysteem-cache-afstemming-optimalisatie\/\">vm.vfs_cache_druk<\/a>, om de verhouding tussen de dentry\/inode-cache en het overige geheugen te <strong>balans<\/strong>. Ik bekijk de waarden in hun onderlinge samenhang, nooit afzonderlijk.<\/p>\n\n<p>Tools zoals arcstat\/arc_summary, zpool, iostat en top\/htop\/free\/vmstat geven me de benodigde <strong>aanwijzingen<\/strong>. Ik vergelijk pieken met de werkvensters en controleer of de problemen zich herhaaldelijk voordoen. Als de bottleneck zich herhaaldelijk voordoet, pas ik de tijdvensters, beperkingen of cache-limieten aan. Als de curve afvlakt en de applicaties snel blijven, houd ik de <strong>Instelling<\/strong>. Zo doe ik in de loop van weken en maanden ervaring op, in plaats van alleen op momentopnames te reageren.<\/p>\n\n<h2>ARC, Dirty Data en ZIL\/SLOG van elkaar onderscheiden<\/h2>\n\n<p>Bij het totaalbeeld hoort dat naast de ARC ook <strong>Onbetrouwbare gegevens<\/strong> (gewijzigde blokken die nog niet naar de schijven zijn geschreven) RAM-geheugen in beslag. Dit gebied groeit tot een bovengrens en wordt vervolgens asynchroon leeggemaakt. Bij een hoge schrijfbelasting kan de hoeveelheid \u2018dirty data\u2019 tijdelijk groot worden en het systeem vertragen, voordat ZFS met beperkingsmechanismen reageert. Daarnaast buffert het <strong>ZIL<\/strong> (ZFS Intent Log) synchrone schrijfbewerkingen; een snelle SLOG helpt, maar vermindert het RAM-gebruik van de ARC niet. Ik maak een duidelijk onderscheid tussen deze aspecten: merkbare schrijflatenties ondanks een goede hitratio duiden vaak op knelpunten in de \u2018dirty data\u2019 of het logboek, in plaats van op een te grote <strong>ARC<\/strong> daar.<\/p>\n\n<h2>Meetmethode: tijdvensters en trendanalyse<\/h2>\n\n<p>Aangezien veel ZFS-tellers cumulatief zijn sinds de <strong>Boot<\/strong> Als ze draaien, analyseer ik ze binnen een dag- of weekvenster. Ik bereken de snelheden (hits\/s, misses\/s) en vergelijk deze met de I\/O-wachttijden en de CPU-belasting. Na grotere configuratiewijzigingen zet ik mijn vergelijkingswaarden op nul of markeer ik het tijdstip, zodat effecten duidelijk kunnen worden toegewezen. Ik beoordeel de hit-ratio per workload-venster (productie-piekuren, nachtvenster, batchruns) \u2013 \u00e9\u00e9n enkel totaalcijfer verhult anders de werkelijke <strong>Flessenhalzen<\/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>Praktijkvoorbeeld: Allround-server met 64 GB RAM<\/h2>\n\n<p>Een server met een mix van webapplicaties, een database en back-ups neemt zonder fijnafstemming al snel 30\u201340 GB in beslag <strong>ARC<\/strong>. De database heeft echter veel eigen RAM nodig, dus stel ik zfs_arc_max in op ongeveer 24\u201328 GB en zfs_arc_min op 8\u201312 GB. Na een paar dagen meet ik lagere swap-percentages en stabielere latenties, terwijl veelgebruikte gegevens nog steeds in de cache blijven <strong>leugen<\/strong>. Het systeem reageert snel, omdat pieken in de belasting niet meer gelijktijdig de database en ARC treffen. Deze gematigde afvlakking behoudt de doorvoer en verbetert de responstijd merkbaar in de <strong>dagelijkse gang van zaken<\/strong>.<\/p>\n\n<p>In de volgende stap optimaliseer ik datasets: bij grote sequenti\u00eble back-ups verminder ik het aandeel van de pure gegevens in de ARC en geef ik prioriteit aan metadata <strong>naar<\/strong>. De hit-ratio blijft op peil, terwijl de druk op het RAM-geheugen tijdens de nachtelijke periodes afneemt. Na voltooiing van de aanpassingen houd ik de ontwikkeling in de monitoring in de gaten en reageer ik alleen bij aanhoudende <strong>Trends<\/strong>. Duurzame stabiliteit presteert beter dan kortetermijnbenchmarks in productieomgevingen. Zo blijft de cache een bron van winst en geen reden tot ongerustheid of strenge <strong>Smoren<\/strong>.<\/p>\n\n<h2>Kort samengevat<\/h2>\n\n<p>Ik beschouw het hoge geheugenverbruik van de ARC als een teken van actieve <strong>Gebruik<\/strong> en niet als een minpunt. ZFS maakt de cache vrij wanneer dat nodig is, terwijl zfs_arc_max en zfs_arc_min de marge duidelijk <strong>Definieer<\/strong>. Setups worden pas echt zinvol door de juiste statistieken, zoals de hit-ratio, de ARC-grootte en I\/O-profielen. L2ARC en dataset-opties bieden mij extra mogelijkheden wanneer het RAM-geheugen schaars wordt of de gegevensvolumes aanzienlijk groter worden <strong>zijn<\/strong>. Wie deze basisprincipes ter harte neemt, kan ZFS op de lange termijn snel, zuinig en betrouwbaar gebruiken <strong>Reactietijd<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Ontdek hoe de ZFS ARC-cache werkt, waarom een hoog RAM-gebruik normaal is en hoe je het geheugengebruik op de juiste manier kunt instellen om de ZFS-prestaties te verbeteren.<\/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\/nl\/wp-json\/wp\/v2\/posts\/21087","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=21087"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21087\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/21080"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=21087"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=21087"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=21087"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}