{"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-memory-usage-explanation-tuning-io","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/zfs-arc-cache-speicherverbrauch-erklaerung-tuning-io\/","title":{"rendered":"ZFS ARC Cache: Understanding Memory Usage Correctly"},"content":{"rendered":"<p><strong>ZFS ARC<\/strong> It makes aggressive use of RAM to quickly make frequently accessed blocks available, while dynamically adjusting actual memory usage to the load. I\u2019ll explain how to correctly interpret the seemingly high memory usage, which metrics matter, and how to safely manage the cache size without <strong>Performance<\/strong> to lose.<\/p>\n\n<h2>Key points<\/h2>\n\n<p>To help you get your bearings quickly, I'll summarize the key points and highlight key terms to ensure clarity. <strong>Overview<\/strong>.<\/p>\n<ul>\n  <li><strong>ARC Size<\/strong>: Dynamic, controllable via zfs_arc_max\/min<\/li>\n  <li><strong>Reclaimable<\/strong>: Cache RAM is released immediately when needed<\/li>\n  <li><strong>Hit Rate<\/strong>: A high hit ratio indicates effective use of the cache<\/li>\n  <li><strong>L2ARC<\/strong>: Add-on for SSD\/NVMe, not a replacement for RAM<\/li>\n  <li><strong>Dataset Rules<\/strong>: Fine-tune primary cache\/secondary cache<\/li>\n<\/ul>\n<p>I use these tips in my daily life to keep reading paths short and optimize memory usage. <strong>share<\/strong>. A full ARC indicates active use and does not indicate a defect or a hidden <strong>Leak<\/strong>. Only when swapping or OOM events occur do I set clear limits. After that, I validate the changes using metrics and gradually adjust the <strong>Frame<\/strong>. That's how I keep systems running smoothly without slowing down other services or taking risky, hasty actions <strong>select<\/strong>.<\/p>\n\n<h2>What the ARC Actually Does in Memory<\/h2>\n\n<p>The ARC is an adaptive read cache and combines <strong>MRU<\/strong> (most recently used) with <strong>MFU<\/strong> (frequently used). This mix automatically adapts to the patterns generated by my workloads and makes available exactly the blocks that deliver the greatest impact. This noticeably reduces latency because accesses occur directly from RAM rather than from <strong>plates<\/strong> or SSDs. I benefit most from repetitive accesses, because the hit rate increases with every matching <strong>Request<\/strong>. The cache really comes into its own, especially with VM images, databases, and large numbers of small files.<\/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>It is precisely because of this way of working that the RAM appears to be \u201efull,\u201c even though I continue to <strong>Reserves<\/strong> have. The allocated cache can be released at any time as soon as processes request memory. In this way, the system actively utilizes idle capacity instead of leaving it unused, while still keeping peak loads below <strong>Control<\/strong>. If you're interested in a direct comparison of file systems, check out my concise <a href=\"https:\/\/webhosting.de\/en\/ext4-xfs-zfs-hosting-performance-comparison-storage\/\">Performance comparison<\/a> . There, I show why a smart cache often has a greater impact on real-world workloads than a simple <strong>Theory<\/strong>.<\/p>\n\n<h2>Why High RAM Usage Is Intended<\/h2>\n\n<p>I view \u201efull\u201c RAM in ARC as a positive thing, as long as the system isn't experiencing a real memory shortage <strong>suffers<\/strong>. ZFS immediately frees up cache memory as applications grow and continuously adjusts the target size. In typical tools, this RAM appears as \u201eused,\u201c even though it is available for new processes without delay. <strong>Disposition<\/strong> . A true bottleneck only becomes apparent through swapping, noticeable lag, or OOM killer activity. To better understand this, take a look at <a href=\"https:\/\/webhosting.de\/en\/linux-transparent-page-cache-page-cache-differences-optimization-data-cache\/\">Page Cache Differences<\/a>, because the operating system cache and ARC are interrelated and both affect the apparent consumption <strong>to shape<\/strong>.<\/p>\n\n<p>Therefore, the context is what matters, not a single screenshot from a monitoring tool showing \u201e0 GB free\u201c as <strong>Horror<\/strong>. I also check I\/O wait times, swap usage trends, and the load profiles of the main services. If these values appear normal, I give the ARC some leeway to maximize recurring read operations <strong>accelerate<\/strong>. If bottlenecks arise, I raise the upper limits moderately instead of tightening the ARC too much <strong>cap<\/strong>. This maintains the balance between caching benefits and application requirements.<\/p>\n\n<h2>How ZFS Determines the ARC Size<\/h2>\n\n<p>If no values are specified, ZFS sets a reasonable upper limit based on the available <strong>RAM<\/strong>. I control this dynamic using two parameters: <strong>zfs_arc_max<\/strong> as an upper limit and <strong>zfs_arc_min<\/strong> as the lower bound. If zfs_arc_max is set to 0 or is unset, ZFS automatically selects an appropriate range, often about half of the <strong>memory<\/strong>. During peak load, the ARC shrinks, but not below zfs_arc_min, so that important blocks remain in RAM. If I set the limits too tightly, the hit rate drops and read I\/O returns more frequently to the <strong>Plate<\/strong> back.<\/p>\n\n<p>In this context, \"practical\" means: A large amount of RAM allows for a large cache, which is particularly beneficial for databases and VM hosting <strong>works<\/strong>. If there isn't enough storage for other services, I deliberately limit `zfs_arc_max` and keep `zfs_arc_min` flexible. I test in stages, monitor the effects, and adjust based on actual trend values. This prevents a one-time spike from <strong>Configuration<\/strong> dominates. Gradual adaptation leads to reliable behavior without any unpleasant <strong>Surprises<\/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>How to Interpret ARC Metrics Correctly<\/h2>\n\n<p>To get a sense of the big picture, I regularly review the key metrics and track the relationships between them in a clear <strong>Table<\/strong> consistently. Tools like arcstat or arc_summary continuously provide data that I correlate with pool I\/O and application metrics. In this context, the big picture matters more than a single outlier in the <strong>Chart<\/strong>. The hit-to-miss ratio, in particular, shows whether the cache is effectively covering the workload. High hit rates indicate stable performance and short read paths in the <strong>RAM<\/strong> there.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Key figure<\/th>\n      <th>Description<\/th>\n      <th>What I pay attention to<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>ARC size<\/td>\n      <td>Current cache size in the <strong>RAM<\/strong><\/td>\n      <td>Expands under load, shrinks noticeably when needed<\/td>\n    <\/tr>\n    <tr>\n      <td>ARC c \/ c_max<\/td>\n      <td>Target value and maximum target value<\/td>\n      <td>Approaching c_max under high load; air at rest<\/td>\n    <\/tr>\n    <tr>\n      <td>Hits \/ Misses<\/td>\n      <td>Goals and misses since <strong>Start<\/strong><\/td>\n      <td>Misses consistently high? Check the workload or cache policy<\/td>\n    <\/tr>\n    <tr>\n      <td>hit ratio<\/td>\n      <td>Hits vs. Total Visits in <strong>%<\/strong><\/td>\n      <td>High number of repetitions: 80\u201390 (%) is realistic; otherwise, lower<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Based on these values, I take the following concrete steps: If the hit ratio remains low even though there is enough free RAM, I cautiously increase `zfs_arc_max` and monitor the <strong>Trends<\/strong>. If applications are under pressure, I lower the threshold and measure latency and I\/O load again. If a larger cache doesn't relieve the load, it's often because there's a highly random access pattern that makes caching less effective <strong>served<\/strong>. In such cases, other measures\u2014such as improving data locality or workload splitting\u2014usually have a greater impact. Simply increasing the cache size does not solve every <strong>Problem<\/strong>.<\/p>\n\n<h2>How the ARC Makes Decisions: Ghost Lists and Adjustments<\/h2>\n\n<p>Besides <strong>MRU<\/strong> and <strong>MFU<\/strong> The ARC uses what are known as <strong>Ghost Lists<\/strong> (MRU\/MFU Ghost). They contain only metadata for recently evicted blocks. If these exact blocks reappear shortly after being displaced, ZFS interprets this as an indication that the corresponding allocation was too small and redistributes capacity between the MRU and the MFU. Thus, <strong>learns<\/strong> The cache actively learns from misjudgments. In practice, this means that fluctuating patterns (e.g., batch windows in the evening) are handled better after just a few cycles, without me having to intervene manually.<\/p>\n\n<p>In this context, I'm mainly observing whether misses occur in waves and whether the hit rate increases noticeably afterward <strong>puts on<\/strong>. When that happens, the ARC logic works as intended. If the number of misses remains high despite repeated attempts, it is often because the work set is larger than the available cache or the access patterns are too <strong>random<\/strong>.<\/p>\n\n<h2>When the ARC Actually Causes Problems<\/h2>\n\n<p>In shared-hosting setups, I share memory with many other services, so a dominant ARC can choke off resources and cause swapping <strong>promote<\/strong>. Virtualization host administrators are familiar with this balancing act: Every VM would benefit from more RAM, while ZFS also wants to use cache resources. On small systems with just a few gigabytes, I set tighter limits so that the response time of the services isn't compromised <strong>device<\/strong>. Problems become apparent when applications run slowly, swap usage increases, or the OOM killer triggers alerts. In these situations, I set clear upper limits and then give the system a few days to <strong>Comparisons<\/strong>.<\/p>\n\n<p>I keep track of symptoms, times, and which parts of the body are affected <strong>Services<\/strong>. If the bottleneck occurs repeatedly during the same time windows, I plan adjustments such as backup windows, throttling indexing, or rescheduling large scans. Only when organizational measures fail to cushion the peak do I adjust the technology and limits <strong>on<\/strong>. This sequence preserves flexibility and prevents hasty interventions in sensitive production environments. This allows us to maintain a clear view of the interaction between the cache, I\/O, and applications <strong>clear<\/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, and NUMA Considerations<\/h2>\n\n<p>In container environments, the following applies: The ARC is <strong>across the host<\/strong> and is not limited by cgroups. If a pod or container reaches its memory limit, that does not prevent the host from coming under pressure due to ARC and other processes. I therefore allocate a fixed buffer on the host for system services and ZFS, and set the container limits so that the physical RAM isn\u2019t used to its absolute limit. On NUMA systems, I also make sure to avoid heavy cross-node access, as this can otherwise increase latencies. Even distribution of large VMs and a realistic ARC limit per <strong>Host<\/strong> This helps prevent a lot of surprises.<\/p>\n\n<h2>Best Practices for Sizing<\/h2>\n\n<p>On dedicated file servers, I like to allocate 60\u201380 % of RAM to ARC because other processes use very little memory <strong>demand<\/strong>. If there's a stack of containers or smaller services running alongside it, I start with 50\u201360 % and monitor the dynamic load. On hypervisors, I often set 30\u201340 % so that VMs have enough dedicated RAM <strong>have<\/strong>. I usually set `zfs_arc_min` to 25\u201350 % of `zfs_arc_max` so that the cache can still shrink during peak loads. I implement changes gradually and analyze the metrics over several days. <strong>from<\/strong>.<\/p>\n\n<p>I plan for buffers to handle spikes instead of setting the upper limit right at the limit <strong>sew<\/strong>. I deliberately leave space for write windows, backups, or re-indexing so that the system doesn\u2019t tip over into unrecoverable swapping. After each change, I check whether the hit ratio is still acceptable and whether applications are responding faster. If read performance remains high and bottlenecks disappear, I confirm the values and note the <strong>Reason<\/strong>. This documentation will be extremely helpful for future capacity-related issues.<\/p>\n\n<h2>Compressed ARC and Prefetch Fine-Tuning<\/h2>\n\n<p>Many workloads benefit from the <strong>Compressed ARC<\/strong>: ZFS stores data in the cache in a compressed form and decompresses it only when it is accessed. This saves RAM and increases the effective cache range. I keep the <strong>CPU<\/strong>-Keep the load in mind\u2014on systems that are heavily CPU-bound, the benefits don't always outweigh the costs. For clear <strong>compressible<\/strong> With data (logs, text, VM images with low entropy), the effect is usually quite noticeable. In addition, the <strong>ZFS Prefetch<\/strong> (zfetch) looks for sequential patterns and preloads subsequent blocks. For long stream reads that I don't want to cache anyway (backups, media pipelines), I configure primarycache to focus on metadata as described, and otherwise let zfetch handle the <strong>Defaults<\/strong>. Forcing the prefetch to turn off often leads to more misses under mixed workloads, and for me, that's the exception, not the rule.<\/p>\n\n<h2>Implement Persistent Settings Securely<\/h2>\n\n<p>I set the limits for the ARC <strong>persistent<\/strong>, so that they survive system restarts, and change them only in conservative increments. Increases are not critical; the system will use the additional space gradually. <strong>Subsidence<\/strong> can temporarily lead to increased eviction and more I\/O\u2014so I lower the values in 10\u201320-% increments and monitor the system for 24\u201348 hours. After major modifications or kernel\/ZFS updates, I check whether the values are still reasonable, since automatic heuristics can change with new versions <strong>Change<\/strong>.<\/p>\n\n<h2>Using L2ARC Wisely<\/h2>\n\n<p>L2ARC on SSD\/NVMe expands the cache and provides a noticeable improvement, especially with large amounts of data that cache well. <strong>Thrust<\/strong>. I only use it when the metrics show that the RAM-ARC is consistently running at capacity and the flash side still has some headroom. Important: L2ARC does not replace RAM, because the metadata for the cached blocks must be stored in the main ARC <strong>stay<\/strong>. A very large L2ARC therefore increases RAM requirements and can even cause performance throttling if the configuration is inappropriate. Writing to the L2ARC consumes I\/O bandwidth and <strong>CPU<\/strong>, I won't overlook that.<\/p>\n\n<p>L2ARC works well when the workload is larger than the amount of RAM but consistently involves similar files, such as VM images or many small <strong>properties<\/strong>. Before upgrading, I use I\/O statistics to check whether the flash drive has free capacity and isn't already operating at its limit. If these conditions are met, L2ARC often delivers consistently lower latencies. Only the combination of thorough monitoring, sufficient RAM reserves, and a properly sized L2ARC delivers the desired <strong>Effect<\/strong>. Simply adding larger SSDs rarely resolves actual bottlenecks.<\/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: Warm-up Phase and Persistence<\/h2>\n\n<p>The L2ARC has a <strong>Warm-up phase<\/strong>: Immediately after creation or after a restart, it is initially empty or not yet fully functional. Modern implementations can store metadata persistently, allowing the L2ARC to resume faster <strong>works<\/strong>. However, filling the feed takes time and consumes I\/O bandwidth. I don\u2019t throttle the feed unnecessarily, but I leave enough headroom for primary workloads. Especially important: The L2ARC should not put a strain on the same SSDs as log or transactional workloads. Dedicated, low-latency devices and a realistically calculated amount of RAM allocated to the L2ARC\u2014<strong>Header<\/strong> are required.<\/p>\n\n<h2>Dataset Settings: primarycache and secondarycache<\/h2>\n\n<p>I clear the cache via the dataset options so that ARC and L2ARC load the correct content <strong>hold<\/strong>. primarycache controls whether data and\/or metadata are stored in the main ARC, while secondarycache determines the contents of the L2ARC. For large, sequential streams (such as media archives), it is often sufficient to keep metadata in the ARC and not to store the actual data stream in the <strong>Buffer<\/strong>. For metadata-intensive workloads, I cache data and metadata to reduce latency. This separation prevents waste and strengthens the relevant <strong>Accesses<\/strong>.<\/p>\n\n<p>I test each dataset individually, rather than applying the same rule across the board to all pools. <strong>set<\/strong>. A properly configured primarycache\/secondarycache reduces unnecessary I\/O and increases the hit rate. Overall, this often results in smoother system behavior with more predictable response times. The same principle applies here: measure, adjust, repeat <strong>measure<\/strong>. It's often the small adjustments that make all the difference.<\/p>\n\n<h2>Special Case: Deduplication (DDT) and RAM Requirements<\/h2>\n\n<p>Activate <strong>Deduplication<\/strong>, memory requirements increase noticeably because the deduplication table (DDT) must be kept in RAM to remain efficient. Metadata is generated for each unique block; with typical block sizes, this quickly adds up to several gigabytes. If there isn\u2019t enough RAM, ZFS offloads DDT accesses to the disks, which increases latency and displaces the ARC. My rule of thumb: Enable deduplication only where high redundancy is guaranteed (e.g., VDI, identical VM images) and sufficient <strong>RAM<\/strong> is available. Otherwise, <strong>Compression<\/strong> is often by far the better lever.<\/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 and troubleshooting<\/h2>\n\n<p>To ensure smooth operation, I continuously monitor ARC size, hit ratio, I\/O profiles, and system-wide <strong>Storage load<\/strong>. If the ARC consistently stays at its limit without affecting applications, I give it some breathing room. If I see swapping or signs of an OOM condition, I set a limit and analyze the main causes. It\u2019s also helpful to take a look at <a href=\"https:\/\/webhosting.de\/en\/vm-vfs-cache-pressure-linux-filesystem-cache-tuning-optimization\/\">vm.vfs_cache_pressure<\/a>, to determine the ratio of the dentry\/inode cache to the remaining memory <strong>balance<\/strong>. I look at these values in context, never in isolation.<\/p>\n\n<p>Tools such as arcstat\/arc_summary, zpool, iostat, and top\/htop\/free\/vmstat provide me with the necessary <strong>circumstantial evidence<\/strong>. I compare peaks with workload windows and check whether the problems occur consistently. If the bottleneck occurs repeatedly, I adjust time windows, throttling settings, or cache limits. If the curve flattens out and applications remain fast, I keep the <strong>Setting<\/strong>. That way, I gain insights over the course of weeks and months, rather than reacting solely to snapshots in time.<\/p>\n\n<h2>Distinguishing Between ARC, Dirty Data, and ZIL\/SLOG<\/h2>\n\n<p>Part of the bigger picture is that, in addition to the ARC, <strong>Dirty Data<\/strong> (modified blocks that have not yet been written to disk) RAM. This area grows up to an upper limit and is then flushed asynchronously. Under heavy write loads, dirty data can temporarily grow large and slow down the system before ZFS responds with throttling mechanisms. In addition, the <strong>ZIL<\/strong> (ZFS Intent Log) synchronous writes; a fast SLOG helps, but does not reduce the ARC's RAM consumption. I make a clear distinction between these aspects: Noticeable write latencies despite a good hit ratio often indicate dirty data or log bottlenecks rather than an ARC that is too large <strong>ARC<\/strong> there.<\/p>\n\n<h2>Measurement Methodology: Time Windows and Trend Analysis<\/h2>\n\n<p>Since many ZFS counters are cumulative since the <strong>Boat<\/strong> When these are running, I analyze them over a daily or weekly window. I calculate rates (hits\/s, misses\/s) and compare them with I\/O wait times and CPU load. After major configuration changes, I \u201ereset\u201c my comparison values or mark the specific point in time so that effects can be clearly attributed. I evaluate the hit ratio per workload window (core production hours, nighttime window, batch runs)\u2014otherwise, a single overall figure obscures the true <strong>Bottle necks<\/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>Real-World Example: All-Purpose Server with 64 GB of RAM<\/h2>\n\n<p>A mixed-use server running web applications, a database, and backups can quickly use up 30\u201340 GB without fine-tuning <strong>ARC<\/strong>. However, the database requires a significant amount of its own RAM, so I set `zfs_arc_max` to about 24\u201328 GB and `zfs_arc_min` to 8\u201312 GB. After a few days, I observe lower swap usage and more stable latencies, while frequently accessed data remains in the cache <strong>lie<\/strong>. The system feels responsive because peak loads no longer hit the database and ARC at the same time. This moderate capping maintains throughput and noticeably improves response time in the <strong>day-to-day business<\/strong>.<\/p>\n\n<p>In the next step, I optimize datasets: For large sequential backups, I reduce the proportion of raw data in the ARC and prioritize metadata <strong>to<\/strong>. The hit ratio remains satisfactory, while the load on RAM decreases during nighttime windows. Once the modifications are complete, I will continue to monitor the situation and will only take action if there are persistent <strong>Trends<\/strong>. Long-term stability trumps short-term benchmarks in production environments. This ensures that the cache remains a source of profit rather than a cause for alarm or harsh <strong>Throttling<\/strong>.<\/p>\n\n<h2>Briefly summarized<\/h2>\n\n<p>I interpret the ARC's high memory usage as a sign of active <strong>Use<\/strong> rather than a flaw. ZFS releases the cache as needed, while zfs_arc_max and zfs_arc_min clearly define the range <strong>Define<\/strong>. Setups only become meaningful when combined with appropriate metrics such as hit ratio, ARC size, and I\/O profiles. L2ARC and dataset options give me additional tools to work with when RAM is running low or data volumes are significantly larger <strong>are<\/strong>. If you follow these guidelines, you'll be able to run ZFS quickly, efficiently, and reliably over the long term <strong>Response time<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Learn how the ZFS ARC cache works, why high RAM usage is normal, and how to properly configure memory usage to improve ZFS performance.<\/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":"126","_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\/en\/wp-json\/wp\/v2\/posts\/21087","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=21087"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21087\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/21080"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=21087"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=21087"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=21087"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}