How do I check whether a service has CPU, memory or task limits below the server total?
A service can be limited even when the overall server has spare CPU or RAM. systemd and container runtimes commonly apply cgroup controls, and parent groups can impose additional restrictions. Inspect effective policy before increasing worker counts or treating a limit-triggered failure as a hardware shortage.
Before you start
- An authorised SSH session on the Linux server.
Instructions
1. Query selected service properties
Use the actual unit and inspect only the properties relevant to the symptom. Current usage and configured ceilings describe different aspects of the workload.
systemctl show example.service -p ControlGroup -p MemoryCurrent -p MemoryMax -p CPUQuotaPerSecUSec -p TasksCurrent -p TasksMaxInfinity or an unset local limit does not rule out restrictions inherited from a parent cgroup, VM allocation or container runtime.
2. Trace the applicable hierarchy
Use the reported control-group path and the runtime’s supported inspection tools. Review parent slice limits and, where cgroup v2 is used, the relevant memory.events and cpu.stat counters without changing them.
Check the result
- The observed failure or throttling is explained against the applicable hierarchy, and any proposed limit change preserves capacity for other services and the operating system.
Troubleshooting
- Host RAM is free but the process reports OOM
- Check the service/container memory ceiling and its events.
- CPU utilisation is low but throughput is capped
- A quota, affinity restriction or single-threaded workload may be constraining effective capacity.
- A property is not recognised
- Consult the installed systemd version and the actual runtime; do not assume every server uses the same control hierarchy.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.