# How can I limit the CPU an application uses?
Source: https://vpsdime.com/knowledgebase/technical-questions/limit-cpu-usage
Last reviewed: 2026-07-02
Summary: Four ways to keep one process from eating every core, nice/renice for priority (the polite fix), systemd CPUQuota for hard per-service caps (the right one), cpulimit for one-off processes, and Docker's --cpus, with when each applies and why priority beats caps for batch work.

## What this is

One process, a backup compressing, a video encode, an [overeager script](https://vpsdime.com/knowledgebase/troubleshooting/slow-vps), pins the CPU and everything else suffers. Two different goals hide in "limit its CPU", and they want different tools:

- **"It can use idle CPU, just never at others' expense"** → priority (`nice`). Usually what you actually want: the job still finishes as fast as conditions allow.
- **"It must never exceed X% no matter what"** → a hard cap (`CPUQuota`, `cpulimit`, `--cpus`). Right for untrusted or misbehaving things; understand it leaves CPU idle on purpose.

## Priority: nice and renice (the polite fix)

```
nice -n 19 tar czf backup.tar.gz /var/www     # start at lowest priority
renice 19 -p 12345                            # demote an already-running PID
```

A nice-19 process uses **all** the idle CPU but yields instantly when anything else wants a turn, the batch job barely slows down, and the site stops noticing it. For disk-heavy jobs, the I/O sibling: `ionice -c3 <command>`. This should be the default posture of every scheduled heavy job you own.

## Hard caps: systemd CPUQuota (the right tool for services)

For anything running as a service (or a [timer job](https://vpsdime.com/knowledgebase/technical-questions/systemd-timers)), cgroup-backed limits are precise and permanent, in the unit's `[Service]` section:

```ini
CPUQuota=50%
```

(50% of one core; `200%` means two cores.) One-liner for an existing service, no file editing:

```
systemctl set-property myapp.service CPUQuota=50%
```

`MemoryMax=` lives in the same family, [it's the same mechanism the timers guide recommends for heavy backup jobs](https://vpsdime.com/knowledgebase/technical-questions/systemd-timers).

## cpulimit: a cap for a one-off process

For a process that isn't a service and needs restraining *now*:

```
apt install cpulimit
cpulimit -p 12345 -l 50       # hold PID 12345 at ~50% of one core
```

It works by rapidly pausing/resuming the process, crude but effective, and nothing to clean up afterwards.

## Docker: --cpus

Containers get the cgroup treatment natively: `docker run --cpus="1.5" ...`, or in compose, `deploy.resources.limits.cpus: "1.5"`, [the same knob the container-sprawl section recommends](https://vpsdime.com/knowledgebase/troubleshooting/slow-vps) so one stack can't starve the VPS.

## The honest footnote

A cap protects neighbors *inside* your VPS; it doesn't create CPU. If the workload legitimately needs more than the plan has, caps just make it slower, [extra vCPU or a bigger plan](https://vpsdime.com/knowledgebase/client-area/services/extra-features) is the real fix, and if the CPU is being eaten by something you don't recognize, that's [a different article entirely](https://vpsdime.com/knowledgebase/troubleshooting/compromised-vps-recovery).

## Still need help?

You can [open a support ticket](https://vpsdime.com/open-ticket/). So we can help on the first reply, it's worth mentioning:

- the VPS hostname or IP,
- the process you're capping, and whether you want priority (nice) or a hard cap.

## Related questions

- "How do I stop a backup job from slowing my website?"
- "How do I cap a service at 50% CPU?"
- "What's the difference between nice and CPUQuota?"
- "How do I limit CPU for a Docker container?"