Linux 性能与
资源故障

# top 看 %Cpu(s) 那一行,这几个字段含义不同,根因完全不同
top
# 或更精确
mpstat -P ALL 1

# 1. 找进程
top          # 按 P 按 CPU 排序
ps aux --sort=-%cpu | head

# 2. 找到具体哪个线程(Java/多线程应用必看)
top -Hp <pid>          # 按 P 排序,看 PID 列(其实是 TID)

# 3. Java 应用:把 TID 转 16 进制,在 jstack 里搜
printf "%x\n" <tid>      # 比如得到 1a2b
jstack <pid> | grep -A 20 "nid=0x1a2b"
# 直接看到死循环或热点代码栈

# 4. 通用方法:perf 抓函数热点
perf top -p <pid>

# 上下文切换次数(看 cs 列)
vmstat 1
# cs > 几万/s 通常是问题,看是不是线程太多了

# 按进程看上下文切换
pidstat -w 1
# cswch/s 自愿切换(锁等待) nvcswch/s 被动切换(CPU 抢占)

# 系统调用追踪
strace -c -p <pid>      # 几秒后 Ctrl+C,看哪个系统调用占比高

# wa 高了直接跳去看磁盘 IO,见 Case 08
iostat -x 1
iotop           # 看哪个进程在猛读写

# 看中断分布
cat /proc/softirqs    # 大流量服务器看 NET_RX 是否暴涨
cat /proc/interrupts

# 网络中断集中在 CPU0,负载不均
cat /proc/irq/<irq-num>/smp_affinity
# 改 affinity 把中断分散到多核(RPS/RSS)

# 1. 找出所有 D 状态进程
ps -eo state,pid,user,cmd | grep "^D"
# 或更直观
ps aux | awk '$8 ~ /^D/ {print}'

# 2. 实时看 D 状态进程数
vmstat 1
# 关注 procs 段的 b 列(blocked on I/O)

# 3. 看具体卡在哪个系统调用
cat /proc/<pid>/stack       # 内核栈,看堵在哪
cat /proc/<pid>/wchan       # 进程在等什么

# 4. 检查所有 mount 点是否健康
df -h
# 卡住的 NFS 挂载点会让 df 也 hang 住!

# 5. 测试每个挂载点能不能访问
timeout 3 ls /mnt/nfs1 && echo OK || echo HANG

free -h

              total        used        free      shared  buff/cache   available
Mem:           15Gi        12Gi       300Mi        50Mi       2.7Gi       2.5Gi
Swap:         2.0Gi       500Mi       1.5Gi

# 按 RSS(实际物理内存)排序找进程
ps aux --sort=-rss | head

# top 里按 M 排序也行
top           # 按 M

# 单个进程详细内存使用
pmap -x <pid> | tail -1

所有进程 RSS 加起来远小于 used 内存——这种情况看 内核内存:

# slab 内核对象缓存(dentry/inode 等)
cat /proc/meminfo | grep -E "Slab|SReclaim"

# slab 详细分类
slabtop      # 看哪个 slab 占用大

# 大量小文件操作会让 dentry cache 暴涨,手动清
echo 2 > /proc/sys/vm/drop_caches  # 清 dentry 和 inode cache
echo 3 > /proc/sys/vm/drop_caches  # 清所有 cache

# 1. 看 OOM 历史
dmesg -T | grep -i "killed process"
grep -i "oom" /var/log/messages

# 2. 详细的 OOM 现场(很重要,有内存快照)
dmesg -T | grep -B 2 -A 20 "oom-killer"
# 输出会列出当时所有进程的内存占用,排序后的 oom_score

内核根据 oom_score 选受害者,分数越高越先被杀。计算因素:

• 进程占用内存大小(主要因素)
• oom_score_adj(可手动调整,-1000 到 1000)
• root 进程会有一些豁免

# 查看进程的 oom_score
cat /proc/<pid>/oom_score
cat /proc/<pid>/oom_score_adj

