Why can an application be limited when my VPS still has spare resources?
The provider’s VPS allocation is not the only possible limit. A systemd service, container or application can impose a lower CPU or memory cap inside the guest. That cap may remain unchanged after a plan upgrade.
Instructions
1. Identify the constrained process or service
Confirm which application is slow or being terminated. A machine-wide average can hide a limit applied to one service or process group.
2. Inspect a named systemd service
Replace the example with the actual approved service name.
systemctl show example-app.service -p ControlGroup -p CPUQuotaPerSecUSec -p MemoryMaxThese properties reveal applicable systemd configuration where supported. They describe guest service policy, not every provider host-side quota.
3. Review the appropriate resource controller
For cgroup v2, inspect the identified group’s cpu.stat, cpu.max, memory.events and memory.max through the system’s approved diagnostic workflow. Container runtimes may manage these settings. Change a limit only after understanding why it exists and whether the workload has enough total capacity.
Check the result
- The actual service or container limit is identified independently of the VPS allocation.
- A reviewed adjustment, if needed, improves the application without exhausting the guest.
Troubleshooting
- The properties show no local limit
- Investigate application-specific settings and provider constraints rather than assuming no limits exist anywhere.
- A container limit differs from systemd
- Inspect the container runtime’s own effective configuration and hierarchy; child limits can be stricter.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.