{"id":20548,"date":"2026-08-11T15:09:51","date_gmt":"2026-08-11T13:09:51","guid":{"rendered":"https:\/\/webhosting.de\/writeback-cache-linux-kernel-cache\/"},"modified":"2026-08-11T15:09:51","modified_gmt":"2026-08-11T13:09:51","slug":"writeback-cache-linux-kernel-cache","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/writeback-cache-linux-kernel-cache\/","title":{"rendered":"Understanding the Writeback Cache and Dirty Pages in the Linux Kernel"},"content":{"rendered":"<p>The writeback cache in the Linux kernel controls when modified data is written to <strong>Dirty Pages<\/strong> remain in RAM and when the kernel writes them in batches to the storage medium. I'll explain how this process <strong>Performance<\/strong>, latency, and data security\u2014and which controls really matter in everyday use.<\/p>\n\n<h2>Key points<\/h2>\n<ul>\n  <li><strong>Dirty Pages<\/strong> Mark changed pages in RAM that have not yet been written to the storage medium.<\/li>\n  <li><strong>writeback<\/strong> It groups changes together and writes them efficiently in larger blocks.<\/li>\n  <li><strong>Threshold values<\/strong> Like vm.dirty_ratio, these control speed and throttling.<\/li>\n  <li><strong>Synchronization<\/strong> Using fsync\/flush protects against data loss.<\/li>\n  <li><strong>Monitoring<\/strong> The \/proc directory and tools display load and latency.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linuxserver-writeback-3901.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>How the Page Cache Works<\/h2>\n\n<p>I read a file; the kernel places the data in the page cache, and subsequent accesses are served from the <strong>Memory<\/strong> instead of from disk. During writing, the system marks the modified pages as <strong>Dirty<\/strong> and often acknowledges the request immediately so that the application can continue running. This decoupling reduces wait times because slow I\/O operations don't directly slow down every app. The cache also keeps frequently used blocks on hand, increasing the hit rate for subsequent accesses. If you want to dive deeper, you can find more background information in my overview of <a href=\"https:\/\/webhosting.de\/en\/filesystem-caching-linux-page-cache-cacheboost\/\">File System Caching<\/a>, which illustrates the role of reading and writing paths in everyday life.<\/p>\n\n<h2>Dirty Pages: Meaning and Impact<\/h2>\n\n<p>Dirty pages are modified memory pages that have not yet been permanently saved and are therefore only available in the <strong>RAM<\/strong> exist. As long as they're dirty, I wear a certain <strong>Risk<\/strong>: A power outage could undo these changes. Nevertheless, this approach provides a higher write rate because the kernel combines many small updates. As the proportion of dirty pages increases, the load on the write back units grows. The system can then free up memory by prioritizing the writing of those pages to the drive.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_kernel_meeting_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Writeback: Triggers and Process<\/h2>\n\n<p>Writeback can be triggered by a schedule, an event, or on demand <strong>Apps<\/strong>. The kernel bundles dirty pages, forms appropriate I\/O sequences, and passes them through the block layer to the <strong>Storage device<\/strong>. Along the way, file systems, reclaimers, and I\/O schedulers intervene to control the order and size of operations. Synchronization calls such as fsync ensure that certain data is safely written to the medium before proceeding. During periods of high activity, I see a growing proportion of writebacks in the statistics, which then drops again after the flush.<\/p>\n\n<h2>Internal Mechanisms: balance_dirty_pages, BDI, and Writeback Workers<\/h2>\n\n<p>Under the hood, several components work together. Writing threads pass through <strong>balance_dirty_pages()<\/strong>, which takes into account the current dirty load, the device speed, and the set limits. It throttles the write rate of the processes so that background writeback can keep up. Each <strong>Backing Device<\/strong>-Context (bdi)\u2014typically a block device or a file system backend\u2014has its own work queues with <strong>Flusher Threads<\/strong>, which convert the dirty pages into ordered I\/O requests. This distribution prevents a slow device from slowing down all the others and improves fairness among workloads.<\/p>\n\n<p>Throttling is adaptive: When I detect faster writers or larger contiguous blocks, the allowed dirty amounts increase temporarily. In the event of bottlenecks, high latencies, or saturated queues, the kernel applies the brakes more aggressively and forces writers to pause until the buffer has some breathing room again. It is precisely this interplay that explains why small parameter changes can lead to noticeably different latency profiles.<\/p>\n\n<h2>Thresholds: vm.dirty_background_ratio and vm.dirty_ratio<\/h2>\n\n<p>I control the behavior using two key limits that determine the proportion of contaminated pages relative to the <strong>RAM<\/strong> define. If I exceed the background value, the kernel starts in the <strong>Background<\/strong> writing. If I reach the hard limit, the system throttles writing processes until enough data has been flushed back. This keeps the storage usable, even if individual programs generate large amounts of changes. If you\u2019re working with byte-based limits, set the corresponding *_bytes parameters instead of the ratio values.<\/p>\n\n<h2>Table: Relevant Kernel Parameters and Metrics<\/h2>\n\n<p>I use a few key controls to specifically manage and visualize writeback, latency, and throughput; the following overview helps with <strong>Classification<\/strong> and fast <strong>Examination<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parameter\/Key Figure<\/th>\n      <th>Effect<\/th>\n      <th>Initial Values\/Note<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio \/ vm.dirty_background_bytes<\/td>\n      <td>Starts background writeback when the percentage of dirty pages exceeds this threshold.<\/td>\n      <td>For servers, choose a more conservative setting so that the flush starts sooner.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio \/ vm.dirty_bytes<\/td>\n      <td>Upper limit for dirty pages; writers are throttled once this limit is reached.<\/td>\n      <td>Too high increases latency risks; too low wastes throughput.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_writeback_centisecs<\/td>\n      <td>Interval at which the kernel checks for dirty pages for background flushing.<\/td>\n      <td>Shorter intervals smooth out load spikes but result in more wake-ups.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_expire_centisecs<\/td>\n      <td>The age at which \u201eDirty Pages\u201c are considered \"due\" and are given priority for writing.<\/td>\n      <td>Higher values provide greater aggregation, but reduce consistency guarantees in the event of an error.<\/td>\n    <\/tr>\n    <tr>\n      <td>\/proc\/meminfo: Dirty, Writeback<\/td>\n      <td>Current number of soiled or actively written-back pages.<\/td>\n      <td>Useful for real-time monitoring during load tests.<\/td>\n    <\/tr>\n    <tr>\n      <td>Mount\/FS Options (e.g., barriers, journaling mode)<\/td>\n      <td>They affect the order, persistence, and cost of individual flushes.<\/td>\n      <td>Select the appropriate option based on the file system and device.<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>I regularly read these values and correlate them with I\/O wait times in Top, iostat, or similar tools <strong>Tools<\/strong>. This provides a clear indication of whether Writeback itself is the limiting factor or whether the <strong>Storage<\/strong> is at its limit.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-kernel-cache-dirty-pages-4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoring and Diagnostics: What I Measure<\/h2>\n\n<p>First, I check \/proc\/meminfo and monitor the \"Dirty\" and \"Writeback\" fields while specifically <strong>Load<\/strong> produce. If the \"dirty\" levels rise sharply and remain high, timely flushes are often lacking, or the <strong>Medium<\/strong> is at full capacity. If writeback increases but dirty only decreases slowly, the target device or I\/O path is the bottleneck. If latency spikes coincide with writeback spikes, I smooth the interval or lower the ratio values. A brief overview helps me understand typical patterns. <a href=\"https:\/\/webhosting.de\/en\/linux-page-cache-performance-booster\/\">Page Cache Booster<\/a>, which summarizes practical adjustment screws and measurement points.<\/p>\n\n<h2>Advanced Metrics, vmstat, and Tracing<\/h2>\n\n<p>In addition to \/proc\/meminfo, I use fine-grained counters to distinguish between cause and effect. In <strong>\/proc\/vmstat<\/strong> Fields such as nr_dirty, nr_writeback, nr_dirtied, and nr_written provide insights into the system's dynamics: How quickly are blocks marked as dirty, and how quickly are they flushed? In addition, I monitor the length of the I\/O queues and the abort rates for merge operations in the block layer.<\/p>\n\n<ul>\n  <li>vmstat 1: displays dirty\/writeback drift and I\/O wait time (wa) per second,<\/li>\n  <li>\/proc\/pressure\/memory: reveals memory pressure, which indirectly triggers writeback,<\/li>\n  <li>Tracepoints (writeback:*) and block events: reveal the order and size of the flushes,<\/li>\n  <li>perf\/ftrace: Identifies hotspots in `balance_dirty_pages` and the flusher workqueues.<\/li>\n<\/ul>\n\n<p>If I see that nr_dirtied is consistently higher than nr_written, that's a clear sign of impending throttling pressure or background flushes that are occurring too late. If peaks in writeback tracepoints correspond to latency spikes, I optimize the interval and batch sizes.<\/p>\n\n<h2>HDD vs. SSD: Impact on Writeback Design<\/h2>\n\n<p>On rotating reels, larger, consecutive flushes are particularly lucrative because they eliminate the need for costly searches <strong>Avoid<\/strong>. SSDs also benefit, but what matters here is the distribution of writes and the interaction with the <strong>Controller<\/strong>. I avoid an excessive number of small syncs so that the firmware can operate efficiently. At the same time, when working with SSDs, I pay closer attention to consistency barriers and flush semantics to truly take advantage of the device\u2019s guarantees. Mixed workloads with random reads and writes respond noticeably to small adjustments in the dirty thresholds and flush timing.<\/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\/tech_office_nacht_6342.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Device Cache, Flush Semantics, and Power Failure Protection (PLP)<\/h2>\n\n<p>Whether a flush actually persists also depends on the <strong>Device Cache<\/strong> ... Many drives buffer data in their own DRAM. Without <strong>Power Loss Protection (PLP)<\/strong> I risk data loss if the cache isn't flushed in time. While writeback benefits from the device cache, I ensure that barriers and flush commands are honored. On systems with RAID controllers, I assess whether a battery- or flash-backed cache is present; in such cases, synchronized writes are often preferable without sacrificing security.<\/p>\n\n<p>I also make the following distinction: FUA (Force Unit Access) enforces persistence per I\/O, but comes at the cost of IOPS. Flush barriers can commit multiple writes at once. For particularly critical paths (such as journals), I accept the FUA\/flush overhead, while I leave bulk data in the writeback stream. Anyone who changes mount options or controller settings should then verify with load tests that the intended flush semantics are working as intended.<\/p>\n\n<h2>Data Consistency: Using fsync, Flush, and FUA Correctly<\/h2>\n\n<p>I use fsync specifically for data with high <strong>Value<\/strong>, which require a clear durability guarantee. The kernel can drive flush operations all the way to the storage medium and use FUA to ensure that a write is truly <strong>persists<\/strong>, before the confirmation is received. This approach takes time and consumes IOPS, but prevents data loss in the event of a crash. Without such safeguards, the system reports success even though the bytes are still in the SSD\u2019s cache or in RAM. I tailor these decisions to the application: I use hard saves for transaction logs and soft saves for bulk updates.<\/p>\n\n<h2>Tuning Examples for Hosting and Database Workloads<\/h2>\n\n<p>For web and database servers, I often set a moderate `dirty_background_ratio` and keep `dirty_ratio` significantly higher to ensure that background flushes occur in a timely manner <strong>start<\/strong>, without Schreiber leaving too early <strong>Brake<\/strong>. During write bursts, I reduce the writeback interval so that the writeback mechanisms kick in sooner. On systems with a lot of RAM, I prefer *_bytes values so that actual sizes\u2014rather than percentages\u2014are used. I test every change with reproducible benchmarks and measure latency, throughput, and the 95th and 99th percentiles. This practical overview provides me with a concise guide to the effects of the page cache: <a href=\"https:\/\/webhosting.de\/en\/linux-page-cache-performance-booster\/\">Linux Page Cache Performance Booster<\/a>.<\/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\/devdesk_linux_cache_4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Direct I\/O and mmap: When the Page Cache Is Bypassed<\/h2>\n\n<p>Not every application uses the page cache in the same way. With <strong>O_DIRECT<\/strong> It can deliberately bypass the cache and write to or read from the device directly. This reduces the load on RAM and shortens data paths, but it also eliminates the benefits of batching and read-ahead. This can be useful for large, one-time transfers; for many small writes, however, I lose the benefits of writeback.<\/p>\n\n<p>With <strong>mmap<\/strong> And with copy-on-write, I mark pages as \"dirty\" when they are modified; the flush then occurs via the normal writeback path or by <strong>msync<\/strong>. I take this into account when applications rely heavily on memory-mapped I\/O: Dirty spikes can occur unexpectedly, even though the app is \u201eonly\u201c writing to memory. Here, too, ratio\/byte limits help control the timing of the write-back.<\/p>\n\n<h2>Container Environments and cgroup Writeback<\/h2>\n\n<p>In multi-tenant setups, I prevent \u201enoisy neighbors\u201c by <strong>cgroups<\/strong>. The kernel assigns dirty pages to the group that generated them (cgroup writeback), so that background flushing and throttling are distributed more fairly. With memory limits (<strong>memory.high<\/strong>, memory.max) I limit the number of dirty spikes per container. In addition, I set I\/O quotas via the I\/O controller to prevent individual workloads from filling up the entire device queue.<\/p>\n\n<p>In practice, I set realistic upper limits for each service class: write-intensive batch jobs get generous dirty budgets, while latency-critical frontends get tighter ones. This keeps the overall latency more stable, because Writeback doesn\u2019t suddenly throttle everyone as soon as a single container goes off track.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-kernel-cache-8974.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Network File Systems (NFS, SMB, distributed file systems)<\/h2>\n\n<p>With network file systems, an additional buffer level is added. Local dirty pages merely indicate that data is in transit; whether they <strong>remote<\/strong> Whether data is persisted is determined by the protocol (commit semantics) and the server. I do not rely on implicit flushes: I explicitly synchronize critical data. At the same time, I take round-trip costs into account\u2014syncing over the network too frequently noticeably increases latency.<\/p>\n\n<p>In mixed workloads, I separate paths: Local, temporary files benefit as much as possible from the page cache; network mounts are assigned stricter sync points. This prevents writeback over the network from becoming a bottleneck while local jobs still have capacity to spare.<\/p>\n\n<h2>I\/O Scheduler, blk-mq, and Queue Depth<\/h2>\n\n<p>How efficiently writeback batches are processed on the device also depends on the <strong>Blocklayer<\/strong> from. With <strong>blk-mq<\/strong> I\/Os are distributed across multiple queues; schedulers such as mq-deadline or kyber prioritize and order them. I choose the scheduler based on the storage medium: On NVMe, \u201enone\u201c is often a good choice, while on SATA or SAS, Deadline helps organize writes.<\/p>\n\n<p>The <strong>Queue depth<\/strong> I set this so that the device is fully utilized but not overloaded. Too shallow wastes throughput; too deep increases latency variation and makes throttling more persistent. Writeback benefits from moderate depths and large, contiguous requests. I monitor merge rates and \u201einflight\u201c counters; declining merge rates indicate that batches are too small or that there are competing random workloads.<\/p>\n\n<h2>Reproducible tests and reliable rollback<\/h2>\n\n<p>Before I adjust the controls, I record the current status and test <strong>reproducible<\/strong> and plan for rollbacks. I use identical workloads and identical data volumes, and I either warm up the cache in a targeted manner or deliberately clear it to ensure that test runs are comparable. I first apply configuration changes temporarily, monitor the metrics, and only then make them permanent.<\/p>\n\n<pre><code># Example: Temporary tuning steps (Root)\nsysctl -w vm.dirty_background_bytes=$((512*1024*1024))\nsysctl -w vm.dirty_bytes=$((2*1024*1024*1024))\nsysctl -w vm.dirty_writeback_centisecs=100\nsysctl -w vm.dirty_expire_centisecs=3000\n\n# Short load test (example, depends on workload)\n# fio --name=wbtest --filename=\/data\/testfile --size=8G --ioengine=libaio \\\n#     --rw=randwrite --bs=128k --iodepth=32 --direct=0 --numjobs=4 --runtime=60 --time_based\n<\/code><\/pre>\n\n<p>Meanwhile, I read from \/proc\/meminfo, vmstat, and iostat simultaneously and correlate the peaks. After the test, I either reset the values or apply them to the system configuration in a controlled manner. To this end, I document <strong>Date<\/strong>, <strong>Kernel<\/strong>-Version, device, and file system details, so that future comparisons remain reliable.<\/p>\n\n<h2>Common Problems and Solutions<\/h2>\n\n<p>If the system seems to be running smoothly but writing operations are stalling, I check for throttling caused by a setting that's too low <strong>dirty_ratio<\/strong>. If the \"Dirty\" setting remains at a high level, there is a lack of bandwidth or the <strong>Interval<\/strong> It's too long for a flush. If latencies spike during short sync storms, I distribute the load across smaller batches and improve I\/O scheduling. If the cache barely gets going, a *_bytes limit that's too small might be preventing effective batching. A closer look at <a href=\"https:\/\/webhosting.de\/en\/server-page-cache-eviction-linux-memory-print-optimization-insight\/\">Cache Eviction During Printing<\/a> helps when storage shortages also get in the way.<\/p>\n\n<h2>Best Practices and a Short Checklist<\/h2>\n\n<p>I make a strict distinction between data that must be committed immediately and data that can be persisted later in order to <strong>Performance<\/strong> To optimize performance. For logs and transaction journals, I enforce synchronous operations; for temporary artifacts, I let writeback run freely and just keep an eye on the throttling limit. Before making any adjustments, I measure the current state and perform A\/B comparisons using defined scenarios. I keep the number of concurrent writers in check because uncoordinated surges reduce the benefits of batching. And I document changes immediately so that future analyses can be based on clear <strong>Data<\/strong> based.<\/p>\n\n<h2>A Practical Summary for Quick Success<\/h2>\n\n<p>The writeback cache aggregates changes in the <strong>Page<\/strong> Caching reduces I\/O overhead and lightens the load on applications. Dirty pages aren't a mistake\u2014they're a deliberate tactic to boost performance, as long as I understand the limits and consistency requirements. Using the vm.dirty_background_ratio and vm.dirty_ratio parameters, I control when the kernel works quietly in the background and when it throttles write operations. Tools and the \/proc directory provide me with the necessary visibility into dirty pages and writebacks so I\u2019m not left in the dark. Once I\u2019ve mastered these controls, web applications, databases, and batch jobs run measurably faster without compromising <strong>Integrity<\/strong> to compromise my data.<\/p>","protected":false},"excerpt":{"rendered":"<p>Writeback Cache in the Linux Kernel: Dirty Pages, Page Cache, and Writeback Explained in Simple Terms.<\/p>","protected":false},"author":1,"featured_media":20541,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20548","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":"150","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":null,"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Writeback Cache","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20541","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20548","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=20548"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20548\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/20541"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=20548"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=20548"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=20548"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}