LinuxCentOS系统管理入门笔记第十一期——系统负载监控uptime/top/stress 与性能分析引言服务器的“体检报告”——如何判断系统是否健康Linux系统管理入门系列更多文章欢迎访问Linux入门——系统管理1我的主页AOwhisky这里有更多运维系统性知识整理和其他有趣内容欢迎与我一起探讨学习~你接手了一台服务器用户反馈“系统变慢了”。你登录上去第一件事应该做什么是凭感觉猜测还是用数据说话系统管理员需要一套量化的健康指标——就像医生用体温计、血压计、心电图来判断病人的身体状况。Linux 系统提供了完整的“体检工具链”Load Average系统负载平均值相当于“系统的体温”——过高说明系统“发烧”了uptime快速看一眼系统运行了多久、负载多高top动态的“CT 扫描”实时展示每个进程的资源消耗stress人工制造“病情”用于压力测试和容量规划sar历史“病历本”记录系统过去一段时间的各项指标本期我们将系统学习这些工具让你面对任何一台服务器都能快速完成“健康评估”——知道哪里有问题、问题有多严重、应该从哪里入手解决。读完这一期你将不再说“我觉得系统变慢了”而是说“系统负载平均值是 2.5wa 占 30%说明磁盘 I/O 是瓶颈”。— Compiled and Authored by Whisky — July 24 th, 2026目录Load Average系统负载的真实含义uptime快速健康检查top动态性能监控stress压力测试工具箱sar历史性能数据采集网络性能监控总结与速查手册1. Load Average系统负载的真实含义1.1 什么是 Load AverageLoad Average系统负载平均值是 Linux 内核维护的一个核心性能指标表示系统在特定时间段内的活动进程数的指数移动平均值。Linux 每 5 秒计算一次负载并维护三个时间维度的平均值时间维度含义用途1 分钟最近 1 分钟的平均负载实时状态短期峰值检测5 分钟最近 5 分钟的平均负载中期趋势判断负载是否在上升/下降15 分钟最近 15 分钟的平均负载长期趋势反映系统整体负载水平1.2 Linux 负载的独特之处维度传统 UNIXLinux负载计算依据仅CPU 运行队列中的进程数CPU 运行队列 等待 I/O的进程数高负载但 CPU 空闲不太可能可能大量进程在等待磁盘/网络⚠️重要结论Linux 中负载高不一定是 CPU 不够用磁盘 I/O 和网络 I/O 也可能导致负载飙升。遇到高负载时一定要结合top的waI/O 等待列综合判断。1.3 活动进程包括哪些RRunning状态正在使用 CPU 或等待 CPU 调度DUninterruptible Sleep状态不可中断睡眠通常正在等待磁盘或网络 I/O白话理解活动进程 “正在干活的工人”R “正在等材料到货的工人”D。两者都算在负载中。1.4 如何解读负载数值关键负载值需要与 CPU 核心数对比而不是绝对值。判断标准条件结论含义负载 核心数 × 0.7✅ 健康系统资源充足核心数 × 0.7 ≤ 负载 ≤ 核心数 × 1.0⚠️ 注意接近饱和需关注负载 核心数 × 1.0 过载存在性能瓶颈计算示例系统有 4 个 CPU 核心 负载值为2.921 分钟4.485 分钟5.2015 分钟 每个核心的负载 1 分钟2.92 ÷ 4 0.73 → 健康低于 0.7×4 2.8接近饱和 5 分钟4.48 ÷ 4 1.12 → 过载超过 4 15 分钟5.20 ÷ 4 1.30 → 过载超过 4 结论系统正在从短期过载进入长期过载需要排查原因。1.5 负载趋势分析趋势含义1 分钟 5 分钟 15 分钟负载持续上升系统正在恶化 1 分钟 5 分钟 15 分钟负载持续下降系统正在恢复 三者相近负载稳定处于稳态# 实际查看负载[whiskycentos7 ~]$uptime13:47:10 up5:01,2users, load average:0.00,0.01,0.05# ↑ ↑ ↑# 1分钟 5分钟 15分钟2. uptime快速健康检查uptime是系统管理员最常用的“看一眼”命令——一行输出包含四个核心信息。2.1 输出解析[whiskycentos7 ~]$uptime13:47:10 up5:01,2users, load average:0.00,0.01,0.05部分含义示例值当前时间系统当前时间13:47:10运行时长系统已运行多久up 5:015 小时 1 分钟在线用户数当前登录的用户数2 users负载平均值1/5/15 分钟负载0.00, 0.01, 0.052.2 生产环境应用# 快速判断重启后负载通常较低运行时间越长负载可能越高[whiskycentos7 ~]$uptime09:30:15 up45days,3:15,3users, load average:0.25,0.30,0.28# 运行 45 天负载稳定在 0.3 左右假设 4 核健康3. top动态性能监控top是 Linux 系统管理员最重要的交互式性能监控工具提供实时的进程级资源消耗视图。3.1 启动与退出# 启动 top[whiskycentos7 ~]$top# 退出按 q 键# 显示完整命令路径默认只显示命令名[whiskycentos7 ~]$top-c# 以批处理模式输出适合脚本[whiskycentos7 ~]$top-bn13.2 top 界面解读top - 14:18:22 up 47 min, 2 users, load average: 1.37, 0.50, 0.47 Tasks: 187 total, 4 running, 183 sleeping, 0 stopped, 0 zombie %Cpu(s):100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 4026124 total, 1535676 free, 490668 used, 1999780 buff/cache KiB Swap: 4063228 total, 4063228 free, 0 used. 3277584 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND 2596 root 20 0 7312 100 0 R 100.0 0.0 1:01.42 stress 2597 root 20 0 7312 100 0 R 100.0 0.0 1:01.25 stress顶部统计信息行内容关键字段1系统概要当前时间、运行时长、用户数、负载平均值2任务统计总进程数、运行中、睡眠、停止、僵尸3CPU 使用率us/sy/id/wa见下表4内存使用总内存、空闲、已用、缓存buff/cache5交换分区总 Swap、已用、空闲、可用内存CPU 使用率各字段含义字段含义正常范围us用户空间进程消耗的 CPU 时间取决于应用类型sy系统内核消耗的 CPU 时间 20%ni低优先级进程nice 值消耗的 CPU—id空闲 CPU 百分比越高越好waI/O 等待CPU 等待磁盘/网络 5%10% 说明 I/O 瓶颈hi硬中断消耗通常很低si软中断消耗通常很低st虚拟机偷取时间宿主机超售云环境中可能出现⚠️关键诊断如果wa 10% 且id较低说明I/O 是瓶颈而不是 CPU 计算能力不足。进程列表各列含义字段含义PID进程 IDUSER运行用户PR优先级内核调度优先级NINice 值用户可调整的优先级-20 到 19VIRT虚拟内存大小KBRES常驻物理内存大小KBSHR共享内存大小KBS进程状态R/S/D/T/Z%CPUCPU 使用率%MEM内存使用率TIME累计 CPU 时间COMMAND命令名3.3 top 交互快捷键按键作用1展开/折叠 CPU 核心视图多核系统显示每个核心P按 CPU 使用率排序大写 P最常用M按内存使用率排序k终止一个进程输入 PID 和信号r调整进程优先级reniceq退出h帮助f选择显示的列3.4 多核 CPU 展开视图按1键后CPU 行会展开为每个核心独立的统计%Cpu0 : 50.0 us, 0.0 sy, 0.0 ni, 50.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu1 : 100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st在多核系统中单个核心可能满载而其他核心空闲——top默认显示的是所有核心的平均值可能掩盖单核热点问题。4. stress压力测试工具箱stress是 Linux 中专门用于人工制造系统负载的工具用于压力测试、容量规划和性能调优验证。4.1 安装[rootcentos7 ~]# yum install -y stress4.2 常用参数参数作用示例-c N创建 N 个 CPU 压力进程计算 sqrtstress -c 2-i N创建 N 个 I/O 压力进程调用 syncstress -i 4-m N创建 N 个内存压力进程分配内存stress -m 2--vm-bytes B每个内存进程分配 B 字节--vm-bytes 1G-d N创建 N 个磁盘压力进程写/删除stress -d 2--hdd-bytes B每个磁盘进程写入 B 字节--hdd-bytes 2G-t N运行 N 秒后自动退出stress -t 604.3 压力测试实战CPU 压力测试# 制造 2 个 CPU 满载进程适合 2 核系统[rootcentos7 ~]# stress -c 2 -t 60stress: info:[2595]dispatching hogs:2cpu,0io,0vm,0hdd stress: info:[2595]successful run completedin60s# top 观察效果top-14:18:22 up47min, load average:1.37,0.50,0.47%Cpu(s):100.0 us,0.0sy,0.0ni,0.0id,0.0wa,0.0hi,0.0si,0.0st PIDUSER%CPU COMMAND2596root100.0stress2597root100.0stress内存压力测试# 检查当前内存使用情况[rootcentos7 ~]# free -mtotal usedfreeshared buff/cache available Mem:393147815001419523201Swap:396703967# 消耗 1GB 内存1 个进程分配 1GB[rootcentos7 ~]# stress -m 1 --vm-bytes 1G -t 30# 再次查看内存[rootcentos7 ~]# free -mtotal usedfreeshared buff/cache available Mem:393114035751419522274# ↑# 已用从 478MB 增加到 1403MB磁盘 I/O 压力测试# 制造磁盘写入压力1 个进程写入 2GB 数据[rootcentos7 ~]# stress -d 1 --hdd-bytes 2G -t 30# 使用 sar 监控磁盘 I/O 效果[rootcentos7 ~]# sar -dp 114:23:30 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util14:23:31 sda2579.000.002638848.001023.2152.8418.580.3283.00# ↑# %util 83%4.4 压力测试的价值场景用途容量规划确定系统能承受的最大负载性能验证验证调优效果如调整内核参数后监控验证确认监控系统能正确捕获高负载故障演练模拟高负载场景下的系统行为5. sar历史性能数据采集sarSystem Activity Reporter是 sysstat 工具包的核心组件可以采集和报告系统活动的历史数据。5.1 安装与启用# 安装 sysstat[rootcentos7 ~]# yum install -y sysstat# 启动数据采集服务CentOS 7[rootcentos7 ~]# systemctl start sysstat[rootcentos7 ~]# systemctl enable sysstat# 数据默认存储在 /var/log/sa/ 目录[rootcentos7 ~]# ls /var/log/sa/sa01 sa02 sa03...# saXX 为当天的数据文件5.2 常用选项# 查看 CPU 使用情况每 1 秒采样一次共 5 次sar-u15# 查看内存使用情况sar-r15# 查看磁盘 I/O按设备sar-d15# 查看网络接口流量sar-nDEV15# 查看历史数据指定日期如 7 月 24 日sar-u-f/var/log/sa/sa245.3 实战示例# 实时监控磁盘 I/O[rootcentos7 ~]# sar -dp 1Linux3.10.0-1160.el7.x86_64(centos7)07/24/2026 _x86_64_(2CPU)14: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 sr00.000.000.000.000.000.000.000.0014:23:30 centos-root2698.000.002761728.001023.626.112.260.2979.505.4 sar 输出关键字段解读字段单位/含义说明tps每秒传输次数每秒钟的 I/O 操作数读写rd_sec/s每秒读取扇区数1 扇区 512 字节wr_sec/s每秒写入扇区数同上avgrq-sz平均 I/O 请求大小扇区越大说明 I/O 越批量avgqu-sz平均 I/O 队列长度 1 说明有 I/O 积压await平均 I/O 等待时间毫秒 10ms 说明磁盘较慢svctm平均服务时间毫秒磁盘本身的响应速度%util磁盘繁忙百分比 70% 说明磁盘是瓶颈6. 网络性能监控6.1 网络带宽监控sar -n DEV# 监控网络接口流量[rootcentos7 ~]# sar -n DEV 114:27:17 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s14:27:18 lo0.000.000.000.000.000.000.0014:27:18 ens3312.008.000.720.960.000.000.0014:27:18 ens370.000.000.000.000.000.000.00# rxpck/s: 每秒接收包数txpck/s: 每秒发送包数# rxkB/s: 每秒接收 KBtxkB/s: 每秒发送 KB6.2 模拟网络流量# 在另一台机器上提供大文件下载服务或者下载大文件[rootcentos7 ~]# wget http://192.168.43.100/CentOS-7-x86_64-DVD-2207-02.iso6.3 网络性能关键指标指标含义异常信号rxkB/s/txkB/s带宽使用量接近网卡上限rxpck/s/txpck/s包速率过高可能导致 CPU 软中断高rxcmp/s/txcmp/s压缩包通常为 0rxmcst/s多播包—7. 总结与速查手册7.1 核心知识点一览主题关键点Load Average活动进程数的指数移动平均值Linux 包含等待 I/O 的进程负载解读与 CPU 核心数对比 0.7×核心数 健康 核心数 过载uptime快速查看负载和运行时长top动态监控P按 CPU 排序1查看多核关注wa列stress压力测试工具-cCPU、-m内存、-d磁盘、-iI/Osar历史性能数据采集-uCPU、-r内存、-d磁盘、-n DEV网络7.2 命令速查表命令作用uptime查看运行时长和负载平均值top交互式进程资源监控top -c显示完整命令路径top -bn1批处理模式单次输出适合脚本stress -c 2 -t 60制造 2 个 CPU 满载进程运行 60 秒stress -m 1 --vm-bytes 1G消耗 1GB 内存sar -u 1 5每 1 秒采样 CPU共 5 次sar -d 1 5每 1 秒采样磁盘 I/O共 5 次sar -n DEV 1 5每 1 秒采样网络流量共 5 次sar -u -f /var/log/sa/sa24查看 7 月 24 日的 CPU 历史数据7.3 性能瓶颈速查表现象可能原因验证工具负载高CPUus高CPU 计算密集型瓶颈topP 排序负载高CPUwa高磁盘 I/O 瓶颈sar -d、iostat负载高CPUsy高系统调用/内核模块瓶颈strace、perf负载高CPUid高大量进程等待 I/OD 状态ps aux内存使用率高Swap 使用内存不足free -m、topM 排序网络缓慢txkB/s接近上限网络带宽瓶颈sar -n DEV7.4 常见错误排查问题原因解决方案stress: command not found未安装 stressyum install -y stresssar: command not found未安装 sysstatyum install -y sysstatsar无历史数据sysstat 服务未启动systemctl start sysstattop中wa持续 20%磁盘 I/O 瓶颈检查磁盘性能、优化 SQL、增加缓存负载高但 CPU 空闲大量 D 状态进程等待 I/Ops auxstress导致系统无响应压力过大减少压力进程数或缩短运行时间7.5 思考与拓展原课后作业转化Linux 的 Load Average 与传统 UNIX 有什么不同→ 传统 UNIX 只计算 CPU 运行队列中的进程数Linux 还包含等待 I/O 的进程D 状态。因此 Linux 中高负载不一定代表 CPU 忙也可能是磁盘 I/O 瓶颈。top中waI/O 等待高但id空闲也高说明什么→ 说明 CPU 大部分时间在空闲但有一部分时间在等待 I/O 完成。如果wa 10%磁盘 I/O 是性能瓶颈。stress -c 2在 4 核系统上负载平均值会是多少→ 理论上会接近 2.0两个进程满负载每个核心的负载为 2.0/40.5不会触发过载阈值 4×0.72.8。sar的历史数据保存在哪里如何查看前一天的 CPU 使用情况→ 保存在/var/log/sa/saXXXX 为日期。查看前一天如 23 号sar -u -f /var/log/sa/sa23。top中%CPU总和为什么可能超过 100%→ 因为多核系统中%CPU显示的是单个进程占用的 CPU 核心数百分比。一个进程占用 2 个核心 100%%CPU显示 200%。7.6 生产环境最佳实践场景建议日常巡检每天执行uptime和 top -bn1性能告警设置负载告警阈值如 核心数 × 0.8历史数据确保sysstat服务启用保留 7-30 天历史数据压力测试在测试环境使用stress逐步增加压力观察系统响应问题定位负载高时按“CPU → 内存 → 磁盘 → 网络”顺序排查容量规划结合sar历史数据分析业务增长趋势提前扩容下期预告从 Linux 历史哲学到命令行基础从文件系统到权限管理从进程控制到性能监控——第一至十一期我们完成了 Linux 系统管理的“基础篇”学习构建了从 0 到 1 的完整知识框架。接下来系列将进入“系统管理进阶篇”深入 Linux 运维的“硬核”领域。下一期开始我们将依次学习CockpitWeb 图形化管理工具让服务器管理“可视化”软件包管理rpm 与 yum 的底层原理、仓库配置、源码编译计划任务与进程调度at/cron 周期性任务、进程优先级调优存储管理全栈文件系统、硬盘分区MBR/GPT、RAID、LVM 逻辑卷、交换空间系统启动原理CentOS 7 启动流程、grub 配置与故障恢复防火墙与 SELinuxfirewalld 动态防火墙、SELinux 安全加固第十二期我们将从Cockpit 管理工具与 RPM 包管理开始——学会用 Web 界面监控服务器同时深入理解 RPM 软件包的查询、验证与提取技巧。从“会用”到“懂原理”进阶之旅正式启程敬请期待— Compiled and Authored by Whisky — July 24 th, 2026