Skip to main content
To limit a service’s CPU and memory on Linux, run sudo systemctl set-property myapp.service CPUQuota=50% MemoryMax=1G. systemd applies the limit through cgroups immediately and keeps it after reboots. For a one-off command, use sudo systemd-run --scope -p CPUQuota=50% -p MemoryMax=1G command. CPUQuota=50% means half of one core; MemoryMax is a hard cap that triggers the out-of-memory killer inside that unit only.

Before you start

  • Connect with SSH as a user with sudo. Root users can leave out sudo.
  • Decide whether you need a cap (never more than X) or a priority (gets less when others need it). A cap wastes idle CPU; a priority doesn’t. The table below helps.
  • Find the service name with systemctl list-units --type=service, or which service a busy process belongs to with systemctl status <PID>. See find what is using CPU.

Which limit should I use?

How to limit a systemd service

1

Set the limits

The change applies straight away and is saved for future boots. Add --runtime to apply it only until the next reboot.
2

Check the values

Prefer to keep the limits in a file you can read later? Put them in a drop-in instead:
Then sudo systemctl restart myapp.service. The systemd documentation recommends MemoryHigh= as the main control and MemoryMax= as the last line of defence. Sizes use base 1024 (1G = 1 GiB), and you can also give a percentage of RAM, such as MemoryMax=25%.
A MemoryMax= lower than the program really needs makes it crash over and over. Measure normal use first (systemctl status myapp shows Memory:), then set the limit with headroom. Don’t put limits on sshd, systemd-journald or your database without testing; a starved SSH service can lock you out. If that happens on a VPS, use the VNC console.

How to limit a single command with systemd-run

--scope runs the command in your terminal, inside a temporary cgroup with these limits. When the command ends, the scope disappears. Without --scope, systemd-run starts the command as a background service instead.

How to lower priority with nice and renice

Start a command with low CPU priority:
Lower the priority of a running process (PID 30043):
Nice values run from -20 (highest priority) to 19 (lowest). A niced process still uses idle CPU, so this is the gentlest option. For a service, set Nice=10 in a drop-in to make it permanent.

How to throttle a running process with cpulimit

cpulimit stops and resumes a process many times a second to hold it near a percentage of one core. It needs no restart, but it is less precise than cgroups.
-l 30 is 30% of one core and -b runs cpulimit in the background. While throttled, the process shows state T (stopped) part of the time in top; that is how cpulimit works.

How to keep a process on certain cores

The process now runs only on core 0. For a service, use CPUAffinity=0 in a drop-in.

How to check it worked

The limited service should stay at or below its CPUQuota in the CPU column. For memory, systemctl status myapp.service shows the current use and the limits on the Memory: line. If the out-of-memory killer acted inside the unit, journalctl -u myapp.service records it.

Frequently asked questions

What does CPUQuota=100% mean on a 4-core server?

One full core out of four. CPUQuota is relative to one CPU, so the maximum on a 4-core server is 400%.

How do I remove a limit?

Set it back to empty or infinity: sudo systemctl set-property myapp.service CPUQuota= MemoryMax=infinity. If you used a drop-in, delete it with sudo systemctl revert myapp.service (this removes all drop-ins for that unit).

Can I limit a Docker container instead?

Yes, with Docker’s own flags, for example docker run --cpus=1.5 --memory=1g. See essential Docker commands.

Does this work on cgroups v1?

These settings are written for the unified (v2) hierarchy that current Ubuntu, Debian, AlmaLinux and Rocky releases use. Check with stat -fc %T /sys/fs/cgroup; cgroup2fs means v2.

VPS and dedicated server guides

Every server guide in one place.

Find what is using CPU

Find the process to limit.

Check memory usage

Measure before you cap.

Manage services with systemctl

Start, stop and edit services.

Create a systemd service

Run your app as a service.

Fix out of memory errors

When processes get killed.

Checked against the systemd.resource-control(5), systemd-run(1) and systemctl(1) manuals and the cpulimit and taskset manuals on 4 November 2026; nice, renice, taskset and cpulimit tested on Ubuntu 24.04 LTS. systemd limits could not be applied in our test environment. Commands can differ on other distributions or releases.

Need Extra Help?

If you encounter any issues, our support team is ready to assist:

Save on Your Hosting

Ready to upgrade your hosting? Use code KB20 at checkout for 20% off your first order!

Last Updated: November 2026