{"id":20858,"date":"2026-08-21T11:49:48","date_gmt":"2026-08-21T09:49:48","guid":{"rendered":"https:\/\/webhosting.de\/linux-dirty-ratio-dirty-background-ratio-optimierung-writeback\/"},"modified":"2026-08-21T11:49:48","modified_gmt":"2026-08-21T09:49:48","slug":"linux-dirty-ratio-dirty-background-ratio-optimization-writeback","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/linux-dirty-ratio-dirty-background-ratio-optimierung-writeback\/","title":{"rendered":"Linux Dirty Ratio and Dirty Background Ratio: Fine-Tuning for Optimal Write Performance"},"content":{"rendered":"<p>I show how <strong>linux dirty<\/strong> and use the dirty background ratio to control the page cache, thereby influencing write throughput, latency, and data integrity. This allows you to set specific thresholds that trigger flushes in a timely manner, prevent deadlocks, and improve the write performance of your workloads.<\/p>\n\n<h2>Key points<\/h2>\n<p>To start, I'll briefly summarize the key points before delving deeper into the topic.<\/p>\n<ul>\n  <li><strong>Dirty Pages<\/strong> It buffers writes in RAM and aggregates many small accesses into more efficient I\/O operations.<\/li>\n  <li><strong>dirty_background_ratio<\/strong> It launches flusher threads in the background, thereby limiting the amount of junk data without the user noticing.<\/li>\n  <li><strong>dirty_ratio<\/strong> slows down writing processes if the hard limit is exceeded.<\/li>\n  <li><strong>Relation<\/strong> Both values determine latency spikes, throughput, and buffer size.<\/li>\n  <li><strong>Bytes Variants<\/strong> (dirty_bytes) provide finer, absolute control on large servers.<\/li>\n<\/ul>\n\n<h2>Understanding \"Dirty Pages\"<\/h2>\n\n<p>When a process writes data, it first ends up in the <strong>Page cache<\/strong> and are marked as \u201edirty\u201c until the kernel can flush them to the storage device. This buffering speeds up applications because RAM responds faster than any SSD or HDD, and small writes are consolidated into large, sequential transfers. I always keep in mind how much \u201edirt\u201c I allow, because too much buffering can lengthen queues or increase the risk of unsaved data in the event of a crash. Understanding how this works helps you make better decisions regarding writeback, latency, and storage pressure. A brief background article on the <a href=\"https:\/\/webhosting.de\/en\/writeback-cache-linux-kernel-cache\/\">Writeback Cache<\/a> helps to clearly categorize this mechanism.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-schreibfeintuning-7492.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Data Security, fsync, and the Crash Window<\/h2>\n<p>These thresholds affect not only performance but also your risk window. I estimate it using a simple rule of thumb: the maximum amount of unsaved data divided by the sustained device throughput roughly gives the time it takes for the buffer to empty. Example: If I allow 4 GB of dirty data and the target medium reaches 500 MB\/s, the full write operation takes about 8 seconds. During this time, the most recent writes could be lost in the event of a power outage or kernel panic.<\/p>\n<p>Applications can close the window by <code>fsync()<\/code> or <code>fdatasync()<\/code> reduce, because these accesses force the file system to write data (and, depending on the journaling mode, metadata as well) to the storage medium. This is more resource-intensive, but essential for databases or journals. I make sure that my dirty limits match the sync behavior: Frequent <code>fsync()<\/code>-Views benefit from lower <em>dirty_ratio<\/em>, so that the kernel doesn't throttle further when data is being persisted regularly anyway. Conversely, for logs that are heavy on appends and rarely flush, I can allow larger buffers\u2014always keeping in mind the accepted risk of data loss.<\/p>\n<p>Barriers and write sequences are also important: Modern file systems use FUA\/flush commands to properly clear controller caches. On media without power-loss protection, large buffers increase the risk; with PLP or write cache protection, larger buffers are often acceptable.<\/p>\n\n<h2>Dirty Background Ratio: The Soft Threshold<\/h2>\n\n<p>With <strong>dirty_background_ratio<\/strong> I specify the percentage of available memory at which flusher threads begin writing in the background. This value does not block applications but quietly starts cleanup operations to prevent the buffer from overflowing. Lower numbers result in more frequent but more consistent background writing and smooth out latency spikes. Higher numbers allow for more buffering, which increases throughput for large sequential writes but can trigger significant I\/O spikes during sudden flushes. Typically, default values are around ten percent, but I adjust this limit depending on the storage medium, workload, and security requirements.<\/p>\n\n<h2>Dirty Ratio: The Hard Brake<\/h2>\n\n<p>The parameter <strong>dirty_ratio<\/strong> marks the threshold at which the kernel throttles writing processes until enough pages have been flushed back. This hard limit protects memory from a flood of non-persistent data and thus directly affects applications as soon as they attempt to continue producing data. For databases, I tend to set this value fairly low so that queries maintain consistent response times and avoid long flush phases. For backup jobs, on the other hand, I use more generous buffers to efficiently transfer large blocks. Typical defaults range from twenty to forty percent, but I always adjust this range to the specific load.<\/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_perf_neu_opt_3847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Interactions and Typical Relationships<\/h2>\n\n<p>Both thresholds function as <strong>Tandem<\/strong> and only take full effect when combined. I always set `dirty_background_ratio` lower than `dirty_ratio` so that the kernel starts background processing in a timely manner and the hard limit is rarely triggered. As a rule of thumb, I often choose a value between one-quarter and one-half of the hard limit\u2014for example, 5\u201310 to 20. This way, writeback starts early enough without unnecessarily reducing throughput. If you get this ratio wrong, you\u2019ll either experience throttling too early or background processing that starts too late, resulting in noticeable latency spikes.<\/p>\n\n<h2>Per-Device Control and Block-Layer Units<\/h2>\n<p>In addition to the global limits, it\u2019s worth taking a look at the device level. Linux distributes the dirty load across so-called <em>Backed Devices<\/em> (bdi). In <code>\/sys\/class\/block\/\/bdi\/<\/code> I find parameters such as <code>max_ratio<\/code>, which determine how much of the globally allocated \"dirty budget\" a single device is allowed to use. On systems with both slow and fast drives running in parallel, I limit the slow drives so they don't become a bottleneck.<\/p>\n<p>Also relevant is block-layer throttling via <code>\/sys\/block\/\/queue\/wbt_lat_usec<\/code> (Writeback Throttling). This allows me to set a target latency; the kernel then throttles the write load when it exceeds this target time. For SATA HDDs, I like to set conservative values to protect interactivity. On very fast NVMe drives, I disable or increase the target latency so that the controller can take full advantage of its parallelism. I choose the I\/O scheduler (mq-deadline, BFQ, none) accordingly: BFQ helps with interactive systems with mixed workloads, while <em>none<\/em> or mq-deadline often performs best for pure throughput jobs on NVMe.<\/p>\n<p>The interplay is crucial: If <em>dirty_background_ratio<\/em> Even though the values are low, visible bottlenecks still occur because the device is aggressively limited by WBT. I therefore calibrate both levels together\u2014global dirty limits for buffer size and the block layer for latency protection.<\/p>\n\n<h2>Ratio vs. Bytes: Default Values and Variants<\/h2>\n\n<p>On systems with a lot of <strong>RAM<\/strong> Percentage values quickly add up to large absolute amounts. In that case, I prefer to set absolute upper limits using `dirty_bytes` and `dirty_background_bytes` to clearly limit the buffer size to about 2\u20138 GB. This decouples the control mechanism from highly fluctuating memory configurations and keeps the amount of non-persistent data predictable. The choice remains dynamic: For small servers with little RAM, percentages are often entirely sufficient. Those with high capacity often find that using byte values makes planning easier.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parameters<\/th>\n      <th>Meaning<\/th>\n      <th>Typical defaults<\/th>\n      <th>When should you change it?<\/th>\n      <th>Note<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio<\/td>\n      <td>Launch of the <strong>Background Flush<\/strong> as a percentage<\/td>\n      <td>\u2248 10%<\/td>\n      <td>In the case of latency fluctuations or very fast SSDs\/NVMe drives<\/td>\n      <td>Lower = smoother latency, higher = more buffer<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio<\/td>\n      <td>Hard <strong>Throttle Limit<\/strong> as a percentage<\/td>\n      <td>\u2248 20\u201340%<\/td>\n      <td>Lower for databases, higher for backups<\/td>\n      <td>Too high \u2192 May cause blockages during a flush<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_background_bytes<\/td>\n      <td>Start of the background flush in <strong>Bytes<\/strong><\/td>\n      <td>Disabled when Ratio is used<\/td>\n      <td>Large RAM, fixed buffer targets<\/td>\n      <td>Overrides ratio parameters<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_bytes<\/td>\n      <td>Hard throttling limit in <strong>Bytes<\/strong><\/td>\n      <td>Disabled when Ratio is used<\/td>\n      <td>Large amount of RAM, configurable upper limit<\/td>\n      <td>Overrides ratio parameters<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Workload Scenarios and Recommendations<\/h2>\n\n<p>Sequential write workloads such as <strong>Backups<\/strong> benefit from large buffers and moderate background writing, because the kernel can write to the medium in large chunks. I often set `dirty_ratio` between 30 and 40 percent and `dirty_background_ratio` between 10 and 20 percent. Databases and small random I\/O applications thrive on predictable latency, so I set hard I\/O to 10\u201315 percent and soft I\/O to 3\u20135 percent. For mixed web and app servers, 15\u201320 percent hard and 5\u201310 percent soft prove to be a good compromise. These ranges serve as a starting point; after that, the actual performance of your system is what matters.<\/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-schreibperformance-feintuning-5648.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>File System Considerations and Mount Options<\/h2>\n<p>The writeback path ends in the file system\u2014whose strategy determines latency and security. Ext4 with <em>data=ordered<\/em> (Default) writes user data before journal commits; <em>data=writeback<\/em> reduces latency but puts old data at risk after crashes. The parameter <code>commit=<\/code> (seconds) controls how often the journal is flushed. Shorter intervals reduce data loss but require more I\/O. XFS uses a well-developed log design; large <em>logbsize<\/em> and proper alignment help with throughput jobs. Btrfs bundles writes using copy-on-write\u2014which stabilizes latencies but can lead to fragmentation with small random writes and limited SSD capacity. Options such as <em>nodatacow<\/em> can help with specific paths or targeted defragmentation when latency spikes occur.<\/p>\n<p>I also note that <em>relatime<\/em>\/<em>noatime<\/em> (reduces metadata writes), <em>lazytime<\/em> (delayed mtime\/atime is more persistent), and journaling barriers. Correct cache semantics are crucial, especially on RAID controllers or in VMs: Incorrectly configured write caches can undo all the work done through \"dirty tuning.\".<\/p>\n\n<h2>Direct I\/O, O_SYNC, and Application Behavior<\/h2>\n<p>Not every request goes through the page cache. With <code>O_DIRECT<\/code> or <code>O_SYNC<\/code>\/<code>O_DSYNC<\/code> Some processes bypass parts of the cache or require immediate persistence. Databases typically write a WAL\/redo log synchronously and data areas asynchronously. I calibrate dirty boundaries specifically for asynchronous paths, while I guarantee low latency for synchronous paths using fast journals (NVMe, dedicated LUNs). When applications very frequently <code>fsync()<\/code> When accessing data, large buffers are of little help\u2014latency then depends more on the controller, queue depth, and I\/O scheduler than on <em>dirty_ratio<\/em>.<\/p>\n\n<h2>Practical Tuning, Step by Step<\/h2>\n\n<p>Before making any changes, I check the <strong>actual values<\/strong> with <code>sysctl vm.dirty_ratio<\/code> and <code>sysctl vm.dirty_background_ratio<\/code>, to document the initial state. For quick tests, I write values directly to <code>\/proc\/sys\/vm\/<\/code>for instance <code>echo 15 &gt; \/proc\/sys\/vm\/dirty_ratio<\/code> and <code>echo 5 &gt; \/proc\/sys\/vm\/dirty_background_ratio<\/code>. If the adjustment is permanent, I'll save it in <code>\/etc\/sysctl.conf<\/code> or <code>\/etc\/sysctl.d\/*.conf<\/code>. I implement changes using <code>sysctl -p<\/code> immediately so that I can measure the effect in a timely manner. Anyone who delves deeper into the topic of system rules will benefit from practical tips on <a href=\"https:\/\/webhosting.de\/en\/sysctl-tuning-for-web-hosting-server-performance\/\">Sysctl Tuning<\/a> on production servers.<\/p>\n\n<h2>Deriving Values: Sample Calculations<\/h2>\n<p>I like to start with tangible specifications. Example 1: Web\/app server with 64 GB of RAM and NVMe. The goal is low latency. I set <code>dirty_background_bytes=1073741824<\/code> (1 GB) and <code>dirty_bytes=3221225472<\/code> (3 GB). With a sustained NVMe throughput of 2 GB\/s, that means it takes about 0.5\u20131.5 seconds to empty\u2014good for interactive workloads. Example 2: Backup node with 128 GB of RAM, fast SATA RAID at 800 MB\/s. I choose <code>dirty_background_ratio=10<\/code>, <code>dirty_ratio=35<\/code>. In absolute terms, that's about 12.8 GB and 44.8 GB; the RAID takes 16\u201356 seconds to empty. That's okay, because the job isn't interactive.<\/p>\n<p>Example 3: Database server with 256 GB of RAM, separate journal on NVMe, data on an SSD array. I set an absolute limit to avoid outliers: <code>dirty_background_bytes=2147483648<\/code> (2 GB), <code>dirty_bytes=8589934592<\/code> (8 GB). This keeps the crash window size predictable and reduces sudden slowdowns during checkpoints.<\/p>\n\n<h2>Writeback Timing and Related Parameters<\/h2>\n\n<p>In addition to the limit values, the following factors influence <strong>Timer<\/strong> the writeback behavior and, consequently, the user experience of the applications. With <code>vm.dirty_writeback_centisecs<\/code> I control the interval at which the kernel flusher is woken up, while <code>vm.dirty_expire_centisecs<\/code> defines the maximum age dirty pages are allowed to reach. Shorter intervals result in more frequent but smaller flushes; longer intervals save on I\/O calls but risk larger batches. I only adjust these values if measurements reveal genuine drawbacks, such as flushes occurring too infrequently on fast NVMe drives. Taking a methodical approach here helps avoid swings between overly aggressive and overly sluggish writeback activity.<\/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_performance_finetune_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoring and Fine-Tuning<\/h2>\n\n<p>After making adjustments, I observe <strong>continuous<\/strong> the key metrics used to highlight successes and side effects. In <code>\/proc\/meminfo<\/code> I check \u201eDirty\u201c and \u201eWriteback\u201c to see buffer levels and active flushes. Tools like iostat, sar, or atop show me throughput, queues, and latency trends. This post on <a href=\"https:\/\/webhosting.de\/en\/server-io-wait-analysis-iostat-vmstat-metrics-disk\/\">Analyze I\/O Wait<\/a>. Only after analyzing this data do I adjust the limits\u2014either lowering or raising them\u2014in small increments to avoid any unexpected side effects.<\/p>\n\n<h2>Containers, cgroups, and Fair Resource Allocation<\/h2>\n<p>In container environments, workloads share the same kernel mechanisms. Cgroup writeback ensures that dirty pages are attributed to the source. I use the cgroups\u2019 I\/O controllers (blkcg) to limit bandwidth or IOPS per container when individual tenants are buffering too aggressively. Absolute byte limits at the host level (<em>dirty_bytes<\/em>) prevent a single guest from using up the entire dirty budget. In addition, I limit memory via <code>memory.max<\/code>, so that Writeback does not wait for a global flush to react. The goal remains: No guest load should trigger host-wide throttling of the <em>dirty_ratio<\/em> enforce.<\/p>\n\n<h2>Hosting Environments and VMs<\/h2>\n\n<p>In multi-tenant setups and VMs, I pay attention to <strong>Overbooking<\/strong> for RAM and I\/O, because percentage-based limits have different effects in those areas. Absolute byte limits can prevent individual guests from building up too much buffer and slowing down their neighbors. I take storage deduplication, ballooning, and controller caches into account because they override buffering effects. For managed servers, it pays off when the provider sets sensible defaults so that customers experience consistent response times. Those who operate their own nodes benefit from clearly defined profile settings for each workload class.<\/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\/DirtyRatioTuning1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Common Misconceptions and Pitfalls<\/h2>\n<ul>\n  <li><strong>\u201eMore buffer = ever-increasing throughput.\u201c<\/strong> This is incorrect for workloads that are heavily random or for devices with a small queue depth. Buffers that are too large cause flush bursts and queues.<\/li>\n  <li><strong>\u201edirty_ratio does not affect reads.\u201c<\/strong> Indirectly, yes: Aggressive writeback phases displace cache pages and increase read latencies.<\/li>\n  <li><strong>\u201eBytes and reason go hand in hand.\u201c<\/strong> No. If you set the \"Bytes\" variants, they override the \"Ratio\" counterparts. Keep it clear.<\/li>\n  <li><strong>\u201efsync() makes dirty limits irrelevant.\u201c<\/strong> No. While frequent syncs reduce the risk window, the remainder of the load is still subject to the limit values.<\/li>\n  <li><strong>\u201eA fast storage device solves everything.\u201c<\/strong> Not if the block layer throttles (WBT) or the file system is mounted suboptimally.<\/li>\n  <li><strong>\u201eDrop_caches is a tuning tool.\u201c<\/strong> Clearing the cache skews measurements and exacerbates latency spikes. I avoid doing this in production.<\/li>\n<\/ul>\n\n<h2>Troubleshooting: Common Symptoms and Solutions<\/h2>\n\n<p>Pile up <strong>Latency peaks<\/strong>, I first lower the background threshold so that flushes start earlier and large write bursts occur less frequently. If applications experience intermittent bottlenecks, the hard limit is usually set too high, or the storage device cannot handle the resulting flush bursts. In such cases, I lower the `dirty_ratio`, check the read-ahead settings, and review the file system journaling options. With very fast NVMe hardware, I gradually increase the background threshold so as not to artificially cap throughput. After each change, I rely on the measurement data, not on gut feelings.<\/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-schreibperformance-5712.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Brief summary for practical application<\/h2>\n\n<p>With few <strong>Adjusting screws<\/strong> I can control how Linux buffers write operations, when flushers start, and when the kernel throttles performance. The Dirty Background Ratio ensures gentle cleanup, while the Dirty Ratio places stricter limits on RAM usage. The relationship between these two values determines whether your system prioritizes consistent latencies or maximum throughput. I document the defaults, make changes in small increments, and consistently analyze the measurements. The result is a configuration that sensibly balances workload, medium, and risk\u2014and delivers noticeably faster performance in practice.<\/p>","protected":false},"excerpt":{"rendered":"<p>Discover how you can use the Linux \"dirty ratio\" and \"dirty background ratio\" to specifically optimize your server's write performance and kernel performance and efficiently manage dirty pages.<\/p>","protected":false},"author":1,"featured_media":20851,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20858","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":"134","_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":"linux dirty","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":"20851","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20858","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=20858"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20858\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/20851"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=20858"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=20858"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=20858"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}