Linux负载是就绪态和不可中断睡眠态进程数的指数加权平均，反映排队任务量而非CPU使用率；/proc/loadavg是唯一权威来源；负载＞核心数未必异常，需结合%wa、%us+%sy、D状态、上下文切换等综合判断。
Linux 负载不是 CPU 使用率
很多人一看到 load average 高，立刻去杀 top 里 %CPU 最高的进程，结果负载纹丝不动——因为系统负载根本不是“CPU 正在忙”的度量，而是“有多少任务在排队等资源”的统计。它反映的是就绪态（R）和不可中断睡眠态（D）的 task 数量的指数加权平均（1/5/15 分钟），包括：正在跑 CPU 的、等着跑 CPU 的、以及卡在磁盘 I/O 或内核锁里出不来的进程。
/proc/loadavg 是唯一真相来源
所有工具（uptime、top、htop）都只是读取 /proc/loadavg 这个内核实时生成的伪文件。它的前三个数字就是 1/5/15 分钟 load，第四个是“正在运行/可运行的进程数 / 总进程数”，第五个是最近使用的 PID。别信任何第三方监控插件的“自定义负载算法”——只要没直读这个文件，就可能失真。
负载 > CPU 核心数 ≠ 一定有问题
关键要看是什么状态的进程在推高负载：
PinPHP购物分享系统
下载
PinPHP是一套基于LAMP技术架构(Linux+Apache/Nginx+MySQL+PHP)的、免费的、开源的社会化分享系统！同时PinPHP分享系统V3.0正式版在V2.2正式版的基础上，对“网站架构”、“负载性能”等几大方面，进行了全面升级。注意事项：1、V3.0采用全新的代码结构与数据库结构，不可以进行版本
- 如果
top中%wa（I/O wait）持续 >20%，且大量进程处于D状态，说明是磁盘慢（比如机械盘随机写、NFS 卡顿、RAID 同步中），此时 CPU 其实很闲，但负载飙升； - 如果
%us+%sy接近 100%，且 top 里有单个进程长期占满一个核，那才是真 CPU 瓶颈； - 如果
pidstat -w 1显示每秒上下文切换（cswch/s）超 10 万，而perf record -e sched:sched_switch发现频繁在两个线程间跳，大概率是锁竞争或轮询 busy-wait，这类负载高但 CPU 利用率未必爆表。
指数加权平均让 load 对突发敏感，但会掩盖毛刺
内核用的是指数加权移动平均（EMWA），公式近似 new_load = old_load × exp(-5/60) + current_runnable × (1 − exp(-5/60))。这意味着：
- 1 分钟 load 对最近变化最敏感，适合发现刚爆发的问题；
- 15 分钟 load 更平滑，但一次持续 30 秒的 I/O hang 就足以把它顶高——你看到的“15 分钟 load=8”，可能只是过去 10 分钟里某次数据库备份导致的短暂堆积；
- 它不区分进程轻重：一个 Java 应用 fork 出 1000 个空闲线程，和一个 dd 写盘进程，对 load 的贡献几乎一样，但实际影响天差地别。
真正要判断是否过载，得把 load average 和 vmstat 1 的 r（运行队列长度）、b（阻塞进程数）、wa、cs（上下文切换）一起看。单独盯着一个数字下结论，十次有九次会误判。
