{"id":4568,"date":"2026-09-19T01:02:15","date_gmt":"2026-09-18T19:32:15","guid":{"rendered":"https:\/\/cpanelfree.com\/blog\/systemd-resource-management-with-cgroups-v2-for-multi-tenant-web-servers\/"},"modified":"2026-09-19T01:02:15","modified_gmt":"2026-09-18T19:32:15","slug":"systemd-resource-management-with-cgroups-v2-for-multi-tenant-web-servers","status":"publish","type":"post","link":"https:\/\/cpanelfree.com\/blog\/systemd-resource-management-with-cgroups-v2-for-multi-tenant-web-servers\/","title":{"rendered":"Systemd Resource Management with cgroups v2 for Multi-Tenant Web Servers"},"content":{"rendered":"

In high-density web hosting environments, unconstrained tenant processes\u2014such as runaway PHP-FPM worker pools, unindexed MySQL queries, or memory-leaking background scripts\u2014can rapidly trigger catastrophic noisy-neighbor resource starvation across an entire production server. At CpanelFree<\/a>, isolating multi-tenant web workloads on bare-metal infrastructure requires moving beyond antiquated POSIX ulimits and fragmented cgroups v1 hierarchies to a unified, deterministic control plane. By combining systemd unit slices with modern Linux cgroups v2 controllers, systems architects can enforce strict CPU fair-share weights, dual-tier memory thresholds, NVMe block I\/O throttles, and atomic process group lifecycle controls without the hypervisor virtualization penalty.<\/p>\n

<\/p>\n

Understanding cgroups v2 Architecture in Modern Multi-Tenant Web Hosting<\/h2>\n
\n

Direct Answer:<\/strong> Systemd cgroups v2 resource management enforces deterministic tenant isolation through a unified single-hierarchy tree mounted at \/sys\/fs\/cgroup<\/code>. By defining nested systemd slices, administrators configure proportional CPU scheduling (CPUWeight<\/code>), dual-stage memory throttling (MemoryHigh<\/code>, MemoryMax<\/code>), and absolute NVMe I\/O limits (IOReadBandwidthMax<\/code>, IOWriteBandwidthMax<\/code>) to completely eliminate noisy-neighbor server degradation.<\/p>\n<\/div>\n

The historical architecture of Linux Control Groups (cgroups v1) suffered from a fundamental design flaw: individual resource controllers (CPU, memory, blkio, freezer, pids) operated in completely disconnected filesystem hierarchies under \/sys\/fs\/cgroup\/<controller>\/<\/code>. Because these subsystems did not communicate, the Linux kernel could not accurately attribute buffered disk writeback to the specific tenant that allocated the dirty pages. If a rogue PHP script flushed hundreds of megabytes of file uploads into page cache, the kernel flush daemon (kworker<\/code>) attempted to write the data asynchronously. The blkio<\/code> controller saw these writes originating from kernel threads rather than the tenant cgroup, rendering disk throttles useless and locking up NVMe queues for every tenant on the host.<\/p>\n

Control Groups v2 (cgroups v2), fully integrated into modern Linux kernels and systemd, resolves this paradigm through a strictly unified hierarchy. Mounted at \/sys\/fs\/cgroup<\/code>, every process belongs to exactly one cgroup path in a single coherent tree. Controllers are enabled selectively down the tree using cgroup.subtree_control<\/code>, enforcing the structural rule that internal nodes cannot host worker processes\u2014only leaf nodes execute code. Because memory allocation, page cache caching, and block I\/O writeback are unified in the same kernel context, storage throttling acts deterministically on both synchronous read calls and asynchronous buffered write operations.<\/p>\n

Legacy cgroups v1 vs Unified cgroups v2: Production Comparison Matrix<\/h2>\n

The following comparative matrix outlines why modern enterprise hosting stacks mandate systemd with cgroups v2 over legacy implementations:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
Feature \/ Subsystem Metric<\/th>\nStandard cgroups v1 (Legacy Default)<\/th>\nTuned cgroups v2 + Systemd (Production)<\/th>\n<\/tr>\n<\/thead>\n
Control Hierarchy<\/td>\nOrthogonal, independent trees per controller (\/sys\/fs\/cgroup\/*)<\/td>\nUnified single tree hierarchy (\/sys\/fs\/cgroup)<\/td>\n<\/tr>\n
Page Cache & Buffered I\/O<\/td>\nUntracked writeback; attributed incorrectly to root kworkers<\/td>\nDirectly attributed to originating tenant cgroup; strict writeback throttling<\/td>\n<\/tr>\n
Memory Pressure Management<\/td>\nBinary hard kill (memory.limit_in_bytes) via kernel OOM<\/td>\nTwo-stage defense: MemoryHigh (proportional throttle) + MemoryMax ceiling<\/td>\n<\/tr>\n
CPU Resource Distribution<\/td>\nCoarse shares (cpu.shares) and fragile CFS quotas<\/td>\nWeight-based fair sharing (CPUWeight 1-10000) & millisecond CPUQuota<\/td>\n<\/tr>\n
Block I\/O Throttling<\/td>\nDirect I\/O only; asynchronous writes escape throttling<\/td>\nUnified IOWeight, IOReadBandwidthMax, and IOWriteBandwidthMax (IOPS & BPS)<\/td>\n<\/tr>\n
Kernel Telemetry & PSI<\/td>\nUnreliable system load averages; no per-cgroup stall metrics<\/td>\nReal-time Pressure Stall Information (PSI) for CPU, Memory, and I\/O<\/td>\n<\/tr>\n
Process Termination Cleanup<\/td>\nFork bombing escapes SIGKILL; orphaned child worker processes<\/td>\nAtomic cgroup.kill mechanism reaps entire tenant subtree instantly<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Architecting Multi-Tenant Hierarchies with Systemd Slices<\/h2>\n

Systemd implements control groups using four basic unit concepts: slices<\/code>, scopes<\/code>, services<\/code>, and sockets<\/code>. For multi-tenant hosting, systemd slices (.slice<\/code>) represent the primary organizational boundary. A slice is an abstract grouping node that does not run processes directly; rather, it hosts child slices, individual tenant system services (like isolated PHP-FPM daemons), and interactive scopes (such as SSH sessions or cron executions).<\/p>\n

In a high-performance web architecture, the slice topology mirrors the tenant business tiers. By default, systemd provides system.slice<\/code> for core operating system daemons and user.slice<\/code> for logged-in sessions. In a dedicated multi-tenant web server, systems engineers construct an isolated customer.slice<\/code>, beneath which individual tenant slices (e.g., customer-tenant101.slice<\/code>) reside. This establishes hierarchical parent-child resource inheritance. If the parent customer.slice<\/code> is constrained to 80% total host memory and 70% CPU cycles, no combination of tenant spikes can ever starve critical system services like OpenSSH, MariaDB, or the Nginx edge reverse proxy.<\/p>\n

\n Architecture Note:<\/strong> When managing cgroups v2 through systemd, never modify raw files inside \/sys\/fs\/cgroup\/<\/code> manually. Systemd actively acts as the single cgroup manager on the operating system. Manual writes to \/sys\/fs\/cgroup<\/code> will be overwritten during unit reloads or process migrations. Always apply configurations via slice unit files or drop-in directories in \/etc\/systemd\/system\/<\/code>.\n<\/div>\n

Core cgroups v2 Subsystem Directives in Systemd<\/h2>\n

Configuring deterministic tenant isolation requires configuring four primary subsystem controllers: CPU, Memory, Block I\/O, and Task Limits (PIDs). Systemd provides native unit parameters that map directly to underlying cgroups v2 kernel interfaces:<\/p>\n

1. CPU Controller (Proportional Weight & Hard Quotas)<\/h3>\n

The CPU controller in cgroups v2 provides two complementary mechanisms: proportional fair-share distribution and absolute hard runtime limits.<\/p>\n

    \n
  • CPUWeight=100<\/code>: Replaces the legacy cpu.shares<\/code> model. Values range from 1 to 10000 (default: 100). When CPU cores are saturated, CPU cycles are divided strictly in proportion to each tenant’s assigned weight. When cores are idle, a single tenant can utilize all available compute cycles without penalty.<\/li>\n
  • CPUQuota=150%<\/code>: Enforces a strict ceiling regardless of system idle capacity. A setting of 150% limits the tenant’s processes to 1.5 full CPU cores per 100ms CFS scheduler period.<\/li>\n<\/ul>\n

    2. Memory Controller (Multi-Stage Reclamation & Protection)<\/h3>\n

    Legacy cgroups v1 only offered a binary threshold (memory.limit_in_bytes<\/code>), which immediately triggered the brutal kernel OOM killer when exceeded. In cgroups v2, systemd unlocks a four-tier defense-in-depth model:<\/p>\n

      \n
    • MemoryMin=256M<\/code>: Hard memory protection. The kernel will never reclaim memory below this threshold, guaranteeing that high-priority worker processes avoid paging latency.<\/li>\n
    • MemoryLow=512M<\/code>: Soft memory protection. Memory below this boundary will only be reclaimed if all unprotected memory on the server has been exhausted.<\/li>\n
    • MemoryHigh=2G<\/code>: The primary throttling ceiling. When a tenant exceeds this value, processes are not killed. Instead, the kernel triggers aggressive asynchronous page reclaim and intentionally throttles the allocating processes by injecting microsecond sleep delays into system calls. This gives database queries and web requests a chance to finish cleanly.<\/li>\n
    • MemoryMax=2.5G<\/code>: The unyielding absolute ceiling. If memory exceeds this value despite throttling and swapping, the kernel out-of-memory handler intervenes inside the tenant slice only.<\/li>\n
    • MemorySwapMax=512M<\/code>: Limits the amount of swap space the slice can consume, preventing disk thrashing.<\/li>\n<\/ul>\n
      \n Architecture Note:<\/strong> In multi-tenant web servers, always pair MemoryMax<\/code> with ManagedOOMMemoryPressure=kill<\/code> or systemd-oomd<\/code>. Furthermore, setting MemoryOOMScoreAdjust=-500<\/code> on core daemon services (Nginx, MySQL) and +200<\/code> on tenant slices guarantees that edge infrastructure remains online while misbehaving tenant pools are reaped cleanly.<\/div>\n

      3. Block I\/O Controller (NVMe Bandwidth & IOPS Throttling)<\/h3>\n

      Because cgroups v2 links the memory page cache directly to the block layer, systemd I\/O directives reliably control both direct I\/O and buffered asynchronous writes:<\/p>\n

        \n
      • IOWeight=100<\/code>: Fair-share scheduling on blk-mq block devices across slices (values 1 to 10000).<\/li>\n
      • IOReadBandwidthMax=\/dev\/disk\/by-id\/nvme-eui... 120M<\/code>: Enforces hard read throughput limits per second on specific NVMe drives.<\/li>\n
      • IOWriteBandwidthMax=\/dev\/disk\/by-id\/nvme-eui... 60M<\/code>: Enforces hard write throughput limits per second, capturing dirty page flushes.<\/li>\n
      • IOReadIOPSMax=5000<\/code> and IOWriteIOPSMax=2500<\/code>: Restricts random input\/output operations per second to preserve drive latency for neighboring websites.<\/li>\n<\/ul>\n

        4. Tasks and Process Limiting (Fork-Bomb Mitigation)<\/h3>\n

        A single compromised WordPress site running a recursive bash script or malicious cron loop can exhaust the operating system process table (PIDs), causing kernel starvation. Setting TasksMax=512<\/code> restricts the total concurrent threads and processes in the slice to 512, instantly neutralizing fork attacks.<\/p>\n

        Production Configuration Files & Implementation Walkthrough<\/h2>\n

        To deploy this architecture in enterprise environments, systems administrators configure kernel parameters, slice hierarchies, and unit drop-ins. Below are complete, validated production configuration templates:<\/p>\n

        Step 1: Kernel Boot Parameter Verification<\/h3>\n

        Ensure your Linux distribution (Ubuntu 22.04+, Debian 12+, AlmaLinux 9+, or RHEL 9+) has unified cgroups v2 and Pressure Stall Information (PSI) enabled at the kernel boot level. Edit \/etc\/default\/grub.d\/99-cgroups.cfg<\/code>:<\/p>\n

        # \/etc\/default\/grub.d\/99-cgroups.cfg\n# Enforce unified cgroup v2 hierarchy and enable Pressure Stall Information (PSI)\nGRUB_CMDLINE_LINUX=\"$GRUB_CMDLINE_LINUX systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all psi=1\"<\/code><\/pre>\n
        After updating the GRUB configuration, regenerate your bootloader configuration with update-grub<\/code> or grub2-mkconfig -o \/boot\/grub2\/grub.cfg<\/code> and reboot the host.<\/p>\n
        Step 2: Defining the Customer Root Slice<\/h3>\n
        Create the parent slice that bounds all tenant activity across the multi-tenant host. Create \/etc\/systemd\/system\/customer.slice<\/code>:<\/p>\n
        [Unit]\nDescription=Multi-Tenant Customer Root Slice\nDocumentation=https:\/\/cpanelfree.com\/docs\/linux-architecture\/cgroups-v2\nBefore=slices.target\n\n[Slice]\n# Overall boundaries for all combined tenants\nCPUWeight=100\nCPUQuota=600%\nMemoryHigh=24G\nMemoryMax=28G\nMemorySwapMax=4G\nTasksMax=16384\n\n# Block device IO boundaries on primary NVMe storage\nIOWeight=100\nIOReadBandwidthMax=\/dev\/disk\/by-id\/nvme-SAMSUNG_MZQL2960HCJR-00A07 1500M\nIOWriteBandwidthMax=\/dev\/disk\/by-id\/nvme-SAMSUNG_MZQL2960HCJR-00A07 800M<\/code><\/pre>\n
        Step 3: Creating Individual Tenant Slices<\/h3>\n
        Define granular boundaries for a specific hosting tenant (e.g., tenant101<\/code>). Create \/etc\/systemd\/system\/customer-tenant101.slice<\/code>:<\/p>\n
        [Unit]\nDescription=Resource Slice for Tenant 101\nDocumentation=https:\/\/cpanelfree.com\nPartOf=customer.slice\n\n[Slice]\n# Dynamic fair-share CPU allocation with burst ceiling\nCPUWeight=100\nCPUQuota=200%\n\n# Tiered Memory thresholds\nMemoryMin=128M\nMemoryLow=256M\nMemoryHigh=1800M\nMemoryMax=2048M\nMemorySwapMax=512M\n\n# Storage constraints\nIOWeight=100\nIOReadBandwidthMax=\/dev\/disk\/by-id\/nvme-SAMSUNG_MZQL2960HCJR-00A07 80M\nIOWriteBandwidthMax=\/dev\/disk\/by-id\/nvme-SAMSUNG_MZQL2960HCJR-00A07 40M\nIOReadIOPSMax=\/dev\/disk\/by-id\/nvme-SAMSUNG_MZQL2960HCJR-00A07 4000\nIOWriteIOPSMax=\/dev\/disk\/by-id\/nvme-SAMSUNG_MZQL2960HCJR-00A07 2000\n\n# Anti-forkbomb process protection\nTasksMax=384<\/code><\/pre>\n
        Step 4: Binding Tenant Services (PHP-FPM Worker Pool)<\/h3>\n
        To place the tenant’s execution processes inside their allocated slice, configure a systemd template service override. Create \/etc\/systemd\/system\/php-fpm@tenant101.service.d\/override.conf<\/code>:<\/p>\n
        [Unit]\nDescription=PHP-FPM Dedicated Pool for Tenant 101\nAfter=customer-tenant101.slice\n\n[Service]\n# Attach service directly into the tenant slice\nSlice=customer-tenant101.slice\n\n# Execution security and hardening\nUser=tenant101\nGroup=tenant101\nProtectSystem=strict\nProtectHome=read-only\nReadWritePaths=\/var\/www\/vhosts\/tenant101\/htdocs \/tmp\nPrivateTmp=true\n\n# Graceful OOM protection score adjustment\nOOMScoreAdjust=100\nKillMode=control-group\nRestart=on-failure\nRestartSec=3s<\/code><\/pre>\n
        Step 5: Kernel Memory & PSI Sysctl Optimizations<\/h3>\n
        Fine-tune kernel memory eviction behavior and asynchronous writeback buffering by deploying \/etc\/sysctl.d\/99-cgroups-psi.conf<\/code>:<\/p>\n
        # \/etc\/sysctl.d\/99-cgroups-psi.conf\n# Optimize kernel page cache writeback for cgroups v2 multi-tenancy\n\n# Lower dirty memory threshold to trigger background flushes earlier\nvm.dirty_background_ratio = 5\nvm.dirty_ratio = 10\n\n# Control kernel swap aggression (balanced for NVMe with zswap\/cgroups)\nvm.swappiness = 30\n\n# Ensure kernel respects cgroup v2 memory watermarks during reclaiming\nvm.zone_reclaim_mode = 0\n\n# Prevent kernel overcommit panic\nvm.overcommit_memory = 0<\/code><\/pre>\n
        Apply the sysctl parameters immediately using sysctl --system<\/code> and reload systemd to detect the new slice configurations with systemctl daemon-reload<\/code>.<\/p>\n
        Runtime Telemetry, Monitoring, and Pressure Stall Information (PSI)<\/h2>\n
        Monitoring multi-tenant hosts under cgroups v2 moves beyond legacy 1-minute load averages. The Linux kernel provides Pressure Stall Information (PSI), exposing exact microsecond metrics regarding how long processes were stalled waiting for CPU cycles, memory page allocations, or disk I\/O.<\/p>\n
        To inspect the live hierarchy, run the built-in systemd cgroup utilities:<\/p>\n
        # View hierarchical tree of active control groups and child tasks\nsystemd-cgls \/customer.slice\n\n# Real-time top monitor sorted by CPU, Memory, and Disk I\/O per slice\nsystemd-cgtop -m -c -p<\/code><\/pre>\n
        Administrators can query the raw kernel PSI telemetry for any individual tenant slice directly from the filesystem:<\/p>\n
        # Check memory pressure stall percentages (some vs full stalls)\ncat \/sys\/fs\/cgroup\/customer.slice\/customer-tenant101.slice\/memory.pressure\n\n# Sample Output:\n# some avg10=0.00 avg60=0.02 avg300=0.01 total=48210\n# full avg10=0.00 avg60=0.00 avg300=0.00 total=1240\n\n# Check IO pressure stall information\ncat \/sys\/fs\/cgroup\/customer.slice\/customer-tenant101.slice\/io.pressure<\/code><\/pre>\n
        In the output above, some<\/code> indicates the percentage of wall-clock time in which at least one thread in the slice was delayed waiting for resource access, whereas full<\/code> indicates that all threads in the cgroup were completely stalled. If a tenant’s memory.pressure full<\/code> spikes above 10% on a 60-second rolling window, their PHP workers are spending more time thrashing memory than executing application bytecode\u2014an actionable indicator for upselling compute tiers or optimizing database indexes.<\/p>\n
        \n  Dynamic Re-provisioning:<\/strong> In modern web orchestration, resource adjustments should not require service restarts. You can dynamically scale any slice parameter in real time using systemctl set-property<\/code>. For example: systemctl set-property customer-tenant101.slice MemoryHigh=3G CPUQuota=300%<\/code> instantly reconfigures kernel boundaries without dropping a single active client connection.<\/div>\n
        Frequently Asked Questions<\/h2>\n
        \nHow does cgroups v2 solve the buffered I\/O writeback accounting problem that plagued cgroups v1?<\/summary>\n
        In cgroups v1, the memory controller and the block I\/O controller resided in independent filesystem hierarchies. When an application executed write calls to disk, the data entered the kernel page cache managed by the memory controller, but when the background flush worker flushed those dirty pages to disk, the I\/O controller could not associate the writes with the originating cgroup. In cgroups v2’s unified single hierarchy, every page in memory carries an explicit pointer to its parent cgroup. As a result, both buffered writes and direct I\/O are correctly throttled according to the originating tenant’s IOWeight<\/code> and IOWriteBandwidthMax<\/code>.<\/p>\n<\/details>\n
        \nWhat is the operational difference between MemoryHigh and MemoryMax in a shared hosting environment?<\/summary>\n
        MemoryHigh<\/code> acts as an elastic, soft throttling ceiling. When a tenant’s memory usage crosses MemoryHigh<\/code>, the kernel actively initiates proactive page reclamation and inserts microsecond scheduling delays into allocating processes. This slows down fast allocations without crashing the web application. Conversely, MemoryMax<\/code> is an unyielding hard limit. If a tenant breaches MemoryMax<\/code> and memory cannot be reclaimed or paged to swap, the kernel invokes the OOM killer on the tenant’s processes. Utilizing MemoryHigh<\/code> ensures that temporary traffic surges trigger graceful performance degradation rather than fatal 502\/500 errors.<\/p>\n<\/details>\n
        \nCan systemd cgroups v2 resource limits be modified dynamically on live production servers without dropping active HTTP connections?<\/summary>\n
        Yes. By using the command systemctl set-property customer-tenant.slice MemoryHigh=4G CPUQuota=400%<\/code>, systemd immediately writes the updated parameters to the live \/sys\/fs\/cgroup<\/code> hierarchy and creates persistent configuration drop-ins in \/etc\/systemd\/system.control\/<\/code>. The changes take effect instantly in kernel space without restarting the slice, terminating worker processes, or dropping active HTTP\/TCP sessions.<\/p>\n<\/details>\n
        \nHow do CPU weights (CPUWeight) differ from hard quotas (CPUQuota) when provisioning multi-tenant tiers?<\/summary>\n
        CPUWeight<\/code> is a proportional fair-share allocator operating between 1 and 10000. It only restricts compute cycles when the host’s physical cores are actively contending for resources; if neighboring tenants are idle, a tenant can utilize 100% of available compute capacity. In contrast, CPUQuota<\/code> defines an inflexible runtime ceiling (e.g., 200% restricts tasks to a maximum of 2 full cores per scheduling period), regardless of whether other cores are sitting idle. Best practice for multi-tenant hosting is to combine a base CPUWeight<\/code> with a safety CPUQuota<\/code> ceiling to allow burst performance while preventing total CPU monopolization.<\/p>\n<\/details>\n
        \n
        Ready to Deploy High-Performance Infrastructure?<\/h3>\n
        Experience blazing-fast NVMe storage, unmetered bandwidth, and enterprise LiteSpeed caching on CpanelFree.<\/p>\n
          Get Started with Free Cloud Hosting →<\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
        Isolate multi-tenant web workloads with systemd and cgroups v2. Prevent noisy neighbors while enforcing deterministic CPU, memory, and NVMe limits.<\/p>\n","protected":false},"author":1,"featured_media":4567,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[181],"tags":[57,177,87,182,101],"class_list":["post-4568","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux-architecture","tag-almalinux","tag-databases-performance","tag-devops","tag-linux-architecture","tag-sysadmin"],"_links":{"self":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts\/4568","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/comments?post=4568"}],"version-history":[{"count":0,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts\/4568\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/media\/4567"}],"wp:attachment":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/media?parent=4568"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/categories?post=4568"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/tags?post=4568"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}