Linux服务器性能监控实战：atop与sysstat工具链系统级性能分析

服务器性能监控工具选型

Linux服务器运维中，性能问题排查是最常见的工作。CPU飙高、内存不足、磁盘IO瓶颈、网络延迟——这些问题的根因往往隐藏在系统内核的多层数据中。atop和sysstat（sar）是两套互补的工具链：atop提供实时进程级监控和历史回放能力，sysstat提供长期趋势分析和数据归档。在服务器故障排查场景下，两者配合使用覆盖从秒级到天级的监控需求。

atop工具安装与实时监控

atop以颜色高亮显示资源占用异常的进程，支持交互式操作和过滤。安装方式：

# CentOS/RHEL
yum install -y atop

# Ubuntu/Debian
apt install -y atop

# 实时监控模式，每2秒刷新
atop 2

# 交互命令：
# t - 按CPU排序
# m - 按内存排序
# d - 按磁盘IO排序
# n - 按网络排序
# c - 按命令行排序
# f - 显示完整命令行

atop的输出分为系统概览和进程列表两部分。系统概览行中关键指标：

# atop典型输出头部
ATOP - 2026/08/24 14:30:00 - 600s elapsed
PRC | sys 0.42s  user 1.85s  #proc 234  #trun 3  #tslpi 120
CPU | sys 12%  user 45%  irq 3%  idle 40%  wait 0%
CPL | avg1 2.35  avg5 3.10  avg15 2.80  csw 45000
MEM | tot 128.0G  free 45.2G  cache 38.5G  dirty 0.5G
DSK | sda busy 85%  read 1200  write 850  MBr/s 45  MBw/s 32
NET | eth0 in 850Mb/s  out 320Mb/s  totin 1.2Gb/s  totout 580Mb/s

当CPU的idle值低于10%且wait值较高时，通常表示磁盘IO成为瓶颈。此时切换到磁盘视图（d键）可以定位具体是哪个进程在产生大量IO。

atop历史数据回放与故障复盘

atop的强大之处在于持续记录系统状态到日志文件，事后可以精确回放任意时间段的系统状态。配置方法：

# /etc/default/atop 配置文件
LOGOPTS="-a"                    # 记录所有进程
INTERVAL=60                     # 采样间隔60秒
LOGGENERATIONS=7                # 保留7天日志

# 启动atop数据采集服务
systemctl enable --now atop atopacct

# 日志存储位置：/var/log/atop/atop_YYYYMMDD

故障回放示例——查看今天14:00-14:30的性能状况：

# 读取今天的atop日志
atop -r /var/log/atop/atop_20260824

# 在回放模式下：
# t - 前进到下一个时间点
# T - 后退到上一个时间点
# b - 跳转到指定时间
# 在atop内输入 b 14:00 跳到14:00
# 然后按t逐步前进查看变化

这种回放能力在服务器故障排查中极其有用。例如凌晨3点服务超时告警，第二天分析时可以回放3点前后的进程级CPU、内存、IO数据，精确定位是哪个进程在异常消耗资源。

sysstat/sar工具链安装与配置

sysstat提供更细致的系统级数据采集，sar命令是查询入口。配置长期数据采集：

# 安装
yum install -y sysstat

# 配置文件 /etc/sysconfig/sysstat
# 修改数据保留天数（默认7天）
HISTORY=30

# 配置文件 /etc/cron.d/sysstat
# 默认每10分钟采集一次，可修改为更密集
*/1 * * * * root /usr/lib64/sa/sa1 1 1
# 每天午夜生成日报
0 0 * * * root /usr/lib64/sa/sa2 -A

# 重启服务
systemctl enable --now sysstat

数据文件存储在/var/log/sa/目录，二进制格式（saDD）和文本格式（sarDD）各一份。

sar常用查询命令与指标解读

sar支持查看CPU、内存、IO、网络、上下文切换等多维度数据：

# CPU使用率（按核心）
sar -u -P ALL -f /var/log/sa/sa24
# 输出：每核CPU的user/system/iowait/idle

# 内存使用
sar -r -f /var/log/sa/sa24
# 关键指标：
# kbcached - 缓存大小
# kbcommit - 已提交内存
# commit%  - 提交比例，超过100%说明overcommit

