Linux高负载需结合load average与CPU核心数判断，load持续高于核心数表明过载，wa高或id低指向IO瓶颈，再分CPU、IO、内存三路排查并定位具体进程。
Linux高负载不是单看CPU使用率高就下结论，关键得看load average和CPU核心数的关系。比如8核机器，load长期高于8，才说明任务排队严重；若load是12但CPU idle还剩40%，大概率是IO卡住了，而不是算力不够。
一、先看整体：确认是不是真高负载
执行uptime或top，重点读这行：
load average: 9.59, 4.75, 1.92
三个值分别代表1/5/15分钟平均负载。对照CPU核心数判断：
- load < CPU核心数 × 0.7 → 健康
- load > CPU核心数 → 已过载，需排查
- load远大于CPU核心数（如16核机器load=50）→ 严重排队，可能IO阻塞或进程失控
同时观察%Cpu(s)里的wa（IO等待）和id（空闲）。wa持续>20%或id接近0，基本可锁定IO瓶颈。
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
二、分方向排查：CPU高？还是IO高？还是内存压垮了？
根据top中wa、us、sy占比，走不同路径：
-
CPU高 + load高：用
top -Hp [PID]找高耗线程，再printf "%x" [TID]转十六进制，最后jstack [PID] | grep -A 20 "0x..."定位Java热点代码；非Java进程可用perf top -p [PID] -
CPU低 + load高：重点查IO。运行
iostat -xz 1看%util是否持续100%、await是否飙升；再用iotop直接看到底哪个进程在狂刷磁盘 -
内存吃紧连带load高：跑
free -h看available是否告急；vmstat 1里若si/so不为0，说明在疯狂swap；dmesg | grep oom查有没有被OOM killer干掉的进程
三、快速定位“搞事进程”：别只盯着top排序
除了top默认按CPU排序，还有更准的招：
- 查IO大户：
pidstat -d 1（每秒输出各进程读写KB） - 查网络连接数暴增：
ss -s看total established是否异常高，再ss -tulnp | awk '{print $7}' | sort | uniq -c | sort -nr揪出监听端口最多的进程 - 查打开文件过多：
lsof -nPl | awk '{print $2}' | sort | uniq -c | sort -nr | head -10 - 查内核级资源争用：
slabtop看dentry/inode缓存是否暴涨，常因大量小文件操作引起
四、进阶收尾：避免重复踩坑
找到根因后，别只重启了事：
- 如果是Java应用CPU高，用
jstat -gcutil [PID] 1000看GC是否频繁；结合jmap -histo [PID]查对象堆积 - 如果是磁盘IO高，检查调度器：
cat /sys/block/sda/queue/scheduler，SSD建议用none或kyber，HDD可用deadline - 系统级调优可临时生效：
echo 10 > /proc/sys/vm/swappiness降低swap倾向；ulimit -n 65535防文件句柄耗尽 - 长期方案要考虑业务逻辑优化，比如把高频时间戳转字符串改成预计算缓存，避免单次请求做上万次重复转换
基本上就这些。排查讲究顺序：先看load和CPU关系，再分IO/CPU/内存三路并进，最后落到具体进程和代码。不复杂但容易忽略wa和r队列长度这两个关键信号。
