Diagnosing whether systemd LimitNOFILE or TasksMax caps cause connection pool exhaustion on Rocky Linux 8/9
0 reputation · 24 Nov 2024, 09:27 UTC
Goal
Determine whether per-service systemd resource ceilings — LimitNOFILE (file descriptors) or TasksMax (threads/processes) — are the first bottleneck hit when a connection pool exhausts on Rocky Linux 8 or 9.
Constraints and uncertainty
Rocky 9 defaults to cgroup v2 while Rocky 8 uses hybrid or v1 unless configured, changing how limits are enforced and observed. Default LimitNOFILE (1024 soft) and TasksMax (derived from kernel.pid_max) differ between releases and systemd versions. Raising either limit without checking kernel-wide fs.file-max and kernel.pid_max may shift the bottleneck rather than remove it. The OS cannot indicate whether the correct fix is raising the systemd ceiling or reducing the application pool size; that decision requires application-level pool metrics.
Questions
- Which diagnostic commands reliably show live per-unit fd and task consumption on both cgroup v1 and v2 modes?
- How should an operator decide between increasing LimitNOFILE/TasksMax via drop-in overrides versus tuning the application pool downward?
- What kernel-level limits must be verified before raising systemd per-service ceilings?
rockylinux