Skip to content

Drill: Inspect Cgroup Resource Limits and Usage

Goal

Inspect cgroup resource limits and current usage for a systemd service to understand resource constraints.

Setup

  • Linux system with cgroups v2 (most modern distros) or v1
  • Root access or membership in appropriate groups
  • A running service to inspect

Commands

Check which cgroup version is in use:

stat -fc %T /sys/fs/cgroup/

Find the cgroup for a service:

systemctl show nginx.service -p ControlGroup

View CPU usage:

cat /sys/fs/cgroup/system.slice/nginx.service/cpu.stat

View memory current usage and limits:

cat /sys/fs/cgroup/system.slice/nginx.service/memory.current
cat /sys/fs/cgroup/system.slice/nginx.service/memory.max
cat /sys/fs/cgroup/system.slice/nginx.service/memory.stat

Check IO stats:

cat /sys/fs/cgroup/system.slice/nginx.service/io.stat

Use systemd-cgtop for a live view:

systemd-cgtop -d 2 -n 3

View resource limits set via systemd:

systemctl show nginx.service -p MemoryMax -p CPUQuota -p TasksMax

Set a memory limit via drop-in:

systemctl set-property nginx.service MemoryMax=512M

What to Look For

  • memory.current vs memory.max shows how close a service is to its limit
  • cpu.stat shows usage_usec for total CPU time and nr_throttled for throttling events
  • memory.stat breaks down memory into anon, file cache, slab, etc.
  • systemd-cgtop gives a top-like view organized by cgroup hierarchy

Common Mistakes

  • Looking in cgroups v1 paths when the system uses v2 (or vice versa)
  • Confusing the slice hierarchy path (system.slice vs user.slice)
  • Not understanding that memory.max of max means unlimited
  • Forgetting that set-property creates a persistent drop-in override

Cleanup

# Remove property override if you set one
systemctl revert nginx.service
systemctl daemon-reload