线上服务器 CPU 或内存飙高，怎么用 Linux 命令排查？

详细解析#

先看整体：load average 和 top#

uptime 和 top 第一行的 load average 是最近 1、5、15 分钟的平均负载。Linux 上它统计的是正在运行或等待运行的任务加上处于不可中断睡眠（D 状态，通常在等磁盘 I/O）的任务，所以：

• 和 CPU 核数（nproc）比较：长期明显超过核数，说明任务在排队
• load 高但 CPU 使用率不高，多半是大量任务卡在 I/O 上，去看磁盘和 NFS 等存储
• 三个值对比能看趋势：1 分钟远大于 15 分钟，说明负载在上升

top 的 CPU 行要拆开看：

CPU 飙高#

1. top 后按 P 按 CPU 排序，找到进程 PID；多核机器上按 1 看每个核，确认是单核打满还是整体打满
2. top -H -p <pid> 看这个进程里哪个线程最忙，记下线程 ID
3. 按语言定位代码：
   • Java：用 jstack <pid> 按线程 ID 找到这个线程的堆栈。JDK 18 起 nid 直接是十进制；JDK 17 及以前要先 printf '%x\n' <tid> 转成十六进制，再搜 nid=0x...。GC 线程忙就转去看 GC 日志
   • Go：线程和 goroutine 不是一一对应的，直接用 pprof 采样：go tool pprof http://<host>:<port>/debug/pprof/profile?seconds=30（服务要引入 net/http/pprof）
   • Node.js：主线程打满时用 --cpu-prof 或 inspector 采集 CPU profile，见 Node.js 服务 CPU 飙高怎么排查
   • 通用：perf top -p <pid> 看热点函数，对 C/C++ 和内核态问题尤其有用

内存飙高#

free -h 的输出：

• buff/cache 是内核用来缓存文件的内存，需要时可以回收，大不代表内存紧张
• available 是估算的、不用 swap 就能分给新程序的内存，判断内存够不够主要看它
• free 小很正常，Linux 会尽量把空闲内存用作缓存

接着找进程和原因：

1. ps aux --sort=-rss | head 按实际占用的物理内存排序
2. 看是否在持续增长：隔一段时间看 /proc/<pid>/status 里的 VmRSS，持续上涨不回落就怀疑泄漏
3. 被杀过没有：dmesg -T | grep -iE 'out of memory|killed process'，或 journalctl -k | grep -i oom
4. 进入语言层面：Java 用 jmap 导出堆、看 GC 日志；Go 用 /debug/pprof/heap；Node.js 对比堆快照，见 Node.js 内存泄漏

按场景的命令清单#

iostat、pidstat 属于 sysstat 包，iotop、htop 可能也需要单独安装，平时就应该在基础镜像里准备好。

代码示例#

Java 进程 CPU 高时的完整流程：

top -H -p 1234                 # 找到最忙的线程，假设 TID 是 1250
jstack 1234 | grep -A 30 'nid=1250 '   # JDK 18 起 nid 是十进制
printf '%x\n' 1250                      # JDK 17 及以前先转十六进制，输出 4e2
jstack 1234 | grep -A 30 'nid=0x4e2'

# 连续抓几次堆栈，间隔几秒对比，持续出现在同一位置的才是热点
for i in 1 2 3; do jstack 1234 > /tmp/jstack.$i.txt; sleep 5; done

面试官可能追问#

易错点#

• 看到 free 很小就以为内存不够，应该看 available
• load average 高不等于 CPU 忙，Linux 的 load 包含了等待磁盘 I/O 的 D 状态任务
• top -H 里显示的是十进制线程 ID；JDK 17 及以前 jstack 里的 nid 是十六进制，要先转换，JDK 18 起 nid 直接打印成十进制，不用再转
• 只排查到进程就停下，没有落到具体的代码或请求，问题还会复发；处理时先保留现场（堆栈、profile、日志），再重启恢复