Linux 性能实战面试手册
1. 面试官真正想听什么
一个优秀回答包含：
- 原理正确；
- 排查有顺序；
- 工具选择有理由；
- 能说出决定性证据；
- 了解风险和权衡；
- 有修复后验证；
- 能沉淀监控和流程。
2. 高频综合题
Q1：线上接口突然变慢，你怎么排查？
结构化回答：
- 确认影响范围、错误率、p99、时间线和变更；
- 分解 DNS、建连、TLS、TTFB、响应传输；
- 用 RED 看服务，用 USE 看 CPU、内存、I/O、网络；
- 对比正常实例、宿主机与容器；
- 对异常资源定向到进程、线程、系统调用或调用栈；
- 止损、单变量修复、同负载验证；
- 补充告警、容量和自动取证。
Q2：CPU 使用率不高，为什么容器仍然很慢？
可能原因：
- cgroup quota 导致 throttle；
- 单核热点被整机平均值稀释；
- 进程在锁、I/O 或调度队列等待；
- PSI 高；
- steal time；
- 应用线程池/连接池排队。
用 cpu.stat、每核 mpstat、pidstat -t、PSI 和应用队列证明。
Q3：容器 Exit Code 137 是什么？
137 通常表示进程收到 SIGKILL，但不能直接等同于 OOM。需要检查：
- 容器状态中的
OOMKilled； - cgroup
memory.events； - kubelet 与内核日志；
- 是否人为
kill -9、强制终止或节点驱逐。
Q4：为什么 JVM 堆不能配置成容器内存上限？
容器内还有：
- metaspace；
- 线程栈；
- direct buffer；
- code cache/JIT；
- GC/native 数据结构；
- mmap、共享库和页缓存计费。
应以压测峰值和 native memory 数据确定余量。
Q5：如何排查偶发丢包？
从应用到设备逐层：
text
应用错误/超时
→ socket/TCP/UDP 计数
→ qdisc/softnet
→ 网卡/驱动
→ 防火墙/conntrack
→ MTU/路由
→ 物理和上游设备使用计数差值、双端抓包和正常节点对照定位首次消失点。
Q6：TIME_WAIT 很多怎么处理？
先解释它是主动关闭方为防止旧报文污染新连接而保留的正常状态。再检查：
- 短连接与连接池；
- 谁主动关闭；
- 临时端口和 NAT；
- 是否真的存在连接失败；
- Keep-Alive/HTTP2。
不推荐旧的 tcp_tw_recycle。
Q7：吞吐下降怎么分析？
先确认“有效吞吐”和错误率，然后依次检查：
- 带宽还是 PPS；
- 连接与 conntrack；
- listen/accept 队列；
- worker/线程池/连接池；
- 临时端口；
- CPU、softirq、锁和热点函数；
- 下游容量。
每解除一个限制都重新观测，因为瓶颈会移动。
Q8：perf、strace 和 eBPF 怎么选？
- perf：采样热点和调用栈；
- strace：系统调用类型、返回值和耗时；
- eBPF：需要跨内核事件定向关联和聚合；
- 语言 profiler：JVM/Go/Python 运行时及业务符号。
先用低成本工具缩小范围，再使用更精细工具。
Q9：火焰图怎么看？
- 横向宽度是采样占比；
- 纵向是调用栈；
- 从下向上沿宽路径找热点；
- 不是时间线；
- 宽函数不一定是可优化根因；
- 需要符号完整并与业务负载对应。
Q10：性能调优如何避免负优化？
- 修改前明确假设和证据；
- 保存旧值；
- 单变量；
- 相同负载对照；
- 同时看成功率、p99 和资源；
- 长时间验证；
- 灰度与回滚；
- 检查瓶颈是否转移。
3. 实战案例表达示例
容器启动慢
text
背景：Java 服务容器化后启动从 2 秒变 22 秒，并偶发退出。
影响：发布扩容速度慢，readiness 失败。
排查：inspect 发现 OOMKilled，内核确认 cgroup OOM；
修正 JVM 内存后仍慢，pidstat 发现线程 %wait 高，
cpu.stat 证明 quota throttle。
修复：为堆外内存预留空间，按启动与稳态分别设计 CPU 资源，
优化启动探针。
验证：相同镜像和数据下，启动恢复约 2 秒，OOM/节流消失。
沉淀：增加 memory.events、throttle 和启动阶段指标。服务吞吐下降
text
背景：压测 RPS 极低且大量非 2xx。
排查：先发现 conntrack 满；扩大后 RPS 上升但错误仍高。
继续发现 worker、backlog、临时端口限制，
最后用火焰图确认 CPU 热点。
关键认识：不能把总 RPS 当成功吞吐，且每解开一层限制都会移动瓶颈。4. 反问与加分点
可以主动询问：
- 业务的 SLO 与峰值负载是什么？
- 问题发生在容器还是裸机？
- 是否有正常实例可对照？
- 最近是否发布、扩容或修改网络/存储？
- 允许哪些线上追踪工具与开销？
- 期望先止损还是直接定位根因？
这能体现你会在真实约束下工作，而不是背命令。