Resource limits

CPU, memory and processes

Each account gets a systemd slice, and the policy becomes CPUQuota, MemoryMax and TasksMax on it. The kernel does the enforcing, so KLYRN's opinion is not required while anything is running.

Measured on a three-core test server, with a 25% quota applied through the panel:

cpu.max = 25000 100000
observed 25.00% of one core over ten seconds; 220 of 222 periods throttled

Memory is a kernel limit, not a suggestion: a process that exceeds it is killed by the OOM killer inside that account's slice, and the rest of the server is unaffected. Hitting the process limit refuses the fork.

Three modes: Unlimited, Recommended (derived from this server's hardware) and Custom.

Every existing account stays unlimited. Upgrading KLYRN never starts constraining sites that were running fine. Lowering a memory limit below what an account is using right now warns that the kernel would kill its processes immediately, and refuses unless you confirm.

What a policy reaches, and what it does not

This is the part to read before relying on it. A limit reaches whatever runs inside the account's slice, and that is not everything.

The usage figures shown next to a policy count every process the account owns, cron included, so the number is never narrower than what the account is actually doing.

What this is, precisely

A script the account runs itself can still write past the limit. A PHP script, a cron job or an SSH session belonging to the account writes through the kernel, not through KLYRN, and KLYRN is not in that path. The next measurement will show that it did. This is not a hard stop for a runaway process, and calling it one would be a lie.

A filesystem quota would be. It needs a separate /home mounted with usrquota, and the quota tooling installed. On a typical VPS with a single root filesystem, turning that on means rewriting the root mount options and quota-checking the whole disk on a live server. KLYRN does not do that to a machine that is already serving traffic.

So the limit is enforced where KLYRN is in the path (which is every way a customer adds data through the panel or the API), and the interface, the CLI and this page all say where it is not.

How usage is measured

klyrn account quota                        # every account
klyrn account quota acme                   # one
klyrn account quota acme --measure         # measure it now
klyrn account quota acme --limit 10G
klyrn account quota acme --limit none      # clear the limit

A background pass measures each account 45 seconds after the server starts and then every fifteen minutes. It sums the size of files and directories, counts a hard link once, and never follows a symlink out of the account. It paces itself so a large tree does not saturate the disk.

On a 3,776-entry tree it returned 134,339,314 bytes, against du -sb at 132,561,650 and du -s at 143,011,840. A 10 G limit here is 10 G of file and directory sizes: a little stricter than du -sb, a little looser than what the disk actually gives up.

An on-demand measurement is limited to once every 30 seconds per account, and the message says how long ago the last one ran.

The six states

What is refused, and what is not

Past the limit, KLYRN refuses uploads, extractions, copies, new archives, restores and new sites. The message carries the limit, the current usage and the age of the measurement, so the number is never presented as more certain than it is.

Still allowed, deliberately: delete, rename, chmod, write and mkdir. Deleting is the way back under the limit, and an account that cannot edit wp-config.php to fix its own site because it is 2 MB over its limit is a support ticket, not enforcement.

Two cases allow the operation anyway: no limit set, and a limit with no successful measurement behind it. Refusing on a number nobody has taken would be an invented answer.

A refusal schedules a fresh measurement, so "delete some files and try again" works within about a minute rather than at the next quarter hour.

Who may set a limit

A customer cannot set their own disk limit: the message is "only your host can change a disk limit". An administrator can set any. A reseller can set a limit on an account they own, but not on an account they own themselves, because a reseller who can raise their own ceiling does not have one.

Setting a limit on an account that has never been measured triggers an immediate measurement, so the state is real rather than unmeasured for the next quarter hour. The maximum limit is 1 PiB.

CPU and memory

Per-account CPU, memory and process limits are enforced by the kernel, and they reach some workloads and not others. An account gets a systemd slice carrying CPUQuota, MemoryMax and TasksMax. Node.js application units are placed in it, and so is the account's own PHP-FPM master, so the kernel enforces the limits on both. Cron jobs are not: cron keeps its jobs in its own cgroup, so a per-account limit cannot reach them. The panel lists what is covered and what is not, per account, rather than implying the limit is total. See Resource limits.

The server-wide picture is in klyrn health: CPU load warns above twice the core count and fails above four times; memory warns under 10% available and fails under 5%.