{"id":20794,"date":"2026-08-19T11:49:58","date_gmt":"2026-08-19T09:49:58","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-buffer-pool-sizing-performance-guidespeicher\/"},"modified":"2026-08-19T11:49:58","modified_gmt":"2026-08-19T09:49:58","slug":"mariadb-buffer-pool-sizing-and-performance-guide","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/mariadb-buffer-pool-sizing-performance-guidespeicher\/","title":{"rendered":"MariaDB Buffer Pool Sizing: A Practical Guide and Rules of Thumb for the InnoDB Buffer Pool"},"content":{"rendered":"<p>I'll show you how I <strong>Buffer Pool<\/strong> Practical sizing in MariaDB so that the active dataset resides primarily in RAM and read and write operations rarely have to wait for slow storage. I use clear rules of thumb for the InnoDB buffer pool, monitor the hit rate and I\/O, and adjust the size incrementally without starving the operating system or services.<\/p>\n\n<h2>Key points<\/h2>\n<p>The following key points provide you with a quick overview to help you make informed decisions.<\/p>\n<ul>\n  <li><strong>RAM Percentage<\/strong>: 60\u201380 % on dedicated database servers, 40\u201360 % on shared hosts<\/li>\n  <li><strong>Active Data<\/strong>: 80\u201390 % of the hot data should fit into the pool<\/li>\n  <li><strong>Hit rate<\/strong>: Target value 99 or higher for %; otherwise, check I\/O and latencies<\/li>\n  <li><strong>Step by step<\/strong> Adjustment: Validate in 10\u201320 % increments<\/li>\n  <li><strong>Overall view<\/strong>: Taking OS Cache, Connections, Logs, and Services into Account<\/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\/mariadb-buffer-8321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Role of the InnoDB Buffer Pool<\/h2>\n<p>The InnoDB cache stores frequently accessed data and index pages in the <strong>RAM<\/strong> and thus reduces costly accesses to the data storage medium. The larger this memory, the more often the engine serves queries directly from the <strong>Cache<\/strong> and the lower the latency. For production environments, correctly configuring `innodb_buffer_pool_size` is one of the most effective ways to optimize performance because it has a direct impact on read and write paths. I therefore prioritize the buffer over other tuning parameters so that workloads encounter a consistent workload. Those who want to delve deeper into practical steps will find in this concise <a href=\"https:\/\/webhosting.de\/en\/mysql-buffer-pool-database-performance-optimization\/\">Buffer pool optimization<\/a> additional food for thought.<\/p>\n\n<h2>Rule of thumb: Percentage of available RAM<\/h2>\n<p>I base the pool size first on the available <strong>Working memory<\/strong>, not the entire amount of physical RAM, in case other services are running. On a dedicated database server, I typically allocate between 60 and 80 percent for innodb_buffer_pool_size; on a combined host, between 40 and 60 percent. This range gives the file system cache, connections, and background processes enough breathing room without <strong>Buffer<\/strong> Keep it tight. Then, under real-world load, I check whether the target values for hit rate and I\/O are being met. The following guidelines are a good starting point; I then fine-tune them based on actual measurement data.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Physical RAM<\/th>\n      <th>Typical Buffer Pool (Dedicated DB Server)<\/th>\n      <th>Reserve for OS &amp; Services<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>4 GB<\/td>\n      <td>2.0\u20132.8 GB<\/td>\n      <td>1.2\u20132.0 GB<\/td>\n    <\/tr>\n    <tr>\n      <td>8 gigabytes<\/td>\n      <td>4.0\u20135.6 GB<\/td>\n      <td>2.4\u20134.0 GB<\/td>\n    <\/tr>\n    <tr>\n      <td>16 GB<\/td>\n      <td>10\u201312 GB<\/td>\n      <td>4\u20136 GB<\/td>\n    <\/tr>\n    <tr>\n      <td>32 GB<\/td>\n      <td>20\u201324 GB<\/td>\n      <td>8\u201312 GB<\/td>\n    <\/tr>\n    <tr>\n      <td>64 gigabytes<\/td>\n      <td>40\u201348 GB<\/td>\n      <td>16\u201324 GB<\/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\/08\/mariadb_buffer_pool_guide_7384.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Active Record: How to Determine the Size<\/h2>\n<p>The RAM rule provides an initial value, but the <strong>active<\/strong> The dataset determines the target size. I first determine the size of the most important tables, including their indexes, and focus on the truly \u201chot\u201d structures. Then I correlate the most frequently occurring queries with these tables, for example using the slow log or performance data. If 80 to 90 percent of the hot data fits into the pool, the engine handles the majority of read operations without additional <strong>Disk I\/O<\/strong>. If resources are insufficient, I prioritize the most critical tables or increase the pool in moderate increments.<\/p>\n\n<h2>Measuring Hit Rate and I\/O Load<\/h2>\n<p>I determine whether the sizing is right by looking at the <strong>Hit rate<\/strong> of the buffer pool and the I\/O metrics of the storage subsystem. If the rate remains consistently below 99 percent, I check both reads and writes per second as well as the response times of individual queries. A consistently high I\/O throughput with a moderate number of users often indicates that the <strong>Buffer<\/strong> . In this case, I increase the pool size as long as there is still healthy RAM available and the system doesn't start swapping. For methodical fine-tuning, this compact <a href=\"https:\/\/webhosting.de\/en\/database-buffer-cache-hit-rate-optimization-guide-data-stream\/\">Guide to the Hit Rate<\/a> with practical checkpoints.<\/p>\n\n<h2>Quickly Determine Key Metrics: Practical Queries<\/h2>\n<p>In practice, I calculate the hit rate directly from status values, which gives me a quick indication of whether the pool is too small or whether full scans or inefficient plans are driving down the cache hit rate.<\/p>\n<pre><code>-- Approximate hit rate:\nSHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';\nSHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';\n-- Formula: 1 - (Innodb_buffer_pool_reads \/ Innodb_buffer_pool_read_requests)<\/code><\/pre>\n<p>In addition, the following values help guide me:<\/p>\n<ul>\n  <li>Innodb_pages_read\/Innodb_pages_written: Read\/Write Load Ratio<\/li>\n  <li>Innodb_buffer_pool_pages_dirty: Number of dirty pages<\/li>\n  <li>Innodb_checkpoint_age and checkpoint duration (via SHOW ENGINE INNODB STATUS)<\/li>\n<\/ul>\n<p>When I combine this data with iostat\/vmstat, I can quickly determine whether the bottleneck is the CPU, memory, or storage. A significant increase in the `innodb_buffer_pool_reads` count while query volume remains stable is a clear signal to me that I need to increase the pool size or review the query plans.<\/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\/mariadb-buffer-pool-sizing-guide-5121.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Practical Tuning: Step by Step<\/h2>\n<p>I'll start with a conservative <strong>Setting<\/strong> based on the RAM allocation and monitor the system under load. Afterward, I collect data on hit rate, I\/O, swap, and CPU usage to inform the next steps. I then adjust `innodb_buffer_pool_size` in 10\u201320 percent increments, paying attention to compatibility with chunk size and the maximum number of chunks. Modern MariaDB versions allow for dynamic adjustments, which helps me keep changes brief during maintenance windows. After each adjustment, I compare the response times of key queries to ensure the benefits of the larger <strong>Caches<\/strong> remains measurable.<\/p>\n\n<h2>Online Resizing in Practice<\/h2>\n<p>When making changes online, I take a structured approach to avoid fragmentation and unnecessary reorganizations:<\/p>\n<ol>\n  <li>I check <strong>innodb_buffer_pool_chunk_size<\/strong> and <strong>innodb_buffer_pool_instances<\/strong>, so that the new target value can be accurately represented by combining the instance and chunk sizes.<\/li>\n  <li>I'll increase the size using <strong>SET GLOBAL innodb_buffer_pool_size = \u2026<\/strong> Proceed in moderate steps and closely monitor RAM usage and any latency spikes.<\/li>\n  <li>Meanwhile, I'm monitoring dirty pages, page cleaner activity, and checkpoint duration to rule out any side effects.<\/li>\n  <li>I document baseline metrics before and after the change (hit rate, 95th and 99th percentiles of response times) so that the measure can be evaluated objectively.<\/li>\n<\/ol>\n<p>For significant scale-ups, I also schedule a short maintenance window, because the internal reorganization of chunks can take time depending on the version, the number of instances, and the load profile.<\/p>\n\n<h2>Limitations and Technical Constraints<\/h2>\n<p>Very small pool sizes are of little use because the administrative overhead and false accesses then become disproportionately high; on the other hand, settings that are too large restrict <strong>OS Resources<\/strong> unnecessary. Above a certain size, the `innodb_buffer_pool_instances` option can reduce locks, while more recent recommendations suggest using a smaller number of instances. I keep the number of instances as low as possible and only increase it when actual contention becomes apparent. When resizing online, I pay attention to the <strong>Chunk size<\/strong>, so that the new value is applied correctly and no performance dips occur. I set upper limits per instance pragmatically to limit administrative overhead and fragmentation.<\/p>\n\n<h2>NUMA, HugePages, and Swappiness<\/h2>\n<p>On larger hosts, I take into account the <strong>NUMA topology<\/strong>, so that the buffer pool doesn't accidentally \u201estarve\u201c on a single node. I use an even memory distribution (interleaved) or pin the service specifically when the load is heavily localized. <strong>Transparent Huge Pages<\/strong> I disable it to ensure predictable latency behavior and use static HugePages only where they provide demonstrable benefits. The Linux parameter <strong>vm.swappiness<\/strong> I keep it conservative (low) so that the kernel doesn't aggressively swap out and the InnoDB cache can keep its hot data in RAM.<\/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\/buffer_pool_sizing_office_4729.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Overall view of the storage facility<\/h2>\n<p>Good sizing takes into account the entire <strong>Energy Storage Balance<\/strong> the machine, not just the InnoDB cache. I allocate space for the file system cache, connections, logs, background processes, and, if necessary, other applications. For InnoDB-heavy workloads, I keep the MyISAM key buffer small to avoid tying up unnecessary resources. On shared hosting servers, I use a more conservative estimate to accommodate load spikes caused by web servers, PHP-FPM, or caching services. This coordination prevents bottlenecks and contributes to consistent <strong>Response times<\/strong> with.<\/p>\n\n<h2>Containers and virtualization<\/h2>\n<p>In containers and VMs, I make sure that the process view is set to <strong>available RAM<\/strong> (cgroups\/Quota) matches the actual allocation. Otherwise, ballooning, overcommitment, and hard memory limits can lead to unexpected swapping or OOM kills. I size the buffer pool based on the <em>guaranteed<\/em> Monitor the guest's RAM and also keep an eye on the host side to prevent silent bottlenecks from occurring.<\/p>\n\n<h2>Real-world examples of common scenarios<\/h2>\n<p>On a small VPS with 4 GB, I plan to allocate about 2 GB for the <strong>Buffer<\/strong> so that the web server, PHP, and the operating system have enough memory and no swapping occurs. A medium-sized database server with 16 GB should aim for 10\u201312 GB, which allows intranet applications with many short transactions to benefit from high <strong>Hit rate<\/strong> benefit. A 64-GB OLTP host often ends up at 40\u201348 GB, and I also check whether it makes sense to use multiple instances. In all cases, I re-evaluate the change after a short period and adjust it based on actual usage patterns. This way, I maintain a healthy balance between memory and I\/O, rather than relying solely on a static number.<\/p>\n\n<h2>OLTP vs. Reporting and Long-Running Jobs<\/h2>\n<p>Different <strong>Access pattern<\/strong> have a significant impact on the ideal pool size. OLTP workloads benefit particularly when the hot set fits into RAM and the LRU queue remains stable. Reporting or ETL jobs with large scans, on the other hand, can \u201edisplace\u201c the cache. For this, I rely on <strong>innodb_old_blocks_time<\/strong>, so that full scans don't immediately overwrite the \"hot\" pages in the Young sublist. At the same time, I schedule heavy reports during off-peak hours or isolate them on replicas so that the primary server meets its latency targets.<\/p>\n\n<h2>Interaction with Other Parameters<\/h2>\n<p>The pool has the greatest impact, but other <strong>Parameters<\/strong> round out the picture. I pay attention to `innodb_log_file_size` and `innodb_log_buffer_size` to ensure that write paths remain efficient and checkpoints don\u2019t occur too frequently. Settings for connections and threads tailor concurrency to the workload profile. I fine-tune flush strategies and checkpointing logic so that load spikes have less of an impact. Only when the central <strong>Buffer<\/strong> If you do a thorough job, this fine-tuning is really worth it.<\/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\/mariadb_bufferpool_guide_8423.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Redo Log, Dirty Pages, and Checkpoints<\/h2>\n<p>Write load and buffer size are closely related to the <strong>Redo Log Capacity<\/strong> and is linked to the number of dirty pages. If the pool is larger, more dirty pages may accumulate; if the redo logs are too small, InnoDB forces checkpoints more frequently and creates peak loads. I therefore believe <strong>innodb_log_file_size<\/strong> and set the log pool to match the write rate, and measure the checkpoint duration. With <strong>innodb_max_dirty_pages_pct<\/strong> (and its low-watermark counterpart), I control when more aggressive flushing begins. On SSDs, I typically disable HDD-oriented optimizations such as <strong>innodb_flush_neighbors<\/strong>, whereas on rotating reels I tend to flush more conservatively. The <strong>innodb_flush_method<\/strong> I choose the appropriate settings based on the file system and controller to avoid double caching and ensure consistent latencies.<\/p>\n\n<h2>Storage Factors: SSD vs. HDD<\/h2>\n<p>The slower the storage, the more a generous buffer pool contributes to latency. On fast NVMe SSDs, sizing remains important, but the difference between a 95% and 99% % hit rate is less noticeable than on HDD-based infrastructure. I monitor queue depth, latency percentiles, and write amplification. If the I\/O paths are already operating at their limits, I address the following in this order: query plans, indexes, buffer pool, redo logs, and finally storage capacity.<\/p>\n\n<h2>Monitoring in Practice<\/h2>\n<p>Lasting success requires reliable <strong>Metrics<\/strong>. I combine Performance Schema data with system metrics to keep track of the hit rate, I\/O load, RAM usage, and swap usage. A high read load with a declining rate usually indicates that space is running out or that query plans are inefficient. To get started quickly with Performance Schema monitoring, I use this <a href=\"https:\/\/webhosting.de\/en\/mysql-performance-schema-monitoring-tool\/\">Monitoring tool<\/a> as a guide. The correlation remains important: I evaluate this only in terms of the interplay between cache hits, I\/O, and query times. <strong>Result<\/strong> Correct.<\/p>\n\n<h2>Buffer Warmup and Persistence<\/h2>\n<p>After a restart, I want to keep the warm-up phase short. I activate the <strong>Dump\/Load<\/strong> of the buffer pool during shutdown and startup, so that frequently used pages return to RAM more quickly. In addition, I preload specific hot tables (e.g., using calibrated SELECT statements) if the pattern is very stable. It remains critical not to overload the OS: I monitor RAM, I\/O, and CPU usage as the cache fills up, and prioritize production load over aggressive preloading.<\/p>\n\n<h2>Quick Checklist for Everyday Life<\/h2>\n<ul>\n  <li>Set the initial value: 60\u201380 % RAM (dedicated) or 40\u201360 % (shared) \u2013 leave a healthy OS buffer.<\/li>\n  <li>Determine the hot set: Sum the tables and indexes of the most frequently used queries; target coverage of 80\u201390 %.<\/li>\n  <li>Measure the hit rate: 1 \u2212 (reads\/read_requests) \u2265 99; aim for %; check parallel I\/O and response times.<\/li>\n  <li>Increase in 10\u201320 % increments; after each increment, verify latencies, dirty pages, and checkpoints.<\/li>\n  <li>Adjust redo logs and the flush strategy to match the write load; smooth out checkpoint spikes.<\/li>\n  <li>Check NUMA\/Swappiness\/THP, respect container limits, and strictly avoid swap.<\/li>\n  <li>Speed up the warm-up (Dump\/Load); \u201edebug\u201c full scans using `old_blocks_time`.<\/li>\n  <li>If latency persists despite a large pool, investigate plans, indexes, and locking\u2014don't just increase RAM.<\/li>\n<\/ul>\n\n<h2>Briefly summarized<\/h2>\n<p>I dimension the <strong>Buffer<\/strong> First, I look at the available RAM, and then I check the active data against actual usage. The goal is to ensure that approximately 80\u201390 percent of the hot data fits into the pool and that the hit rate is around 99 percent. I then fine-tune the settings in 10\u201320 percent increments until I\/O and response times are optimal. I consistently take into account limits imposed by instances, chunk sizes, and the system\u2019s overall requirements to prevent bottlenecks. This combination of clear guidelines, measurement, and targeted adjustment ensures that your MariaDB instance runs reliably and with low <strong>Latency<\/strong> works.<\/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\/buffer-pool-szenario-4937.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>","protected":false},"excerpt":{"rendered":"<p>A practical guide to MariaDB buffer pool sizing with clear rules of thumb and example values. Learn how to optimally size the InnoDB buffer pool to significantly improve the performance of your MariaDB database. Focus on buffer pool sizing for stable workloads.<\/p>","protected":false},"author":1,"featured_media":20787,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-20794","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":"143","_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":"Buffer Pool","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":"20787","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20794","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=20794"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20794\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/20787"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=20794"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=20794"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=20794"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}