系统负载高需区分CPU忙、I/O卡顿或进程排队三类原因；先用uptime和nproc对比负载值与核心数，再通过top、vmstat、iostat等定位瓶颈类型及具体进程。
系统负载高不等于CPU跑满，得先分清是CPU真忙、I/O卡住、还是进程排队堵着——三类情况对应不同命令和处理逻辑。
看懂负载值和CPU核心数的关系
运行 uptime 或 cat /proc/loadavg，得到三个数字（1/5/15分钟平均负载），再用 nproc 或 grep -c 'processor' /proc/cpuinfo 查出CPU核心数。如果负载值持续高于核心数，说明系统确实承压；若只是1分钟值略高，可能是瞬时抖动，不用急着干预。
区分CPU高还是I/O高导致的负载升高
CPU使用率高 + 负载高：典型如死循环、加密计算、未优化脚本。用 top 或 htop 按 P 排序，找 %CPU 最高的进程；再用 ps -T -p [PID] -o pid,tid,%cpu,time,cmd 看线程级占用，确认是不是单线程打满。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
CPU使用率低 + 负载高：大概率是I/O等待拖累。重点看 vmstat 1 输出里的 wa（I/O wait）是否长期 >10%，同时 r（运行队列长度）明显大于核心数；再用 iostat -x 1 查 %util 是否接近100%，iotop 找具体吃I/O的进程。
快速定位瓶颈进程与资源类型
- CPU瓶颈：用 pidstat -u 1 实时看各进程CPU占比；配合 perf top -p [PID] 看函数级热点（需安装 perf）
- 内存瓶颈：用 free -h 看可用内存是否过低，ps aux --sort=-%mem | head 找内存大户；查 dmesg | grep oom 确认是否触发过OOM Killer
- I/O瓶颈：用 iostat -x 1 关注 await、%util、r/s w/s；用 pidstat -d 1 查进程级读写量；lsof +L1 可发现被删除但仍被打开的大文件
- 网络相关：用 ss -s 看连接总数，netstat -s | grep -i "retrans|reset" 查重传或异常断连，nethogs 定位带宽占用进程
针对性处理与临时缓解
确认问题进程后，先评估影响：非关键服务可 kill -15 [PID] 尝试优雅退出；紧急情况下用 kill -9。对Java类应用，建议先 jstack [PID] > stack.log 保留现场再操作。长期方案包括：调整进程优先级（renice -5 [PID]）、限制资源（cgroups 或 systemd CPUQuota）、升级磁盘（HDD → SSD）、加缓存层、拆分大查询等。别忘了检查日志：tail -n 50 /var/log/syslog（Debian系）或 /var/log/messages（RHEL系），常有线索藏在报错前后。
