高负载表现为load average持续超CPU核心数，需通过uptime、top、vmstat定位CPU、内存、I/O或上下文切换瓶颈；再用ps、pidstat、perf、iostat、iotop、free、smem等工具细分根因；最后用cgroup和ionice限制资源。
当 Linux 系统响应缓慢、服务延迟升高或进程频繁超时，往往表明系统处于高负载状态。高负载并不等同于 CPU 占用率高，而是体现在 load average 值持续超过 CPU 核心数，反映的是单位时间内等待运行或正在运行的平均进程数。以下是定位与缓解高负载的多种方法：
一、识别高负载来源
需先确认负载是否真实异常，并定位主导因素（CPU、内存、I/O 或上下文切换）。load average 仅是表象，必须结合多维度指标交叉验证。
1、执行 uptime 查看当前 load average 三值（1/5/15 分钟），并与 nproc 输出的逻辑 CPU 数对比。
2、运行 top，观察 %Cpu(s) 行中 us（用户态）、sy（内核态）、wa（I/O 等待）、si（软中断）占比；同时检查 RES 列总和是否接近物理内存总量。
3、使用 vmstat 1 5 检查 r（就绪队列长度）、b（阻塞进程数）、si/so（交换活动）、bi/bo（块 I/O 速率）及 cs（上下文切换次数）。
二、排查 CPU 密集型进程
CPU 使用率长期高于 90% 且 wa 较低，说明存在计算密集型任务占用大量处理器时间，需定位并限制其资源消耗。
1、执行 ps aux --sort=-%cpu | head -n 11 获取 CPU 占用前 10 的进程及其 PID 和命令行参数。
2、对可疑进程运行 pidstat -u -p PID 1 3，确认其用户态与内核态时间分布及是否频繁调用系统调用。
3、使用 perf top -p PID 定位该进程内部热点函数，判断是否存在算法缺陷或未优化循环。
三、诊断 I/O 瓶颈
当 wa 值持续高于 20%，且 bi/bo 数值显著偏高，说明磁盘或存储子系统成为瓶颈，进程在等待 I/O 完成。
1、运行 iostat -x 1 3，关注 %util（设备饱和度）、await（I/O 平均等待毫秒）、r_await/w_await 及 svctm（服务时间）。
2、执行 iotop -o，筛选出实际产生 I/O 的活跃进程，注意其 READ/WRITE 速率与 IO% 列数值。
3、检查文件系统挂载选项，确认是否启用 noatime 或 barrier=0（仅限可信环境），避免元数据更新拖慢写入。
四、分析内存压力与交换行为
可用内存持续低于 5%、si/so 非零、或 kswapd0 进程 CPU 占用突增，表明系统正频繁进行页面回收与换入换出操作。
1、运行 free -h，重点查看 available 字段而非 free；若 available 远低于 total，且 buff/cache 占比不高，则存在真实内存短缺。
2、执行 cat /proc/meminfo | grep -E "^(MemAvailable|SwapTotal|SwapFree|PageTables|Slab)"，确认页表和内核缓存是否异常膨胀。
3、使用 smem -s rss -r | head -n 10 按 RSS 排序进程，识别内存泄漏或缓存未释放的应用。
五、控制进程资源分配
对已确认为负载源的进程，可通过内核级机制限制其对 CPU、内存、I/O 的无节制索取，避免单点失控影响整体稳定性。
1、将进程加入 CPU 限制组：echo PID > /sys/fs/cgroup/cpu/mygroup/tasks，再设置 echo 50000 > /sys/fs/cgroup/cpu/mygroup/cpu.cfs_quota_us（限制为 50% CPU 时间）。
2、为进程设置内存上限：echo "1G" > /sys/fs/cgroup/memory/mygroup/memory.limit_in_bytes，并启用 memory.oom_control 防止 OOM killer 全局触发。
3、应用 I/O 调度优先级：对关键进程执行 ionice -c 2 -n 7 -p PID，将其设为空闲类 I/O，降低对前台服务的影响。
