Linux 系统监控必会:负载平均值怎么读 + top / htop / stress / sar 实战定位瓶颈

Linux 系统监控必会:负载平均值怎么读 + top / htop / stress / sar 实战定位瓶颈 服务器变卡、SSH 一顿一顿第一个该看什么指标负载平均值load average。但uptime后面那三个小数怎么算出来、多大算高、为什么同机器 Linux 的负载总比 UNIX 高很多人说不清。本文先讲透负载的来龙去脉再配齐top / htop / stress / sar四件套stress造负载、top/htop看谁在吃资源、sar判断瓶颈卡在磁盘还是网络。一、系统负载平均值是什么用法速查表概念含义记忆点活动请求数正在运行或等待 IO 的进程数对应状态R和D不只是「在跑」的进程负载平均值活动请求数的指数移动平均是平滑后的平均值不是瞬时值采样周期内核每5 秒计算一次攒起来才得到下面三个数1 分钟短期窗口最敏感波动大5 分钟中期窗口常用来判断趋势15 分钟长期窗口看整体水位涨还是落逐条拆开看活动请求数不仅包含运行中的进程还包含等待 IO 的进程状态R和D。等待 IO 的任务睡在磁盘或网络响应上没占 CPU但对用户同样是「卡住了」所以内核一并算进来。指数移动平均值是一个平滑高值/低值的数学公式避免某一秒的尖峰把曲线顶飞让「一段时间内的负载」更有代表性还能看出负载在升还是在降。内核根据所有 CPU 的活动请求数每 5 秒计算一次再汇总出最近1 分钟、5 分钟、15 分钟的指数移动平均值。一些 UNIX 系统只考虑CPU 使用率或运行队列长度Linux 的负载里还包含 IO 因素——所以「负载很高但 CPU 很闲」时要查磁盘和网络别盯着 CPU 发愁。Linux 把每个物理核心和超线程都当成独立执行单元每个执行单元拥有自己的请求队列。一句话记忆负载平均值 运行中 等待 IO的进程数在1/5/15 分钟三个窗口上的平滑结果。它衡量的是「有多少活等着干」而不是「CPU 有多忙」。二、查看系统负载先看几个核再看数值用法速查表命令作用说明lscpulistCPU列出 CPU 架构信息先确认核心数负载才有解读基准uptimeup time系统已运行时长 当前负载末尾三个数就是 1/5/15 分钟负载md5sum /dev/zero制造 CPU 负载的土办法压测时比等真实业务方便得多上手演示把负载从 0 拉起来# 第一步确认 CPU 核心数负载要除以它才有意义[zhbzhb-m1 ~]$ lscpu Architecture: x86_64 CPU op-mode(s):32-bit,64-bit CPU(s):2# cpu数量为2Thread(s)per core:1Core(s)per socket:1socket2型号名称 Intel(R)Core(TM)i5-6300HQ CPU 2.30GHz......# 第二步查看当前负载[zhbzhb-m1 ~]$uptime13:47:10 up5:01,2users, load average:0.00,0.01,0.05# 第三步给系统加负载两个进程各占满一个核[zhbzhb-m1 ~]$ md5sum /dev/zero[1]4912[zhbzhb-m1 ~]$ md5sum /dev/zero[2]4913# 等 30 秒左右再看[zhbzhb-m1 ~]$uptime13:48:57 up5:03,2users, load average:1.02,0.28,0.13两个满负荷进程跑起来后1 分钟负载涨到 1.02——正好对应「2 核机器上 2 个进程抢 CPU」的直觉。5 分钟、15 分钟还停在 0.28、0.13因为窗口更长还没被这波负载「带起来」。⚠️load average的数值必须结合核心数才有意义。同样是 1.02在 2 核机器上已经是满负荷在 16 核机器上连热身都算不上。三、负载数值怎么解读先除以核心数用法速查表场景负载值每核平均值结论4 核 CPU2.920.732.92 ÷ 4有余量健康4 核 CPU4.481.124.48 ÷ 4刚好满载开始排队4 核 CPU5.201.305.20 ÷ 4过载任务明显排队判定口径很简单把负载除以核心数。每核平均值小于 1还有余量系统跟得上。每核平均值约等于 1刚好把 CPU 吃满再来的任务就得排队。每核平均值持续大于 1已经有任务在排队等 CPU响应变慢是必然的。经验值理想的负载水位是75% 左右每核 0.75 上下特意留出余量突发流量来了不至于立刻排队。四、top动态查看进程与资源占用top动态查看进程信息包括各状态任务数量、CPU 与内存消耗。它比ps更进一步ps拍快照top持续刷新。用法速查表按键 / 命令作用说明toptableofprocesses动态刷新进程与资源统计1数字 1在「所有 CPU 汇总」和「每个 CPU 单独显示」之间切换PProcessor按 CPU 使用率降序默认就是它MMemory按内存使用率降序kkill终止进程按提示输入 PID 和 signalrrenice调整进程的 nice 值sseconds改刷新频率支持 0.5、1、5 这样的带小数秒数uuser过滤指定用户名有效 / 真实qquit退出记忆点大写P/M是两个排序键——P ProcessorCPUM Memory。日常排障最高频的组合大屏top→ 看到谁 CPU 高 →P排序确认 → 动手就k。下面这张图把 top 界面的每个区域都标注清楚了界面从上到下分成四块区域内容看什么第一行当前时间、运行时长、登录用户数、load average与uptime完全一致一眼看负载第二行Tasks总数、running、sleeping、stopped、zombie各状态任务数量分布第三行%Cpu(s)us用户态 /sy系统态 /ninice /id空闲 /wa等待 IO /hisi中断 /st被虚拟化抢占谁在消耗 CPUwa高说明卡在 IO第四、五行KiB Mem物理内存、KiB Swap交换分区内存是否吃紧、有没有在用 swap下方列表PIDUSERPRNIVIRTRESSHRS%CPU%MEMTIMECOMMAND具体是哪个进程完整的交互快捷键这张速查图列得最全建议直接存下来配合 stress 看效果开 2 个 CPU 压测进程后top第一行负载窜到 1.37两个stress的%CPU都是100.0%Cpu(s)的us到100.0——三者互相印证# 压测期间观察 toptop-14:18:22 up47min,2users, load average:1.37,0.50,0.47Tasks:187total,4running,183sleeping,0stopped,0zombie %Cpu(s):100.0 us,0.0sy,0.0ni,0.0id,0.0wa,0.0hi,0.0si,0.0st KiB Mem:4026124total,1535676free,490668used,1999780buff/cache KiB Swap:4063228total,4063228free,0used.3277584avail Mem PIDUSERPR NI VIRT RES SHR S %CPU %MEM TIME COMMAND2596root20073121000R100.00.01:01.42 stress2597root20073121000R100.00.01:01.25 stress2594root20016210023201588R0.60.10:00.12top......htop更顺手的交互式查看器top够用但有两个天生短板不支持鼠标、不支持横向滚动命令行一长就被截断按c也不行。htop正是冲着这些体验问题来的——彩色条状图、可点鼠标、能左右滚看完整命令行。先分清一个易混点top属于procps-ng包几乎每台 Linux 都自带htop是独立项目得额外装。# CentOS / RHEL 7htop 在 EPEL 仓库里要先启用 EPELsudoyuminstall-yepel-releasesudoyuminstall-yhtop# Debian / Ubuntu官方源里直接有sudoaptupdatesudoaptinstall-yhtop和 top 的差异速查表维度tophtop安装procps-ng自带几乎无处不在需单独装CentOS 在 EPEL鼠标❌ 纯键盘✅ 可点击、可滚动横向滚动❌ 长命令行被截断✅←→看完整命令行树视图✅ 按V进森林视图✅F5切换批量操作❌ 一次只能处理一个 PID✅ 空格标记多个一起 kill / renice界面单色文本彩色条状图每核 CPU、内存、swap脚本化✅top -b -n 1可输出到文件❌ 纯交互没有批处理模式别被网上的对比表带偏不少中文教程写「进程树视图htop 支持 / top 不支持」——这是错的top从 procps-ng 3.3 起就支持森林视图按V开启。真正的差异是鼠标和横向滚动而且top一按排序键就退出森林视图官方手册明确说明用起来没那么稳。常用快捷键均出自htop(1)官方手册按键作用F1/h/?帮助F2/S设置配置顶部仪表、颜色方案、显示哪些列F3//按命令行增量搜索F4增量过滤只留匹配的进程F5/t树视图按父子关系排布F6/选排序字段F7减nice 值 → 提高优先级需 rootF8加nice 值 → 降低优先级F9/k发信号kill弹出菜单选具体信号F10/q退出空格标记 / 取消标记当前进程可多选批量操作u只看某个用户的进程P/M/T按 CPU / 内存 / 运行时间排序沿用top的习惯键F「跟随」选中进程让它始终留在视野内K/H隐藏内核线程 / 用户线程开关p/Z显示程序完整路径 / 暂停刷新开关s/l/w调strace追系统调用 / 调lsof看打开的文件 / 完整命令行另开屏看两个容易搞反、容易忽略的点F7是「减 nice」。nice 越小优先级越高所以F7其实在提高优先级F8才降。有的教程写「F7 降低优先级」——按 nice 说是降、按 priority 说是升记「F7 减 nice、F8 加 nice」就不绕晕。s和l是两个彩蛋选中进程按s直接strace追系统调用按l列它打开的文件。排查「这个进程卡在哪」极好用不用另开终端手敲 PID。什么时候还得回top写脚本或定时采集时top -b -n 1能把一屏结果输出到文件htop面向交互没有非交互模式采集交给top、vmstat或sar。五、stress四个维度主动造负载stress是 Linux 压力测试工具可对 CPU、内存、IO、磁盘施加高负载用来验证系统在压力下的表现常用于性能调优和硬件验证。# 安装属于 EPEL 仓库[rootzhb-m1 ~]# yum install -y stress用法速查表参数英文全称作用-c Ncpu启动 N 个 worker 空转sqrt()压 CPU-i Nio启动 N 个 worker 反复sync()压 IO-m Nvirtualmemory启动 N 个 worker 反复malloc()/free()压内存--vm-bytes Bvm bytes每个 vm worker 分配的内存量默认 256MB-d Nhdd启动 N 个 worker 反复 write / unlink压磁盘--hdd-bytes Bhdd bytes每个 hdd worker 写入的字节数默认 1GB-t NtimeoutN 秒后自动结束-vverbose输出更详细的信息-qquiet安静模式不打印中间信息记忆点四个压测维度各占一个字母——c是 CPU、i是 IO、m是内存virtual memory、d是磁盘hdd。数值后面的单位可带s/m/h/d/y时间或B/K/M/G大小。压 CPU# 消耗 2 个 CPU[rootzhb-m114:17:19]# stress -c 2stress: info:[2595]dispatching hogs:2cpu,0io,0vm,0hdd启动后配top观察就能看到前面那一幕负载升高、两个stress进程各占100.0CPU。压内存# 压测前看内存基线[rootzhb-m114:21:06]# free -mtotal usedfreeshared buff/cache available Mem:393147815001419523201Swap:396703967# 消耗 1G 内存[rootzhb-m114:19:11]# stress -m 1 --vm-bytes 1Gstress: info:[2623]dispatching hogs:0cpu,0io,1vm,0hdd# 压测后used 从 478 涨到 1403多出的约 925MB 就是被吃掉的[rootzhb-m114:21:44]# free -mtotal usedfreeshared buff/cache available Mem:393114035751419522274Swap:396703967压磁盘# 持续往磁盘写 2G 数据压 IO[rootzhb-m114:22:21]# stress -d 1 --hdd-bytes 2G# 用 sar 观察磁盘饱和度重点看 %util[rootzhb-m114:23:28]# yum install -y sysstat[rootzhb-m114:23:31]# sar -dp 114时23分29秒 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util14时23分30秒 sda2699.000.002762752.001023.626.112.260.2979.5014时23分30秒 centos-root2698.000.002761728.001023.626.112.260.2979.50......%util到了79.50说明这块盘已经有八成时间在处理请求——磁盘正在成为瓶颈。六、sar定位磁盘 IO 与网络带宽瓶颈sar是systemactivityreporter属于sysstat包按秒级粒度输出各资源的历史统计负载高时的「嫌疑排查」全靠它。用法速查表命令作用关键列yum install -y sysstat安装 sar—sar -dp 1每秒刷新磁盘活动%util饱和率、await平均等待、tps每秒传输次数sar -n DEV 1每秒刷新网卡流量rxkB/s接收、txkB/s发送、rxpck/s收包数磁盘sar -dp 1列英文全称含义tpstransactionspersecond每秒传输次数IOPS 参考rd_sec/sreadsectors每秒读扇区数wr_sec/swritesectors每秒写扇区数avgrq-szaveragerequestsize平均每次请求的扇区数avgqu-szaveragequeuesize平均请求队列长度awaitaveragewait平均等待时间毫秒越大越慢svctmservicetime平均服务时间%utilutilization设备繁忙百分比接近 100% 说明已饱和网络sar -n DEV 1# 传送一个大文件同时监控带宽[rootzhb-m114:27:17]# wget http://192.168.43.100/isos/CentOS-7-x86_64-DVD-2207-02.iso# 每秒刷新网卡流量[rootzhb-m114:29:13]# sar -n DEV 114时29分07秒 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s14时29分08秒 ens3269961.005404.0096338.71513.950.000.000.00......rxkB/s达到 96338.71约 94MB/s说明这块网卡正在被下载流量喂饱。排障顺序建议负载高时先在top里看%Cpu(s)的wa——wa高说明瓶颈不在 CPU 而在 IO。再用sar -dp 1查磁盘、sar -n DEV 1查网络两步就能锁定是哪块资源拖后腿。七、最佳实践总结负载看三个数、除一次核心数uptime的 1/5/15 分钟三个窗口除以核心数才是有意义的「水位」每核 0.75 左右最舒服。负载高先怀疑 IOLinux 的负载包含等待 IO 的进程D状态负载高但 CPU 闲八成卡在磁盘或网络。排障用三件套top/htop看谁在吃资源%Cpu(s)的wa是关键线索、stress主动造负载验证、sar落到具体设备%util、rxkB/s。命令要能互相印证uptime的负载、top第一行、stress起的进程数三个信息对得上结论才站得住。附命令英文全称速查表命令 / 参数英文全称含义lscpulistCPU列出 CPU 架构信息uptimeup time系统运行时长与负载toptableofprocesses动态查看进程与资源sarsystemactivityreporter系统活动报告器stressstress压力测试工具load averageload average负载平均值RRunning运行中DDisk sleepuninterruptible不可中断睡眠通常在等 IOSSleeping可中断睡眠ZZombie僵尸状态ususerCPU 用户态占用sysystemCPU 系统态占用wawaitCPU 等待 IO 的时间占比ididleCPU 空闲占比ststeal被虚拟化抢占的 CPU 时间tpstransactionspersecond每秒传输次数awaitaveragewait平均等待时间%utilutilization设备繁忙百分比 参考资料官方文档 · 中英双语英文原版man7.orguptime 命令手册top 命令手册free 命令手册sar 命令手册其他官方文档htop 命令手册Debian manpageshtop 官方项目站中文版uptime 命令中文说明菜鸟教程free 命令中文说明菜鸟教程htop 命令中文说明菜鸟教程这篇把「看负载 → 找元凶 → 定瓶颈」这条链路走通了。对进程本身的管理发信号、批量杀进程、僵尸与孤儿感兴趣的话见姊妹篇《Linux 进程管理必会信号机制 kill / pgrep / pkill 发信号 who / w / last 查看登录用户》与《Linux 僵尸进程与孤儿进程必会kill -9 为什么杀不掉僵尸》。觉得有用的话点赞收藏评论区聊聊你遇到过的诡异负载。