An application running on Linux used to process 1000 requests/second. Now it only processes ~2 requests/second.
How would you troubleshoot this issue?
答题套路：先框架→快查→深挖→修复→验证。
1) 先确认：只这台机还是全集群？从啥时候开始？有没有发布 / 配置 / 依赖变更？看四大指标：吞吐、延迟、错误率、饱和度。
2) 快速体检（5 分钟命令）：
- 资源：
top/htop、vmstat 1、iostat -xz 1、pidstat -udr 1、df -h -i、sar。 - 网络：
ss -s、netstat -s、丢包 / 重传、DNS（dig）。 - 限制：
ulimit -n、somaxconn、backlog、ip_local_port_range、nf_conntrack、cgroup 限额、dmesg（OOM/ 节流）。 - 进程：线程 / 协程数、队列长度、GC 指标、日志是否打爆 IO。
3) 判断归因：
- CPU 忙 →
perf/pprof抓火焰图，找热点 / 锁； - IO 等待高 → 小写放大、fsync、日志 / 磁盘满 / inode 耗尽；
- 网络问题 → 重传 / 半双工 /MTU/DNS/TLS；
- 依赖变慢 → 数据库慢查询、连接池耗尽、缓存雪崩、消息队列积压。
4) 常见一锤子修复：回滚最近变更；增大 fd/ 端口范围 /backlog；调线程 / 连接池；修 DNS；清理磁盘或限日志；热身缓存；恢复正确 cgroup 配额。
5) 收尾：验证恢复曲线；补监控报警与 Runbook，保留性能画像以防再发。
面试要点：别背命令清单；要有 分层定位的思路 、 每步要验证什么 、 为什么这步能排除 / 确认某个瓶颈。
VOprep 团队长期陪同学员实战各类大厂 OA 与 VO，包括 Tesla、Google、Amazon、Citadel、SIG 等，提供实时答案助攻、远程陪练与面试节奏提醒，帮助大家在关键时刻不卡壳。
如果你也在准备公司，可以了解一下我们的定制助攻方案——从编程面到系统设计，全程护航上岸。
正文完
