{"id":21199,"date":"2026-08-31T11:49:34","date_gmt":"2026-08-31T09:49:34","guid":{"rendered":"https:\/\/webhosting.de\/linux-cgroup-v2-memory-controller-erklaerung-hosting-resourcen-focus\/"},"modified":"2026-08-31T11:49:34","modified_gmt":"2026-08-31T09:49:34","slug":"linux-cgroup-v2-memory-controller-explanation-focus-on-hosting-resources","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/linux-cgroup-v2-memory-controller-erklaerung-hosting-resourcen-focus\/","title":{"rendered":"The Linux cgroup v2 Memory Controller Explained \u2013 Setting Clear Resource Limits"},"content":{"rendered":"<p>I explain how <strong>cgroup v2<\/strong> uses its memory controller to properly enforce memory limits, protect services, and contain local OOM events. This allows administrators to set clear <strong>Resources<\/strong>-Establish rules, control peak loads, and protect critical processes against power shortages.<\/p>\n\n<h2>Key points<\/h2>\n<p>The following list summarizes the key points I discuss in detail in the article.<\/p>\n<ul>\n  <li><strong>Uniform<\/strong> Architecture: cgroup v2 simplifies control and monitoring.<\/li>\n  <li><strong>Hard<\/strong> Limit: memory.max prevents uncontrolled allocations.<\/li>\n  <li><strong>Gentle<\/strong> Brake: memory.high reduces pressure without causing immediate kills.<\/li>\n  <li><strong>More targeted<\/strong> Protection: `memory.low` and `memory.min` prioritize services.<\/li>\n  <li><strong>Transparent<\/strong> Check: `memory.current` provides measurement values for tuning.<\/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\/serverraum-ressourcen-6912.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>How cgroup v2 Handles Memory Differently<\/h2>\n\n<p>I summarize processes in <strong>Control<\/strong> I group them together and manage their memory requirements as a single unit. With version v2, the kernel standardizes interfaces, allowing me to apply limits, protection thresholds, and telemetry consistently. The memory logic separates hard isolation from soft throttling, which doesn\u2019t immediately choke off allocations but slows them down in an orderly manner. This allows me to respond to outliers without affecting the entire system, because terminations occur locally within the affected group. For hosting and containers, this provides predictable <strong>Resources<\/strong>-Allocation and predictable responses to load spikes.<\/p>\n\n<p>I use these features to bundle services with similar profiles and establish clear rules. I keep containers, PHP workers, and database processes neatly separated so that each set of workloads has its own boundaries. This helps me avoid cross-contamination, such as global memory pressure that affects harmless jobs. This isolation can be refined step by step until the load distribution responds predictably. This allows me to gain <strong>Predictability<\/strong> during operations and keep service quality on track during peak demand.<\/p>\n\n<h2>An Overview of Tax Files<\/h2>\n\n<p>Memory management revolves around just a few <strong>Parameters<\/strong>, which I set in the cgroup filesystem. Each cgroup is assigned its own values for hard limits, soft throttling points, and safety thresholds. This allows me to scale from mild reclaim to uncompromising isolation, depending on the importance of the service. Monitoring simultaneously reads the current usage and issues an alert when protection thresholds are triggered. This creates a closed-loop control system consisting of specifications and measured values, which <strong>Resources<\/strong>-makes consumption manageable.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parameters<\/th>\n      <th>Kind<\/th>\n      <th>Effect<\/th>\n      <th>Typical use<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>memory.max<\/td>\n      <td>Hard <strong>Border<\/strong><\/td>\n      <td>Blocks new allocations above the limit; local OOM kill<\/td>\n      <td>Databases, JVMs, PHP-FPM pools with clear caps<\/td>\n    <\/tr>\n    <tr>\n      <td>memory.high<\/td>\n      <td>Soft <strong>brake<\/strong><\/td>\n      <td>Increases Reclaim and latency during allocations; no instant kills<\/td>\n      <td>Gentle De-escalation Before Things Escalate<\/td>\n    <\/tr>\n    <tr>\n      <td>memory.low<\/td>\n      <td>Soft<strong>Protection<\/strong><\/td>\n      <td>Best possible protection against reclaim below the threshold<\/td>\n      <td>Key middleware, caches, central services<\/td>\n    <\/tr>\n    <tr>\n      <td>memory.min<\/td>\n      <td>Harder <strong>Protection<\/strong><\/td>\n      <td>No \"Reclaim\" below the threshold; OOM tends to affect other groups more<\/td>\n      <td>Critical Core Components<\/td>\n    <\/tr>\n    <tr>\n      <td>memory.current<\/td>\n      <td>Live-<strong>Value<\/strong><\/td>\n      <td>Shows current usage; basis for alerts and tuning<\/td>\n      <td>Dashboards, Trend Analyses<\/td>\n    <\/tr>\n    <tr>\n      <td>memory.oom.group<\/td>\n      <td>Kill-<strong>Scope<\/strong><\/td>\n      <td>Aggregates OOM kills at the group level<\/td>\n      <td>Consistent termination of related processes<\/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\/linuxcgroup-memory-2321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Understanding Hierarchies and Inheritance<\/h2>\n\n<p>I'm setting up cgroups <strong>hierarchical<\/strong>: Parent groups define the framework; children inherit limits and share the available memory. This structure makes constraints predictable but requires clear rules. The parent's `memory.max` limits the total amount of memory for the children; `memory.low` and `memory.min` act as <strong>Priorities<\/strong>: A group with a higher protection level is more likely to retain its base memory, while less important groups are reclaimed more aggressively. This helps me secure critical paths without compromising global limits.<\/p>\n\n<p>I note that the protection values <strong>additive<\/strong> The idea is this: If the memory.min values are set too high across all child nodes, it blocks reclamation in the hierarchy and shifts the pressure upward, all the way to the host. That\u2019s why I calibrate protection budgets per level and always leave a buffer free. In tiered models, I define classes (critical, important, best effort) and apply consistent bandwidths and protection thresholds for each class. This keeps load distribution fair and transparent\u2014even when teams manage subgroups independently.<\/p>\n\n<h2>Hard Limit: Setting `memory.max` Correctly<\/h2>\n\n<p>I set <strong>memory.max<\/strong> so that the process has enough headroom for spikes but does not dominate the server. To do this, I measure realistic peaks, add a buffer, and then consistently cap the usage. If a service hits this upper limit, no further allocations are made, and the kernel terminates local processes within the group. This encapsulation prevents domino effects on other workloads. For memory-hungry services, this provides clear <strong>Security<\/strong> without cross-damage.<\/p>\n\n<p>For large heaps or caches, I deliberately build in buffers, because garbage collection and background tasks cause fluctuations. I validate the limit with load tests to ensure that OOM events do not occur during normal operation. If usage remains consistently close to the limit, I first increase the reserve or reduce the actual workload. This way, I keep the margin for error small and efficiency high. This discipline pays off in <strong>Availability<\/strong> from.<\/p>\n\n<h2>Gentle Braking: memory.high in Everyday Life<\/h2>\n\n<p>With <strong>memory.high<\/strong> I set a warning and throttling threshold before the hard limit. If the group exceeds that threshold, the kernel activates Reclaim and slows down allocations without immediately cleaning up. I use this time to flush caches, stagger batch loads, or lower request limits. This allows me to smooth out peaks before kills become necessary. This improves the <strong>Service quality<\/strong> during sudden load spikes.<\/p>\n\n<p>I make sure to set a noticeable gap between `memory.high` and `memory.max` so the system has some real breathing room. If the gap is too small, I run out of memory (OOM) too quickly. If it\u2019s too large, I lose control over latencies. I test both under production profiles and calibrate the sweet spot. This allows me to create a reliable <strong>Throttle<\/strong>, which takes effect in a timely manner.<\/p>\n\n<h2>Swap Policy: Choose `memory.swap.max` Carefully<\/h2>\n\n<p>I determine whether and to what extent a group <strong>Swap<\/strong> may use. With `memory.swap.max`, I can limit swapping separately from the RAM limit. If I set the value to 0, I disable swapping for the group\u2014which is useful for latency-sensitive services that must not block. If I allow moderate swapping, I gain flexibility for caches and rarely accessed pages. It\u2019s important that I <strong>urgency<\/strong> Understand the different types of workloads: Databases and JVMs often benefit from strict or very tight swap policies, while batch or reporting jobs are more flexible when it comes to swapping.<\/p>\n\n<p>I coordinate the swap strategy with the host configuration (e.g., swappiness, zram\/zswap) to ensure that the measures do not conflict with one another. Excessive swap only masks memory shortages in the short term and shifts the load to I\/O\u2014I use it specifically as <strong>Buffer<\/strong>, not as a permanent condition. Metrics such as major page faults and latencies quickly reveal whether swapping helps or hinders performance. This is how I keep delays and tail latencies under control.<\/p>\n\n<h2>Protection thresholds: memory.low and memory.min<\/h2>\n\n<p>I use <strong>memory.low<\/strong>, to reserve base memory for important services. As long as usage remains below this threshold, the kernel spares this portion and prefers to reclaim memory elsewhere. For highly prioritized components, I also use `memory.min`. This hard protection threshold makes it clear to the kernel that I do not allow reclamation here. This ensures that the core of an application remains functional even under extreme load and <strong>responsive<\/strong>.<\/p>\n\n<p>I set the weighting deliberately: central databases get `memory.min`, critical middleware gets `memory.low`, and non-critical batch jobs get no extra protection. This prioritization makes it easier to make decisions during bottlenecks. If an OOM occurs, this classification protects my key paths. I retain control over which processes give up memory first. This gives me clear <strong>Priorities<\/strong> in the event of bottlenecks.<\/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-memory-control-explained-2984.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Transparency: memory.current in Monitoring<\/h2>\n\n<p>I read <strong>memory.current<\/strong> I continuously monitor it and correlate it with application metrics. This allows me to identify trends, backlog buildup, and spikes. If the system detects an increase in instances where `memory.high` is exceeded or in OOM events, I adjust the limits or the workload. Dashboards and alerts give me a head start in addressing issues. From this data, I derive <strong>Tuning<\/strong>-decisions that prevent absences in the long term.<\/p>\n\n<p>In addition to the value itself, I monitor page fault rates, cache hit rates, and latencies. This view shows whether reclaim is causing excessive slowdowns or whether protection mechanisms are kicking in. I adjust intervals and thresholds until the alerts are useful rather than annoying. Then I automate countermeasures such as cache trim or queue limiting. This ensures that the response remains fast and <strong>targeted<\/strong>.<\/p>\n\n<h2>Telemetry in Depth: memory.stat, memory.events, and PSI<\/h2>\n\n<p>I'm adding the following to `memory.current`: <strong>memory.stat<\/strong> and <strong>memory.events<\/strong>, to identify causes rather than just symptoms. `memory.stat` breaks down usage by Anon, File Cache, Slab, and other categories. From these percentages, I can tell whether an application\u2019s allocations or the page cache are growing\u2014and adjust accordingly (e.g., cache sizes vs. number of workers). memory.events and memory.events.local count triggers such as violations of low\/high\/max limits as well as <strong>oom<\/strong> and <strong>oom_kill<\/strong>. This provides reliable triggers for alerts and automated remediation.<\/p>\n\n<p>I also use <strong>PSI<\/strong> (Pressure Stall Information) to quantify pressure rather than guess at it. If Memory-PSI values rise continuously, threads experience delays; I throttle the workload, increase `memory.high`, or free up bandwidth in the pipeline. Overall, this generates telemetry that gives me a gradual <strong>Early warnings<\/strong> provides\u2014before strict limits are enforced.<\/p>\n\n<h2>Containers and orchestration<\/h2>\n\n<p>If I set memory limits in Kubernetes, they end up as <strong>cgroup<\/strong>-Values such as `memory.max` and, optionally, `memory.high` in the runtime. The orchestration applies policies on a per-pod basis, while I define the specifics for each namespace or deployment. To ensure reliable SLOs, I link limits to HPA strategies and pod budgets. This holistic approach prevents individual pods from dominating memory usage. A good introduction to <a href=\"https:\/\/webhosting.de\/en\/cgroups-hosting-resource-isolation-linux-containerlimits-serverboost\/\">Resource Isolation with cgroups<\/a> makes it easier to plan containers with clear boundaries and access routes.<\/p>\n\n<p>I also check whether sidecars and init containers are assigned their own limits, so that auxiliary processes don't restrict core workloads. For stateful workloads, I set `memory.low` or `memory.min` so that caches and buffers don't shrink immediately. I document these decisions in the deployment so the team can easily understand them. This way, I ensure <strong>Consistency<\/strong> between infrastructure and applications. The result is predictable workload profiles.<\/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_Linux_cgroup_7458.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Systemd Integration and Automation<\/h2>\n\n<p>I use systemd to set cgroup v2 parameters declaratively: <strong>MemoryMax<\/strong> is equal to memory.max, <strong>MemoryHigh<\/strong> the memory.high, <strong>MemoryLow<\/strong> and <strong>MemoryMin<\/strong> set protection lines, <strong>MemorySwapMax<\/strong> is managed by Swap. This mapping makes policies transparent in the code repository and simplifies rollbacks. In larger environments, I use it to orchestrate consistent <strong>Standards<\/strong> per service class and decouple operations from manual interventions.<\/p>\n\n<p>For automated interventions, I combine events from memory.events\/PSI with policy engines. If a group repeatedly exceeds `memory.high`, I simultaneously reduce the number of workers, limit burst rates, or trigger <strong>targeted<\/strong> Cache trim. If these steps don't work, I let the system's built-in OOM mechanisms take effect in a controlled manner\u2014the `memory.oom.group` setting ensures that the effect remains local and predictable. This results in a gradual, self-healing behavior without any surprises.<\/p>\n\n<h2>Multi-Tenant Hosting with CloudLinux<\/h2>\n\n<p>I encapsulate customer environments in separate <strong>cgroups<\/strong> and set clear limits for each tenant. CloudLinux complements this with tools that allocate RAM, CPU, and I\/O on a per-account basis. This keeps neighboring-account effects manageable, and prevents individual outliers from dragging down all accounts. For those who want to dive deeper, here\u2019s a practical overview of <a href=\"https:\/\/webhosting.de\/en\/cgroup-v2-cloudlinux-shared-hosting-stable\/\">CloudLinux and cgroup v2<\/a> in the context of shared hosting. This allows me to maintain fair <strong>Resources<\/strong>-Distribution across many customers.<\/p>\n\n<p>I set `memory.max` per customer based on the measured daily profile, assign a `memory.low` value to caches, and protect core processes with `memory.min`. When limits are exceeded, throttling mechanisms kick in first, rather than abruptly halting accounts. If an OOM occurs, it affects only the affected group locally. This ensures that the platform remains available to other tenants. This approach strengthens <strong>Plannability<\/strong> compared to traffic spikes.<\/p>\n\n<h2>Special Cases: Page Cache, THP, and Large Pages<\/h2>\n\n<p>I differentiate between <strong>Anon<\/strong>-Memory (heaps, stacks) and <strong>File Cache<\/strong> (Page Cache). Under heavy load, it\u2019s easier to free up file cache, while anonymous pages require swapping or lead to OOM. `memory.high` and protection limits help me reclaim file cache without affecting critical heaps. For Transparent Huge Pages (THP), I check whether they benefit the application or increase fragmentation and latency\u2014depending on the profile, I adjust the THP policy to ensure that it continues to work well with the memory controller.<\/p>\n\n<p>Uses an application <strong>Hugepages<\/strong> Specifically, I isolate their memory requirements from RAM management using the corresponding controllers. This prevents large pages from displacing regular RAM. I keep these special reserves tightly managed and coordinate them with the other limits to avoid unexpected bottlenecks. Overall, this establishes clear guidelines for regular and special memory usage.<\/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_cgroup_me_script_1283.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Best Practices for Limits<\/h2>\n\n<p>I start with real-world usage profiles and set <strong>memory.max<\/strong> I leave some headroom so that peaks don't immediately trigger an OOM. I set `memory.high` noticeably lower to smooth out load spikes and slow down allocations. Prioritization is key: the database gets `memory.min`, middleware gets `memory.low`, and batch loads are not given special treatment. Monitoring accompanies operations and shows whether thresholds are effective or have been set too strictly. Based on these signals, I adjust limits and simultaneously increase the <strong>Efficiency<\/strong> the application.<\/p>\n\n<p>I document the metrics for each service, explain the rationale behind them, and record changes in a way that\u2019s easy to trace. This helps me ensure that decisions are firmly established within the team and prevents guesswork weeks down the line. Before making updates or architectural changes, I review trend charts to avoid tightening or loosening settings blindly. A small test environment saves a lot of trouble later in production. This rhythm ensures <strong>Constance<\/strong> in day-to-day business.<\/p>\n\n<h2>Practical Exercise: Organizing Web Hosting Servers<\/h2>\n\n<p>I create a separate one for each customer <strong>cgroup<\/strong> and move PHP-FPM, the database, and the cache into it. I allocate `memory.max` plus a buffer to each set, while `memory.high` takes precedence and smooths out fluctuations. Critical customer services are given protection limits to ensure their core memory doesn\u2019t drop. Logs and dashboards show which processes are slowing things down, which are causing spikes, and where OOM is a threat. Additionally, tips on <a href=\"https:\/\/webhosting.de\/en\/server-context-isolation-namespaces-cgroups-hosting-security\/\">Namespaces and Isolation Concepts<\/a>, so that clients remain clearly separated and <strong>Security<\/strong> increases.<\/p>\n\n<p>I also adjust the number of PHP workers, OPcache sizes, and query caches to reduce memory footprints. Often, simply reducing memory spikes using `memory.high` is enough to cut down on time. For testing, I use real-world load patterns, not synthetic ideal values. Afterward, I document new limits and link them to SLAs. This way, the <strong>Transparency<\/strong> toward customers and internal support.<\/p>\n\n<h2>Troubleshooting Memory Printing<\/h2>\n\n<p>Rises <strong>memory.current<\/strong> When things are moving fast, I first check for changes in traffic, deployments, or configurations. I compare the trends in high-threshold violations, page faults, and latencies. If OOMs occur in succession, I identify the affected processes via the kernel log and adjust limits or the workload. If the cause lies in faulty caches, I perform targeted trimming rather than applying a global solution. This diagnostic chain quickly leads me to the <strong>Cause<\/strong>, not just a symptom.<\/p>\n\n<p>If the load remains high, I scale back operations: lower burst limits for Ingress, reduce queue lengths, and reschedule batch jobs. At the same time, I temporarily increase `memory.high` to buy some breathing room without raising `memory.max`. If I find memory leaks, I tighten the guardrails until a fix is in place. In stubborn cases, I reduce the service scope or replicate the instance. That\u2019s how I keep the <strong>Operation<\/strong> Reliable operation, even under pressure.<\/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-cgroup-memory-4297.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Automation: Event-Driven Countermeasures<\/h2>\n\n<p>I'm tying <strong>Actions<\/strong> For events: `memory.events` provides counters that I process using a watcher or metrics pipeline. In the event of repeated high-hit counts, I selectively flush caches, reduce concurrency, or initiate reclaim attempts before users notice anything. If mild interventions fail, I switch to hard measures: request throttling, queue draining, and prioritization changes. It\u2019s important that decisions <strong>deterministic<\/strong> are\u2014same triggers, same reactions\u2014so that teams can understand and replicate the behavior.<\/p>\n\n<p>I'm also keeping the <strong>Scope<\/strong> Keeping an eye on OOM. With `memory.oom.group`, I avoid partial kills that put applications into inconsistent states. If something needs to be terminated, it should be done in a coordinated and swift manner so that remaining capacity is quickly available again. Combined with telemetry and documented playbooks, this creates a robust feedback loop that holds up under real production conditions.<\/p>\n\n<h2>Outlook and summary<\/h2>\n\n<p>The memory controller from <strong>cgroup<\/strong> v2 provides me with a tiered set of tools: hard caps, soft brakes, and guard lines with clear priorities. By deliberately using `memory.max`, `memory.high`, `memory.low`, and `memory.min`, I can respond systematically to sudden spikes in load and keep services running. Monitoring via `memory.current` provides early warning of where limits are being reached or reserves are running low. In container and multi-tenant setups, these mechanisms ensure fair resource allocation without causing collateral damage. With discipline, metrics, and small corrective steps, I achieve reliable <strong>Performance<\/strong> \u2013 from a single virtual machine to a heavily loaded host.<\/p>","protected":false},"excerpt":{"rendered":"<p>Learn how the Linux cgroup v2 memory controller works and how to build stable hosting and container environments using targeted Linux resource limits.<\/p>","protected":false},"author":1,"featured_media":21192,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21199","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":"225","_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":"cgroup v2","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":"21192","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21199","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=21199"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21199\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/21192"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=21199"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=21199"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=21199"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}