{"id":21291,"date":"2026-09-11T11:51:31","date_gmt":"2026-09-11T09:51:31","guid":{"rendered":"https:\/\/webhosting.de\/redis-memory-fragmentation-ratio-richtig-interpretieren-speicheranalyse\/"},"modified":"2026-09-11T11:51:31","modified_gmt":"2026-09-11T09:51:31","slug":"interpreting-the-redis-memory-fragmentation-ratio-correctly-memory-analysis","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/redis-memory-fragmentation-ratio-richtig-interpretieren-speicheranalyse\/","title":{"rendered":"How to Correctly Interpret and Optimize the Redis Memory Fragmentation Ratio"},"content":{"rendered":"<p><strong>Redis Fragmentation<\/strong> determines how much memory is lost between the RSS allocated by the OS and the Redis data actually in use, and how I can avoid latency, swapping, and outages. I'll explain the <strong>Redis Memory Fragmentation Ratio<\/strong> Practical, with useful threshold values and clear guidelines for tuning, monitoring, and data modeling.<\/p>\n\n<h2>Key points<\/h2>\n\n<ul>\n  <li><strong>Definition<\/strong>: Correctly interpret the ratio of used_memory_rss to used_memory.<\/li>\n  <li><strong>Limit values<\/strong>: Take action at 1.5 or higher; check immediately if below 1.0.<\/li>\n  <li><strong>Causes<\/strong>: Variable object sizes, erasure waves, long runtimes.<\/li>\n  <li><strong>Measures<\/strong>: Active Defrag, Budgeting, Streamlining the Data Model.<\/li>\n  <li><strong>Monitoring<\/strong>: Set alerts for ratio and allocator values.<\/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\/09\/redis-analyse-4032.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>What exactly does \"mem_fragmentation_ratio\" mean?<\/h2>\n\n<p>I use the parameter <strong>mem_fragmentation_ratio<\/strong>, to see the ratio of RSS to data usage. The quotient of <strong>used_memory_rss<\/strong> divided by <strong>used_memory<\/strong> shows how efficiently Redis uses RAM. Values close to 1.0 indicate a <strong>efficient<\/strong> Utilization with few empty gaps. High values indicate that there are many empty areas in the process that the allocator cannot reuse. I never evaluate this value in isolation, but rather in conjunction with size, workload, and <strong>allocator<\/strong>-Metrics.<\/p>\n\n<h2>Interpreting Reference Values Correctly<\/h2>\n\n<p>I'm organizing the <strong>Ratio<\/strong> into fixed zones so that decisions remain reproducible. Slight overhangs around 1.1 are normal for me <strong>Overhead<\/strong>. When the value reaches about 1.5, I plan to take action, because otherwise RAM will be lost or the system will get closer to its OOM limits. If it drops below 1.0, I react immediately, because that indicates <strong>Swap<\/strong> The following table summarizes typical areas and actions.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Ratio<\/strong><\/th>\n      <th><strong>Meaning<\/strong><\/th>\n      <th><strong>immediate action<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Less than 1.0<\/td>\n      <td><strong>Swap<\/strong>-Risk, high latency<\/td>\n      <td>Check RAM\/Maxmemory, reduce the amount of data<\/td>\n    <\/tr>\n    <tr>\n      <td>1,0\u20131,1<\/td>\n      <td><strong>Healthy<\/strong> with a slight overhead<\/td>\n      <td>Continue monitoring; nothing urgent<\/td>\n    <\/tr>\n    <tr>\n      <td>1,1\u20131,5<\/td>\n      <td><strong>Normal<\/strong>, moderate fragmentation<\/td>\n      <td>Observe trends, note the causes<\/td>\n    <\/tr>\n    <tr>\n      <td>Over 1.5<\/td>\n      <td><strong>Increased<\/strong>, memory waste<\/td>\n      <td>Active Defrag, Check Model, Test Purge<\/td>\n    <\/tr>\n    <tr>\n      <td>Over 2.0<\/td>\n      <td><strong>High<\/strong>, capacity constraints<\/td>\n      <td>Aggressive defragmentation; consider restarting<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis_meeting_optimization_6723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>How Fragmentation Occurs<\/h2>\n\n<p>I see high <strong>Fragmentation<\/strong> especially during frequent write and delete cycles. The allocator, usually <strong>jemalloc<\/strong>, creates storage in arenas that aren't always recycled perfectly. When keys shrink, grow, or disappear entirely, gaps are left behind. New objects often don't fit into these gaps, causing the RSS to remain higher than the actual data. Over long periods of time, these gaps accumulate <strong>Gaps<\/strong>, until the ratio increases significantly.<\/p>\n\n<h2>Symptoms and Risks in the Workplace<\/h2>\n\n<p>Rising <strong>Latency<\/strong>, sudden OOM errors and a rising RSS are the first things I notice. Even if used_memory remains moderate, the instance can <strong>RAM<\/strong>-reach their limits. When the system then offloads pages, response times skyrocket. Services become sluggish and timeouts increase, which throws applications off track. That's why I always keep an eye on the <strong>Swap<\/strong>-Metrics at a glance.<\/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\/09\/redis-memory-optimization-8486.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>How to Safely Read INFO MEMORY<\/h2>\n\n<p>About <strong>INFO<\/strong> For memory, I check used_memory, used_memory_rss, and mem_fragmentation_ratio. I also pay attention to <strong>allocator_frag_ratio<\/strong> and `allocator_rss_ratio` to identify differences between the heap and the OS. A high `mem_fragmentation_ratio` with a normal `allocator` value indicates to me that the OS is not reclaiming pages effectively. High `allocator` values, on the other hand, point to internal <strong>Heap<\/strong>-fragmentation. I document the combinations so that trends become apparent and measures can be targeted effectively.<\/p>\n\n<h2>Active Defragmentation in Practice<\/h2>\n\n<p>I activate the <strong>Active<\/strong> Defragmentation occurs when the ratio increases or workloads fluctuate significantly. During this process, Redis reorganizes objects and packs them more tightly so that the OS can free up pages. I\u2019m testing the control mechanism step by step to keep CPU costs within reasonable limits. To start, I\u2019m using tried-and-true settings and then fine-tuning them. This provides me with a good introduction: <a href=\"https:\/\/webhosting.de\/en\/redis-active-defragmentation-reduce-memory-fragmentation-optimized-heap\/\">Active Defragmentation<\/a>-Article.<\/p>\n\n<pre><code>CONFIG SET activedefrag yes\nCONFIG SET active-defrag-ignore-bytes 100mb\nCONFIG SET active-defrag-threshold-lower 10\nCONFIG SET active-defrag-threshold-upper 100\nCONFIG SET active-defrag-cycle-min 5\nCONFIG SET active-defrag-cycle-max 75\n<\/code><\/pre>\n\n<p>I set <strong>Limit values<\/strong> so that Defrag kicks in only when truly necessary. The cycle values limit the CPU budget to ensure that peak loads aren't affected. After making adjustments, I monitor the metrics for several hours. Only when the ratio, latency, and CPU usage look right do I apply the <strong>Values<\/strong> permanent.<\/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\/09\/redis_optimierung_3021.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Fine-tune parameters without side effects<\/h2>\n\n<p>I raise the <strong>Threshold values<\/strong> only in small steps to avoid side effects. While a cycle that is too aggressive reduces fragmentation, it also puts a strain on the <strong>CPU<\/strong> Noticeable. During peak hours, I reschedule tests for quieter times so that the effects remain clearly measurable. It's helpful to compare the results before and after the adjustment using identical <strong>Workload<\/strong>. That's how I can tell whether defragmentation actually lowers the ratio or just shifts the load.<\/p>\n\n<h2>Using Lazy Free Purposefully<\/h2>\n\n<p>I use <strong>Lazy Free<\/strong>, when many large keys disappear or are renamed at once. Instead of blocking synchronously, <em>UNLINK<\/em>, <em>FLUSHDB ASYNC<\/em> and <em>FLUSHALL ASYNC<\/em> Free memory in the background. This reduces latency spikes but may temporarily increase fragmentation because pages are recycled asynchronously. I control this behavior using lazyfree parameters (e.g., lazyfree-lazy-eviction, lazyfree-lazy-server-del), test the impact on CPU usage, and monitor <strong>lazyfree_pending_objects<\/strong> in INFO memory. If there are many pending objects left over, I slightly increase the defragmentation budgets or spread out the deletion waves so that the heap doesn't break up into many small gaps.<\/p>\n\n<h2>Schedule Manual Cleanup and Restart<\/h2>\n\n<p>If the Ratio goes through the roof, I'll take drastic <strong>Lever<\/strong>. With MEMORY PURGE, I instruct the allocator to return unused pages to the OS. Using DEBUG MALLOC-STATS, I can look deeper into the <strong>Arenas<\/strong> and allocation patterns. If the ratio remains above 2.0, I plan a coordinated restart after a snapshot or AOF sync. This step requires the <strong>Memory Structure<\/strong> Go back and catch up on RSS right away.<\/p>\n\n<h2>Budgeting Maxmemory Wisely<\/h2>\n\n<p>I am planning <strong>maxmemory<\/strong> never up to the physical RAM limit. As a rule of thumb, I reserve about 60\u201365 % for data, 5\u201310 % as a fragmentation buffer, and 10\u201320 % for <strong>Copy-on-Write<\/strong>. The rest is reserved for the OS, agents, and operations. This allocation prevents <strong>OOM<\/strong>-Surprises and gives Defrag some breathing room. I found a handy guide here: <a href=\"https:\/\/webhosting.de\/en\/redis-memory-management-optimally-configuring-memory-for-performance-and-caching\/\">Optimize Storage Configuration<\/a>.<\/p>\n\n<h2>Persistence, RDB\/AOF, and Copy-on-Write<\/h2>\n\n<p>I always take into account the effects of <strong>Persistence<\/strong> on fragmentation. With BGSAVE and AOF rewrites, copy-on-write duplicates modified pages. During this phase, RSS increases even though used_memory barely grows. I therefore plan to perform hard rewrites during quiet time windows and check <em>auto-aof-rewrite-percentage<\/em> and <em>-min-size<\/em> and reserve headroom for CoW. Aggressive write spikes during a rewrite can quickly cause arenas to fragment; defragmenting afterward reclaims RSS. On replicas, I pay particularly close attention to the first full resync: large bulk imports combined with CoW are a classic driver of short-term spikes in <strong>mem_fragmentation_ratio<\/strong>. If the value remains elevated after completion, I'll run a quick defragmentation or test <em>MEMORY PURGE<\/em>.<\/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\/09\/redis_optimierung_desktop_4253.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Below 1.0: The swap rate is the stumbling block<\/h2>\n\n<p>If the ratio falls below 1.0, it slows down <strong>Swap<\/strong> the system. Each page fault cycle costs a noticeable amount of time and ruins latency targets. I then check the RAM status and reduce <strong>maxmemory<\/strong> or reduce the amount of data in the instance. I also monitor system parameters such as vm.swappiness to ensure that the kernel does so less frequently <strong>outsources<\/strong>. The goal remains to keep the instance strictly in RAM and avoid page fetches.<\/p>\n\n<h2>Consider Container and Kernel Settings<\/h2>\n\n<p>In containers, I always measure fragmentation in the context of <strong>cgroups<\/strong>-Limits. I compare RSS against memory limits and set <em>vm.overcommit_memory=1<\/em>, so that Redis doesn't fail due to overcommitment. <strong>Transparent Huge Pages<\/strong> I disable them because they bloat RSS feeds and make defragmentation more difficult. I also notice that <em>oom_kill<\/em>- I monitor the cgroup counters and respond early if the kernel starts to put pressure on the system. In Kubernetes, I ensure realistic requests and limits and reserve headroom per pod so that BGSAVE and rewrites don\u2019t unintentionally hit their limits. Important: Container isolation does not change the internal heap logic\u2014defragmentation, lazy free, and garbage collection remain the key tools against <strong>Fragmentation<\/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\/09\/redis-optimierung-4931.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Optimize the Data Model and Key Metrics<\/h2>\n\n<p>I hold <strong>properties<\/strong> small and uniform, so the allocator is less likely to scatter. I split very large lists, sets, or hashes into several smaller keys. Instead of huge JSON strings, I use compact <strong>Data types<\/strong> such as hashes with fields that change less frequently. For sessions, counters, and caches, I standardize sizes so that allocations remain more predictable. This way, I reduce the <strong>Fragmentation<\/strong>, before I start tweaking the settings.<\/p>\n\n<h2>Eviction Policy and Behavioral Patterns<\/h2>\n\n<p>I choose the <strong>Eviction policy<\/strong> tailored to the workload. When key volumes fluctuate significantly, LRU\/LFU variants distribute deletions more evenly and prevent spikes. I avoid mass expirations at the top of the hour and stagger TTLs so that Active-Expire doesn't remove thousands of objects at once. Parameters such as <em>hz<\/em> and <em>active-expire-effort<\/em> I only adjust it carefully so as not to overwork the CPU. A steady execution pattern produces predictable allocations\u2014and that's exactly what keeps the <strong>mem_fragmentation_ratio<\/strong> flat.<\/p>\n\n<h2>Redis Cluster and Sharding<\/h2>\n\n<p>When it comes to growth, I focus on <strong>Sharding<\/strong> or clusters, because smaller heaps per shard result in fewer long-term gaps. During rebalancing, I schedule migration windows so that write spikes and rewrites do not conflict. Large MIGRATE waves can temporarily increase RSS on target nodes; I monitor allocator values during this time and activate defragmentation after the move. On replicas, I account for additional memory for backlogs and replica buffers\u2014this also factors into the <strong>Maxmemory<\/strong>-Budgeting.<\/p>\n\n<h2>Delving Deeper into Observability: MEMORY STATS and Latency<\/h2>\n\n<ul>\n  <li>I use <strong>MEMORY STATS<\/strong>, to view overhead, dataset distribution, and fragmentation details. This helps distinguish heap fragmentation from OS-related fragmentation.<\/li>\n  <li>With <strong>MEMORY DOCTOR<\/strong> I'll get guidance on whether the data model, defragmentation, or purge will be most effective in the short term.<\/li>\n  <li>I correlate <strong>latency<\/strong>-Metrics (e.g., latency doctor) that include defragmentation phases and rewrites to identify side effects.<\/li>\n  <li>The <strong>SLOWLOG<\/strong> Shows me whether commands get out of sync due to memory operations\u2014especially DEL, UNLINK, and large HSET\/HGET sequences.<\/li>\n<\/ul>\n\n<h2>Practical Playbook for Operations<\/h2>\n\n<ul>\n  <li>Baseline: Back up INFO memory; document ratio, allocator values, and dataset\/overhead.<\/li>\n  <li>Budget: Set `maxmemory` to a realistic 60\u201365 % of data, 5\u201310 % of fragmentation, and 10\u201320 % of CoW.<\/li>\n  <li>Defrag: Enable activedefrag, increase the value gradually in cycles, and measure the effects over several hours.<\/li>\n  <li>Data model: split large objects, avoid JSON blocks, standardize sizes.<\/li>\n  <li>Expire: Spread out TTLs, choose an appropriate eviction policy, avoid mass deletions.<\/li>\n  <li>Persistence: Schedule rewrites, allocate headroom, and check for defragmentation after completion.<\/li>\n  <li>Purge\/Restart: If the ratio is greater than 2.0, attempt a purge; otherwise, restart in an orderly manner.<\/li>\n  <li>Container: THP off, overcommit on, limits\/requests with headroom; strictly limit swap.<\/li>\n  <li>Monitoring: Alerts at 1.5\/2.0\/below 1.0; analyze trends by deployments and batches.<\/li>\n<\/ul>\n\n<h2>Example: From 1.8 to 1.2 in 24 hours<\/h2>\n\n<p>On a 64-GB instance (maxmemory 40 GB), the <strong>mem_fragmentation_ratio<\/strong> to 1.8, even though used_memory was between 28 and 30 GB. At first, I <em>activate defrag<\/em> Enabled it (cycle-min 5, cycle-max 50) and moved the nightly AOF rewrite to a quieter time slot. After that, I adjusted the TTLs that had previously expired hourly and replaced several huge JSON values with hashes with fixed field sizes. A targeted <em>MEMORY PURGE<\/em> After the peak load, RSS was also released. Result: After 24 hours, the ratio dropped steadily to ~1.2, latency spikes disappeared, and the host RAM gained ~8 GB of free space. The <strong>allocator<\/strong>-Values confirmed: less heap fragmentation, OS RSS in balance.<\/p>\n\n<h2>Comparing Hosting Environments Effectively<\/h2>\n\n<p>I make sure to get enough <strong>RAM<\/strong>, predictable CPU and consistent I\/O performance when I host Redis with a hosting provider. Dedicated resources and flexible upgrades prevent bottlenecks as the system grows. Clear metrics for RSS are useful, <strong>Swap<\/strong> and limits, so I can identify bottlenecks early on. For German setups, I recommend webhoster.de because it reliably provides the necessary resources. A clean platform keeps the <strong>Fragmentation<\/strong>-level within the normal range.<\/p>\n\n<h2>Summary<\/h2>\n\n<p>I read the <strong>Redis<\/strong> Memory fragmentation ratio as an early warning sign for RAM loss and latency. Values close to 1.0 are healthy; at 1.5 or higher, I run a defrag and make model adjustments; below 1.0, I stop. <strong>Swap<\/strong> immediately. With Active Defragmentation, smart Maxmemory budgeting, and compact data structures, I keep the <strong>Memory<\/strong>-High efficiency. Continuous monitoring identifies patterns and prevents frantic ad hoc actions. This keeps the instance responsive, and the <strong>Ratio<\/strong> is right where it belongs.<\/p>","protected":false},"excerpt":{"rendered":"<p>Learn how to correctly interpret the Redis memory fragmentation ratio, identify normal and critical ranges, and keep your Redis memory efficient and stable through targeted Redis tuning.<\/p>","protected":false},"author":1,"featured_media":21284,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21291","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"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":"67","_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":"Redis Fragmentation","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":"21284","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21291","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=21291"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21291\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/21284"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=21291"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=21291"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=21291"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}