# 安装 sysstat 包
yum install sysstat
参数 功能描述
-c 显示 CPU 使用情况
-d 显示磁盘使用情况
-k 以 KB 为单位显示数据
-m 以 MB 为单位显示数据
-N 显示磁盘阵列(LVM)信息
-n 显示 NFS 使用情况
-p[磁盘] 显示指定磁盘和分区的情况
-t 显示终端和 CPU 的信息
-x 显示详细信息
-V 显示版本信息

基础输出解读

# 安装后可使用io状态子命令，每2秒采集一次，共采集100次（总共持续200秒）
iostat 2 100

执行 iostat 2 100 后的典型输出：

Linux 2.6.18-128.el5 (CT1186)   2012年12月28日

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.30    0.02    5.07    0.17    0.00   86.44

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda              22.73        43.70       487.42  674035705 7517941952
sda1              0.00         0.00         0.00       2658        536
sda2              0.11         3.74         3.51   57721595   54202216
sda3              0.98         0.61        17.51    9454172  270023368

输出中上半部分是 CPU 涉及到io的状态指标

1. %user - 用户模式CPU时间

含义：CPU 在运行用户空间程序（应用程序）上所花费的时间百分比

计算公式：

%user = (用户态CPU时间 / 总CPU时间) × 100%

典型场景：

  • 数值高：Web服务器处理请求、数据库执行查询、应用程序计算
  • 正常范围：取决于应用类型，通常 20%-70%
  • 预警值：持续 >80% 可能表示应用需要优化或需要更多CPU资源

示例：

# 如果 %user = 45.2%
# 表示CPU有45.2%的时间在执行应用程序代码

2. %nice - 低优先级用户模式CPU时间

含义：CPU 在运行 低优先级（nice值 > 0） 用户程序的时间百分比

技术背景：

  • nice值范围：-20（最高优先级）到 19（最低优先级）
  • 默认nice值：0
  • 负nice值需要root权限

实际意义：

# 运行低优先级任务
nice -n 10 compress_large_file.sh

# 此时该任务消耗的CPU会计入 %nice

典型值：

  • 通常很低：0.1% - 2%
  • 值较高：系统正在运行后台批处理任务

3. %system - 系统模式CPU时间

含义：CPU 在执行内核系统调用上所花费的时间百分比

包含的操作：

  • 系统调用（文件I/O、网络通信、进程管理）
  • 中断处理
  • 内核线程执行
  • 内存管理

诊断价值：

# %system 高的可能原因：
# 1. 大量系统调用
# 2. 频繁进程上下文切换
# 3. 设备中断过多
# 4. 内核模块繁忙

正常范围：

  • 通常：2% - 20%
  • 预警：持续 >30% 需要调查系统调用优化

4. %iowait - I/O等待时间 ⚠️ 关键指标

含义：CPU 空闲且 同时 有未完成的磁盘I/O请求的时间百分比

重要理解：

  • 不是CPU繁忙的程度，而是CPU想工作但被I/O阻塞的程度
  • 需要两个条件同时满足：
    1. CPU 处于空闲状态
    2. 至少有一个I/O请求在处理中

计算公式：

%iowait = (I/O等待时间 / 总CPU时间) × 100%

性能诊断：

# 不同范围的解释：
%iowait < 5%   : 正常，I/O压力小
%iowait 5%-20% : 轻度I/O压力
%iowait 20%-40%: 明显I/O瓶颈
%iowait > 40%  : 严重I/O瓶颈，需要立即处理

5. %steal - 虚拟化环境下，虚拟机获取CPU资源，但进入时间片轮转机制时间的百分比

含义：在虚拟化环境中，物理CPU被hypervisor用于服务其他虚拟机的等待时间。比如宿主机上有a、b两个虚拟机，a正在使用cpu资源，此时b也要用且分配不均匀时，或者说不够b要用的，此时b等待的这段时间就叫steal

仅适用于：虚拟机环境

诊断意义：

# 数值解释：
%steal < 5%   : 正常
%steal 5%-10% : 轻度资源竞争
%steal > 10%  : 严重资源竞争，考虑迁移虚拟机或升级配置

6. %idle - 空闲时间

含义：CPU 完全空闲且没有未完成I/O请求的时间百分比

计算公式：

%idle = 100% - (%user + %nice + %system + %iowait + %steal)

性能分析：

# 不同情况的解读：

# 情况1：%idle高，系统响应快
# ✅ 正常：系统资源充足

# 情况2：%idle高，但系统响应慢
# ❌ 可能问题：内存不足（CPU在等待内存分配）
#              应用程序锁竞争
#              网络延迟

# 情况3：%idle持续 < 10%
# ❌ CPU资源紧张，需要考虑：
#    - 优化应用程序
#    - 增加CPU资源
#    - 负载均衡

实际监控示例分析

示例1：健康的Web服务器

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           68.2     0.1     8.3     0.2     0.0    23.2

分析：

  • %user=68.2%：主要处理用户请求，正常
  • %system=8.3%：系统调用适中
  • %iowait=0.2%：几乎没有I/O瓶颈
  • %idle=23.2%：有足够CPU缓冲容量
  • 结论：系统运行健康

示例2：I/O瓶颈的数据库服务器

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           15.3     0.0    12.7    45.8     0.0    26.2

分析：

  • %iowait=45.8%：严重I/O瓶颈
  • %user=15.3%：CPU大部分时间在等待I/O
  • %idle=26.2%：虚假空闲，实际是I/O阻塞
  • 结论：需要优化磁盘性能或查询