# 保护重要进程不被 OOM(设为 -1000 永不杀)
echo -1000 > /proc/<pid>/oom_score_adj

# 反过来,让某进程优先被杀
echo 1000 > /proc/<pid>/oom_score_adj

# 1. 加内存(最直接)

# 2. 关闭过度内存提交
sysctl vm.overcommit_memory=2
# 0=启发式(默认), 1=允许超量, 2=严格控制

# 3. JVM 应用必须限制堆大小
# -Xmx 不要超过物理内存的 70%,留出空间给堆外

# 4. 找出内存泄漏(应用层问题)
pmap -x <pid>
# 观察一段时间 RSS 是否持续增长

# 1. 看 swap 总体使用
free -h
swapon -s

# 2. 看哪些进程用了 swap
for file in /proc/*/status; do
  awk '/VmSwap|Name/{printf $2 " " $3}END{print ""}' $file
done | sort -k 2 -n -r | head

# 3. 实时监控 swap in/out
vmstat 1
# 看 si(swap in)和 so(swap out)列,持续不为 0 就是 thrashing

# 当前值(默认 60,值越高越倾向于使用 swap)
cat /proc/sys/vm/swappiness

# 数据库/Redis 等内存敏感服务,建议调到 1-10
sysctl -w vm.swappiness=10

# 永久生效,写入 /etc/sysctl.conf
echo "vm.swappiness = 10" >> /etc/sysctl.conf

# 临时禁用 swap(谨慎,可能触发 OOM)
swapoff -a
swapon -a    # 重新启用

# 1. 确认是不是这个问题
df -h          # 看分区使用
du -sh /*       # 加起来对比,差距大就是删除未关闭

# 2. 找出"已删除但被占用"的文件(关键命令!)
lsof | grep "deleted"
# 或更精确
lsof +L1      # 列出链接数为 0 的文件(已删除但被打开)

# 3. 输出示例
# java  12345 root  3w  REG  8,1  10737418240 /var/log/app.log (deleted)
#                                  ↑ 10GB 占着空间

# 方案 A:重启占用文件的进程(最干净)
systemctl restart <service>

# 方案 B:不能重启服务,用 /proc 清空文件内容
# 比如 lsof 显示 java 12345 持有 fd 3
: > /proc/12345/fd/3
# 文件被截断为 0,空间立即释放
# 但应用还在写,新写入会从 0 开始

# 方案 C:重启大法(最后手段)
reboot

# 1. 看 inode 使用
df -i
# 看 IUse% 列,接近 100% 就是这个问题

# 2. 找哪个目录小文件最多
for i in /*; do echo -n "$i: "; find $i 2>/dev/null | wc -l; done | sort -t: -k2 -n

# 或者一层一层往下找
find /var -xdev -type f | cut -d/ -f 1-4 | sort | uniq -c | sort -rn

# 1. 直接删除小文件大户(找到后)
find /var/spool/postfix -type f -delete

# 2. 文件太多,rm * 会爆 argument list too long
find /path/to/dir -type f -delete
# 或
ls | xargs -n 100 rm

# 看磁盘性能(关键命令)
iostat -x 1
# -x 显示扩展信息,1 = 每秒刷新

iotop            # 类似 top,但看 IO
iotop -o         # 只显示有 IO 的进程

# 或者 pidstat
pidstat -d 1
# kB_rd/s 读速率, kB_wr/s 写速率

uptime

10:23:01 up 30 days,  3:21,  2 users,  load average: 2.05, 4.50, 8.10

• 第一个:过去 1 分钟平均负载
• 第二个:过去 5 分钟平均负载
• 第三个:过去 15 分钟平均负载

load 的合理上限 ≈ CPU 核数。8 核机器 load 持续 > 8 才算饱和。

nproc                  # 看核数
cat /proc/cpuinfo | grep processor | wc -l