# 磁盘IO
sar -d -f /var/log/sa/sa24
# 关键指标：
# %util - 磁盘利用率，持续>80%说明IO瓶颈
# await - IO等待时间(ms)，>20ms需要关注

# 网络吞吐
sar -n DEV -f /var/log/sa/sa24 | grep eth0
# 关键指标：
# rxkB/s  - 每秒接收KB
# txkB/s  - 每秒发送KB
# rxerr/s - 接收错误率

# 上下文切换
sar -w -f /var/log/sa/sa24
# cswch/s - 每秒上下文切换次数
# 异常高值(>100000/s)可能指示锁竞争或大量线程切换

结合atop和sar定位性能问题

实际排查中，先用sar锁定问题时间段，再用atop回放该时间段的进程级数据。完整排查流程：

# 步骤1：用sar发现CPU飙高时间段
sar -u -f /var/log/sa/sa24 | awk '$3+$5 > 80 {print}'
# 输出CPU使用率超过80%的时间点

# 步骤2：用atop回放该时间段
atop -r /var/log/atop/atop_20260824
# 在atop内按 b 跳转到问题时间，按t逐步前进

# 步骤3：在atop中按c排序找到CPU最高的进程
# 记录进程PID和命令行

# 步骤4：用pidstat查看该进程的历史数据
pidstat -p $(pgrep -f problem_process) -u -r -d
# 分别查看CPU、内存、IO使用历史

iostat与pidstat深入分析

iostat和pidstat是sysstat工具链的补充，用于更细粒度的分析：

# iostat - 磁盘IO详细分析
iostat -dxm 2
# 输出指标：
# rrqm/s   - 每秒合并读请求
# wrqm/s   - 每秒合并写请求
# r/s w/s  - 每秒读写IOPS
# rsec/s   - 每秒读扇区数
# await    - 平均IO等待时间
# %util    - 磁盘利用率

# pidstat - 进程级资源使用
pidstat -d 2        # 每个进程的IO使用
pidstat -u 2        # 每个进程的CPU使用
pidstat -r 2        # 每个进程的内存使用
pidstat -w 2        # 每个进程的上下文切换

当await持续超过50ms且%util接近100%时，磁盘成为性能瓶颈。此时需要考虑更换NVMe SSD或增加磁盘条带数量。

自定义监控脚本与告警集成

将atop/sar数据集成到告警系统，实现自动化监控：

#!/bin/bash
# /opt/monitor/perf_alert.sh
# 基于sar数据的自动告警脚本

THRESHOLD_CPU=85
THRESHOLD_IO_WAIT=20
LOG_FILE="/var/log/sa/sa$(date +%d)"

# 获取最近5分钟CPU平均使用率
CPU_USAGE=$(sar -u -s $(date -d '5 min ago' +%H:%M:%S) -e $(date +%H:%M:%S) -f $LOG_FILE | tail -2 | head -1 | awk '{print $3+$5}')

# 获取IO wait
IO_WAIT=$(sar -u -s $(date -d '5 min ago' +%H:%M:%S) -e $(date +%H:%M:%S) -f $LOG_FILE | tail -2 | head -1 | awk '{print $6}')

if (( $(echo "$CPU_USAGE > $THRESHOLD_CPU" | bc -l) )); then
    echo "ALERT: CPU usage ${CPU_USAGE}% on $(hostname) at $(date)"
    # 触发atop快照
    atop -b 1 -e 5 -r /var/log/atop/atop_$(date +%Y%m%d) > /tmp/atop_snapshot.txt
    # 发送告警...
fi

这种方案在硬件性能测评和服务器安全加固场景下也很实用，可以自动捕获异常时段的完整系统快照。

系统性能调优建议

基于监控数据的常见调优方向：

• CPU密集型：iowait高说明磁盘拖累CPU，优先优化IO；user高需要定位进程代码逻辑
• 内存不足：kbcached持续下降且kbswpfree减少时，考虑增加物理内存或调整vm.swappiness
• 磁盘IO瓶颈：%util持续100%时，使用deadline或noop调度器，或将随机IO转向SSD
• 网络延迟：rxerr/s或txerr/s不为零时检查网卡双工模式和MTU配置

在IDC数据中心的算力资源规划中，atop和sar的历史数据是容量评估的核心依据。通过分析30天以上的sar数据趋势，可以预测CPU、内存、IO的增长曲线，为硬件采购和扩容提供数据支撑。