Linux and RHEL · Troubleshooting guide

Linux Troubleshooting: High Load with Idle CPU, and SSH Logins That Crawl

How to read load average correctly, find D-state processes, and fix the two most common causes of slow SSH logins.

Published August 28, 2026 · RCW IT Training

Performance triage

Load average is high but CPU looks idle

Load counts runnable plus uninterruptible (D-state) tasks, so I/O waits inflate it. Check %wa in top, per-disk await and %util with iostat -xz 1, and list stuck processes with ps aux | awk '$8 ~ /D/'. Follow the busiest device with iotop -oP. Common culprits: fsync-heavy databases, backup scans, and swapping - confirm with vmstat 1 (si/so columns) and free -h.

System slowly unusable and kswapd eats CPU

That is memory pressure, not CPU shortage. Rank consumers with systemd-cgtop or per-process RSS, look for leaks, and confirm swap is on fast media. Tuning vm.swappiness is a mitigation; the real fix is right-sizing RAM or capping the workload with cgroups memory limits.

SSH login delays

10-30 second pause before the password prompt

Usually reverse-DNS or GSSAPI lookups timing out. Set UseDNS no and GSSAPIAuthentication no in /etc/ssh/sshd_config, restart sshd, and fix /etc/resolv.conf so the server can actually reach its DNS servers. Verify with sshd -T | grep -Ei 'usedns|gssapi' and time a login with ssh -v.

Pause after the password, or the session hangs at login

PAM or profile stalls: check journalctl -u sshd -b and /var/log/secure for PAM timeouts, broken motd scripts in /etc/profile.d, or a slow NFS home directory. A hung systemd-logind shows as a long 'Starting User Manager' - inspect systemctl status systemd-logind and journalctl -b -p err.

Key takeaway: High load with idle CPU is an I/O story - follow await, %util and D-state processes. Slow SSH is almost always DNS/GSSAPI or a PAM/profile stall.