真实故障复盘聚焦问题暴露、定位与根治：cpu单核打满因jvm未设亲和性致伪共享，通过numactl绑定节点+usenuma解决；内存持续增长由pandas未释放dataframe引发oom，改用chunksize+显式回收+调低swappiness+systemd内存限制；磁盘io高延迟因ext4挂载参数与mysql配置不当，优化为noatime,nobarrier及o_direct等。
真实故障复盘不是讲理论，而是看问题怎么冒出来、怎么被揪住、又怎么稳住不复发。下面三个典型场景，都来自生产环境，有日志线索、有操作路径、有踩过的坑。
CPU 单核打满，其余核空闲
某 Web 服务响应延迟突增，top 显示一个 Java 进程 CPU 占用率长期 100%，但只跑在 CPU0 上，其他核心负载不足 10%。
- 先确认 NUMA 拓扑：numactl --hardware 发现是双路 Xeon，两个节点，每个节点 16 核
- 再查进程绑定：taskset -p
返回 0x00000001，说明确实只绑在 CPU0 - 根本原因：JVM 启动时未指定亲和性，内核调度器默认将线程集中到第一个可用 CPU，而该应用大量使用本地缓存（如 Caffeine），导致伪共享+缓存行竞争加剧
- 解决：启动脚本中加入 numactl --cpunodebind=0 --membind=0 java -jar app.jar，限定在 Node0 内部调度；同时 JVM 加 -XX:+UseNUMA
内存持续增长，最终触发 OOM Killer
一个 Python 数据处理服务运行 48 小时后被杀，dmesg | tail -20 明确出现 "Killed process XXX (python) total-vm:XXXXXXkB, anon-rss:XXXXXXkB"，且 free -h 显示可用内存已跌破 200MB。
- 排除内存泄漏：用 py-spy record -p
-o profile.svg 抓取堆栈，发现大量 pandas DataFrame 未释放，且重复 read_csv 未加 chunksize - 检查 swap 策略：cat /proc/sys/vm/swappiness 值为 60，对内存密集型服务偏高，改为 10 减少无谓交换
- 限制资源：用 systemd 启动时配置 MemoryLimit=4G 和 MemoryMax=4.5G，配合 OOMScoreAdj 控制优先级
- 关键补丁：代码中改用 pd.read_csv(..., chunksize=10000) + 显式 del df + gc.collect()
磁盘 I/O 高但业务慢，iostat 却显示 %util 不高
数据库查询 RT 普遍超 2s，iostat -x 1 显示 %util 最高才 45%，avgqu-sz 却常年 >8，r_await 和 w_await 超过 15ms。
- 说明不是吞吐瓶颈，而是响应延迟高——队列深、单次 IO 慢
- 用 iotop -oPa 定位到 mysqld 进程在频繁执行小块随机写（WRITE 类型，BPS ）
- 检查挂载参数：mount | grep data 发现 ext4 分区用了 data=ordered，且未开启 barrier=0 或 noatime
- 优化动作：重新挂载加 noatime,nobarrier（SSD 场景），并调整 MySQL 的 innodb_io_capacity=2000 和 innodb_flush_method=O_DIRECT
