Production server becomes slow — how do you identify CPU/memory/disk/network issues?

When a production server becomes slow, I apply Brendan Gregg's USE Method (Utilization, Saturation, Errors) using a systematic 60-second command checklist to isolate which subsystem is bottlenecking. Key Takeaway: Use the USE Method. Run 'uptime' -> 'vmstat 1 5' -> 'free -h' -> 'iostat -xz 1 5'. High 'wa' in vmstat means Disk I/O bottleneck; high 'si/so' means memory swapping; high 'r' means CPU saturation.

Disk reaches 100% — how would you find and safely remove the cause?

When a disk hits 100%, services begin dropping connections, crash, and cannot write logs or create PID files. The investigation requires checking both disk blocks and inodes, and avoiding the classic 'deleted file still held open' trap. Key Takeaway: Check 'df -i' for inode exhaustion. Use 'lsof +L1' to find deleted files held open by running processes, and truncate them via /proc//fd/ rather than rebooting.

Process is consuming high CPU — which commands would you use?

When a process consumes high CPU, my goal is to drill down from the system process level down to the exact thread, system call, or application function causing the burn. Key Takeaway: Use 'top -c' to find PID, 'top -H -p ' to find the specific thread, and 'strace -c' or 'perf top' to pinpoint the looping function or lock contention.

Service is running but not listening on the expected port — how would you troubleshoot?

When systemctl reports 'active (running)' but you cannot connect to the expected port, I trace through 5 discrete checkpoints: daemon listening sockets, IP binding address, privileged port permissions, firewall rules, and security modules. Key Takeaway: Check 'ss -tulpn | grep ' first. If listening on 127.0.0.1, change binding to 0.0.0.0. If port < 1024, check CAP_NET_BIND_SERVICE. If bound correctly, check iptables and SELinux port policies.

A production deployment causes a sudden 40% increase in error rates. Walk through your incident-response process from detection and diagnosis to rollback, mitigation, root-cause analysis, and post-incident prevention.

A 40% error rate spike is a SEV-1 outage. My golden rule as an Incident Commander is: 'Mitigate first to protect customers; debug second.' Never spend hours debugging a broken deployment in production when an immediate rollback restores service. Key Takeaway: Mitigate first, debug second. Stop customer bleeding via immediate rollback or feature flag disablement within 5 minutes. Formally separate Incident Commander, Ops Lead, and Comms Lead, followed by a blameless post-mortem.

89+ Production Linux & SRE Interview Questions & Scenarios (2026 Edition)

Q: A production deployment causes a sudden 40% increase in error rates. Walk through your incident-response process from detection and diagnosis to rollback, mitigation, root-cause analysis, and post-incident prevention.

A 40% error rate spike is a SEV-1 outage. My golden rule as an Incident Commander is: 'Mitigate first to protect customers; debug second.' Never spend hours debugging a broken deployment in production when an immediate rollback restores service. Key Takeaway: Mitigate first, debug second. Stop customer bleeding via immediate rollback or feature flag disablement within 5 minutes. Formally separate Incident Commander, Ops Lead, and Comms Lead, followed by a blameless post-mortem.

Senior DevOps / SRE Performance & SRE

⚡ Scenario linux-server-slow-bottleneck-triage

Production Server Becomes Slow — Identifying CPU, Memory, Disk, or Network

Mastering the USE Method (Utilization, Saturation, Errors) to isolate system bottlenecks across CPU, Memory, Disk I/O, and Network in under 60 seconds....

#Linux #USE Method #vmstat

All Linux & SRE Scenario Questions (89)