示例3：CPU饱和的应用服务器

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           85.6     0.0     9.8     0.1     0.0     4.5

分析：

  • %user=85.6%：应用消耗大量CPU
  • %idle=4.5%：CPU资源紧张
  • %iowait=0.1%：无I/O问题
  • 结论：需要优化应用代码或增加CPU

示例4：虚拟化环境资源竞争

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           35.2     0.1     6.3     1.2    15.4    41.8

分析：

  • %steal=15.4%：明显虚拟化资源竞争
  • %user=35.2%：实际应用CPU使用被挤压
  • 结论：需要与云服务商协商或迁移实例

监控实践建议

1. 长期趋势分析

# 持续监控，观察趋势
iostat -c 60 10    # 每60秒一次，共10次

2. 结合其他工具

# 结合磁盘I/O分析
iostat -c -d -x 2 5

# 结合进程监控
top -p $(pgrep your_app)

3. 预警阈值设置

critical:
  %iowait: > 40%
  %idle: < 5%
  %steal: > 10%
  
warning:
  %user: > 85%
  %system: > 25%
  %iowait: > 20%

重要理解要点

  1. %iowait 不等于 I/O繁忙度：它衡量的是CPU被I/O阻塞的程度
  2. %idle 需要结合系统响应时间：高空闲率+慢响应可能隐藏其他问题
  3. 所有指标的总和应为100%：可用于验证数据准确性
  4. 关注趋势而非单点值：短期峰值正常，持续异常需要关注

下半部分是磁盘I/O的其他指标

参数 说明 性能分析意义
tps 每秒传输次数（I/O请求次数） 值越高表示磁盘处理能力越强，通常达到400即可满足TB级大数据应用
Blk_read/s 每秒读取的数据量（块/秒） 监控读操作压力
Blk_wrtn/s 每秒写入的数据量（块/秒） 监控写操作压力
Blk_read 累计读取的数据总量 历史统计
Blk_wrtn 累计写入的数据总量 历史统计

详细磁盘性能分析

使用 iostat -d -x -k 1 1 获取更全面的磁盘性能数据：

[root@CT1186 ~]# iostat -d -x -k 1 1

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.44    38.59  0.40 22.32    21.85   243.71    23.37     0.04    1.78   4.20   9.54

详细参数解析

参数 全称 说明 性能分析意义
rrqm/s Read Requests Merged per Second 每秒合并的读请求数 值高表示读请求有较好的合并优化
wrqm/s Write Requests Merged per Second 每秒合并的写请求数 值高表示写请求有较好的合并优化
r/s Reads per Second 每秒完成的读I/O次数 直接反映读操作频率
w/s Writes per Second 每秒完成的写I/O次数 直接反映写操作频率
rkB/s Read KB per Second 每秒读取的数据量(KB) 读吞吐量指标
wkB/s Write KB per Second 每秒写入的数据量(KB) 写吞吐量指标
avgrq-sz Average Request Size 平均每次I/O操作的数据大小(扇区) 反映I/O请求的平均大小
avgqu-sz Average Queue Size 平均I/O队列长度 关键指标：值大表示有大量I/O在等待
await Average Wait Time 平均每次I/O操作的等待时间(毫秒) 关键指标：包括队列等待和服务时间
svctm Service Time 平均每次I/O操作的服务时间(毫秒) 磁盘处理单个请求所需时间
%util Utilization I/O操作占用CPU时间百分比 关键指标：接近100%表示磁盘饱和

性能瓶颈诊断指南

1. 磁盘利用率分析

  • %util > 70%：I/O压力较大
  • %util ≈ 100%：磁盘已成为系统瓶颈，I/O请求过多

2. 响应时间分析

  • await vs svctm 关系：
    • await ≈ svctm：I/O响应良好，几乎没有等待
    • await >> svctm：I/O队列过长，响应变慢，需要优化

3. 队列深度分析

  • avgqu-sz 值较大：表示有大量I/O请求在排队等待
  • 结合 vmstat 命令的 b(等待进程数)和 wa(I/O等待CPU百分比)参数：
    • wa > 30%：I/O压力较高

4. 请求模式分析

通过公式计算：avgqu-sz × (r/s + w/s) = rkB/s + wkB/s

  • 可分析I/O请求模式和数据传输特性

形象的银行排队比喻

I/O 概念 银行排队比喻 说明
r/s + w/s 顾客总数 单位时间内办理业务的总人数
avgqu-sz 平均排队人数 单位时间内平均有多少人在排队
svctm 柜员办理速度 柜员处理单个业务所需时间
await 平均等待时间 顾客从排队到办完业务的总时间
avgrq-sz 平均业务量 每个顾客平均办理的业务数量
%util 柜台繁忙率 柜台有人办理业务的时间比例

实用诊断技巧

  1. 综合监控：结合 iostat、vmstat 和 top 命令综合分析
  2. 趋势观察：长时间监控而非单次快照
  3. 阈值预警：设定 %util、await 等关键指标的预警阈值
  4. 根因分析：区分是应用程序问题还是硬件性能瓶颈
# linux # 运维 # 服务器
Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

cover

Electron 主进程与渲染进程通信详解：HarmonyOS PC基于 `ipcRenderer.send` 与 `ipcMain.on` 的双向数据传输

avatar 2048 AI社区
cover

LangChain与LangGraph：让大模型开发更简单，小白也能轻松掌握（收藏必备）

avatar 2048 AI社区
cover

37岁北漂程序员因职业倦怠决定转行大模型

avatar 2048 AI社区