Resource limits
CPU, memory and processes are limited by the kernel. Disk is measured and refused at KLYRN’s own boundaries. This page says what each limit reaches.
CPU, memory and processes
Each account gets a systemd slice, and the policy becomes CPUQuota,
MemoryMax and TasksMax on it. The kernel enforces them.
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, with 220 of 222 periods throttled
A process that exceeds the memory limit 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 warns that the kernel would kill its processes immediately, and refuses unless you confirm.
What a policy reaches, and what it does not
A limit reaches whatever runs inside the account's slice. Some workloads run outside it.
| Workload | Limited | Why |
|---|---|---|
| Node.js applications | Yes | Each is its own unit, placed in the account's slice. |
| PHP-FPM pools | Yes | Each account runs its own PHP-FPM master, klyrn-php<version>@<account>.service, inside the account's slice, so its workers are in the account's cgroup. Measured: a script allowed to allocate freely was killed at about 389 MB under MemoryMax=384M. Until 0.3.0-beta.4 every account's workers shared one php-fpm service and were bounded only by pm.max_children and memory_limit. |
| Cron jobs | No | They run under cron.service, in cron's own cgroup. |
| Disk I/O | Not offered | The io controller is not delegated on Ubuntu 24.04's default configuration, so a control would do nothing. I/O is counted per account from the slice and shown beside CPU and memory. It is not limited. |
The usage figures shown next to a policy count every process the account owns, cron included.
What the disk limit is
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, and KLYRN is not in that path. The next measurement shows that it did. The disk limit is not a hard stop for a runaway process.
A filesystem quota would be a hard stop. It needs a separate /home mounted
with usrquota, and the quota tooling installed. On a typical VPS with a
single root filesystem, that means rewriting the root mount options. It also means
quota-checking the whole disk on a live server. KLYRN does not do that to a machine
that is already serving traffic.
The limit is enforced where KLYRN is in the path: every way a customer adds data through the panel or the API.
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 limitA 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 is 10 G of
file and directory sizes. That is a little stricter than du -sb and a
little looser than what the disk 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
| State | Meaning |
|---|---|
none | No limit is set on this account. |
unmeasured | A limit is set but nothing has been measured yet. |
error | The last measurement failed. Reported as error even when the stale number would look fine. |
ok | Under 90% of the limit. |
warn | At or over 90%. Shown on the account and in the health view. |
over | Past the limit. |
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.
Still allowed: delete, rename, chmod, write and mkdir. Deleting is the
way back under the limit. An account 2 MB over can still edit
wp-config.php to fix its own site.
Two cases allow the operation anyway: no limit set, and a limit with no successful measurement behind it.
A refusal schedules a fresh measurement, so "delete some files and try again" works within about a minute.
Where the disk goes
Storage shows administrators and resellers where the disk goes, by account, site and kind, with the largest folders and files. A reseller sees only their own customers.
Each cleanup lists exactly what it will remove before anything is removed. An optional AI explanation uses a provider the administrator configures.
Bandwidth and visitors
Bandwidth is counted per site and per account, and a package can set a monthly limit. Visitor statistics come from the server's own logs, with no third-party tracker.
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, and not on an account they own themselves.
Setting a limit on an account that has never been measured triggers an immediate measurement. 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. Node.js application units and the account's own PHP-FPM master are placed in the account's slice. 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.
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%.