{"id":6354,"date":"2026-09-29T10:04:33","date_gmt":"2026-09-29T07:04:33","guid":{"rendered":"https:\/\/www.scalahosting.com\/kb\/?p=6354"},"modified":"2026-09-29T10:04:34","modified_gmt":"2026-09-29T07:04:34","slug":"spanel-limits-cgroups-v2","status":"publish","type":"post","link":"https:\/\/www.scalahosting.com\/kb\/spanel-limits-cgroups-v2\/","title":{"rendered":"We Built Resource Limits on cgroups v2 – the Same Kernel Tech Containers Run On"},"content":{"rendered":"\n

SPanel enforces per-account limits on CPU, memory, disk throughput, disk IOPS, and processes using Linux control groups (cgroups v2), the same kernel mechanism that container runtimes are built on. A small SPanel service, cpm, places each account’s processes into its own control group and re-checks once per second. You get that at no additional cost on every ScalaHosting managed VPS, with no separate operating system license.<\/p>\n\n\n\n

What are cgroups v2<\/strong><\/h2>\n\n\n\n

A control group (cgroup) is a kernel feature that groups processes together and caps what the group can consume<\/strong>. Cgroups v2 is the current generation, with a unified hierarchy and per-resource controllers for CPU, memory, disk I\/O, and process count. <\/p>\n\n\n\n

This is not an SPanel invention – it ships in the Linux kernel and underpins the container world. When you run a Docker container with a memory cap, that cap is<\/em> a cgroup.<\/p>\n\n\n\n

So SPanel points the machinery the industry already trusts for containers at hosting accounts instead; no parallel enforcement engine to learn, audit, or pay for. The kernel holds; SPanel configures.<\/p>\n\n\n\n

One control group per account<\/strong><\/h2>\n\n\n\n

When an account has performance limits set (directly or through a package<\/a>), SPanel creates a control group for it and writes the account’s ceilings in. On the package form’s Advanced Limits tab, five dials map to four standard cgroups v2 controllers:<\/p>\n\n\n\n

Limit (package dial)<\/strong><\/td>cgroups v2 controller<\/strong><\/td>What happens at the ceiling<\/strong><\/td><\/tr>
CPU Limit – 100 means one full core<\/td>cpu<\/td>Throttled to its share, never killed<\/td><\/tr>
Memory Limit (MB)<\/td>memory<\/td>Reclaimed inside that account only; worst case ends its own process<\/td><\/tr>
Storage Transfer Rate (MB\/s)<\/td>io<\/td>Queued and slowed to its lane<\/td><\/tr>
IOPS Limit (operations\/sec)<\/td>io<\/td>Queued and slowed to its lane<\/td><\/tr>
Maximum Total Processes<\/td>pids<\/td>The fork past the cap simply fails<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Two rows need a note. The CPU number is a share of a core, not of the server: 100 is one full core, 50 is half a core, 200 is two cores. And the Storage Transfer Rate and IOPS Limit dials govern storage<\/em> traffic, not network bandwidth. ScalaHosting’s managed VPS plans come with unmetered network traffic; the io controller has nothing to do with that.<\/p>\n\n\n\n

\"We<\/figure>\n\n\n\n

The<\/strong> cpm<\/strong> sweep: one second, on purpose<\/strong><\/h2>\n\n\n\n

A control group only contains the processes you put in it, and new processes spawn constantly: every PHP request, cron job, and shell. Something has to keep placing fresh ones into the right account’s group: cpm, SPanel’s control-group process manager.<\/p>\n\n\n\n

cpm runs continuously and sweeps once per second: it walks the running processes, identifies which account each belongs to, and assigns it to that account’s control group. A process that started a moment ago is picked up on the next sweep.<\/p>\n\n\n\n

That cadence sets the honesty boundary for the whole feature. <\/p>\n\n\n\n

What the sweep promises:<\/strong> any sustained workload (a plugin stuck in a loop, a memory leak climbing all afternoon) is inside its ceilings within about a second of starting, and stays there. <\/p>\n\n\n\n

What it does not promise:<\/strong> instantaneous enforcement. A new process runs unconfined for up to a second before its first sweep. For overload that lasts minutes or hours, that horizon is the right call. For sub-second microbursts, it is not a fence, and we won’t claim it is.<\/p>\n\n\n\n

Pull quote:<\/strong> “The kernel holds the line; our job is to keep every process on the right side of it, once a second, forever.”<\/p>\n\n\n\n

\"We<\/figure>\n\n\n\n

Want to see these dials on a live server?<\/strong> Every limit here ships with SPanel on a ScalaHosting managed VPS, with no separate operating-system license. Set them for a whole plan in the package form, or for one account in the Change Limits editor.<\/p>\n\n\n\n

What the ceilings feel like<\/strong><\/h2>\n\n\n\n

The behavior at each ceiling is chosen to degrade the offending account gracefully and leave its neighbors untouched. The table above lists them; two are worth dwelling on.<\/p>\n\n\n\n

Memory is the honest one. At the ceiling the kernel reclaims inside that one account’s group, and in the worst case ends the account’s own offending process, not anyone else’s. An undersized memory ceiling can terminate the account’s own worker mid-task, so the fix is sizing the dial sensibly. SPanel’s monitoring tells the two apart: a server-wide out-of-memory event raises an admin alert; a per-account containment event is the limit doing its job.<\/p>\n\n\n\n

The process ceiling is the other: a fork past it simply fails<\/strong>, which is why a fork bomb fizzles instead of taking down the process table. Throttled, contained, slowed, refused: four concrete verbs, no error page in sight.<\/p>\n\n\n\n

Burst mode: enforcement that watches the load<\/strong><\/h2>\n\n\n\n

An optional layer over the sweep, burst mode, answers an obvious objection: why throttle an account to half a core at 4 a.m. when seven cores sit idle?<\/p>\n\n\n\n

With burst mode on, cpm compares server load to core count once per second. While load stays below the core count (real spare capacity), limited accounts run unconfined and use what’s free. The moment load reaches the core count, confinement engages within about a second. <\/p>\n\n\n\n

One honest caveat is a conservative tail: when pressure subsides, processes already confined stay in their groups until they exit, and only new work runs free again. The effect is mild but real. The mechanics live in our burst mode write-up<\/a>. The principle: limits protect, they don’t punish.<\/p>\n\n\n\n

Where this came from<\/strong><\/h2>\n\n\n\n

This is one of SPanel’s clearest Cloud Democracy<\/a> stories. For years, the most common reason providers gave for staying on another panel was per-account resource limiting, historically a separate, paid operating-system layer. The requests asked for exactly this: CPU, RAM, IO, IOPS, and process caps per account, without buying another license. We built them on the kernel’s own control groups: native, with no CloudLinux license needed.<\/p>\n\n\n\n

One scope note: this is resource enforcement, not filesystem virtualization. SPanel does not provide a CageFS-style per-account virtual filesystem. Account isolation comes from standard Linux users and permissions plus SShield and the security stack; resource limits come from cgroups v2.<\/p>\n\n\n\n

Demo flow<\/strong><\/h2>\n\n\n\n

Deterministic Admin Interface steps for the screens in this article.<\/p>\n\n\n\n

    \n
  1. Log in to the SPanel Admin Interface<\/strong> with admin credentials.<\/li>\n\n\n\n
  2. Under Accounts Management<\/strong>, open Packages<\/strong> and click Create a New Package<\/strong> (or Modify<\/strong> an existing package).<\/li>\n\n\n\n
  3. On the Advanced Limits<\/strong> tab, capture the five kernel dials: CPU Limit, Memory Limit, Storage Transfer Rate, IOPS Limit, and Maximum Total Processes.\u00a0<\/li>\n\n\n\n
  4. Switch to the Basic Limits<\/strong> tab and capture the storage and creation-count dials (disk space, inodes, addon domains, email accounts, databases).\u00a0<\/li>\n\n\n\n
  5. From Manage Accounts<\/strong>, open a limited account’s Actions<\/strong> menu and choose Change Limits<\/strong>; in the Change the limits of user<\/strong> editor, open the Advanced Limits<\/strong> tab to read the account’s five current values.<\/li>\n<\/ol>\n\n\n\n
    \"We<\/figure>\n\n\n\n

    Try it on a real server<\/strong><\/h2>\n\n\n\n

    To see the dials and a limited account’s current values on a live server, spin up a ScalaHosting managed VPS; SPanel and every limit here are included free, with no per-account fees or extra OS license. If there’s a feature you\u2019re missing, the Cloud Democracy board<\/a> is the place to suggest it and possibly see it in new SPanel versions. Field-level reference lives in the SPanel documentation<\/a>.<\/p>\n\n\n

    \r\n \"shortcode-logo\"\r\n
    \r\n \"shortcode-bg\"\r\n <\/div>\r\n
    \r\n
    \r\n
    Supercharge Your Business with an All-inclusive Fully Managed Cloud<\/div>\r\n
    \r\n
    \r\n
    Free, Effortless & No-Downtime Migration<\/b><\/div>\r\n
    Anytime Unconditional Money-back Guarantee<\/b><\/div>\r\n
    Full Scalability & 24\/7 Expert Cloud Support<\/b><\/div>\r\n <\/div>\r\n <\/div>\r\n
    \r\n
    \r\n Start Now<\/a>\r\n <\/div>\r\n
    \r\n