2. 性能数据采集基础：常用性能监控工具、数据采集频率与粒度选择、数据采集的常见陷阱
性能数据采集是压力测试特征工程的起点。采集到的数据质量直接决定了后续特征提取、异常检测和瓶颈分析的有效性。本节将系统讲解 Linux 环境下最核心的四个性能监控工具、采集频率与粒度的选择原则，以及数据采集过程中最容易踩中的陷阱。
2.1 常用性能监控工具
在 Linux 服务器端性能监控中，top、vmstat、iostat 和 sar 是最基础且最常用的四个命令行工具。它们分别从不同维度提供系统资源的使用快照或连续记录。
| 工具 | 主要监控维度 | 典型输出频率 | 适用场景 |
|---|---|---|---|
| top | 进程级 CPU、内存、负载 | 实时刷新（默认 3 秒） | 快速定位高消耗进程 |
| vmstat | 系统级 CPU、内存、IO、进程、上下文切换 | 可指定间隔（如 1 秒） | 宏观系统瓶颈判断 |
| iostat | 磁盘 IO 吞吐量、IOPS、响应时间、队列长度 | 可指定间隔（如 1 秒） | 磁盘性能瓶颈分析 |
| sar | 历史与实时系统活动报告（CPU、内存、IO、网络） | 系统级周期性采集（如 10 分钟） | 长期趋势分析与历史回溯 |
2.1.1 top：进程级资源监控
top 是最直观的实时监控工具，默认按 CPU 使用率降序排列进程。在压力测试中，重点关注以下字段：
- %CPU：进程 CPU 使用率，多核环境下可能超过 100%。
- %MEM：进程物理内存使用率。
- RES：进程常驻物理内存大小（KB/MB）。
- S：进程状态（R 运行、S 睡眠、D 不可中断睡眠）。
top -b -n 1 以批处理模式输出单次快照，便于脚本采集；使用 top -p PID1,PID2 只监控特定进程。
2.1.2 vmstat：系统级宏观快照
vmstat 提供系统整体的 CPU、内存、IO 和进程状态。典型用法：
# 每 2 秒采集一次，共采集 10 次
vmstat 2 10输出关键列解读：
| 类别 | 列名 | 含义 | 关注阈值 |
|---|---|---|---|
| 进程 | r | 运行队列中的进程数 | > CPU 核数 × 2 时表示 CPU 饱和 |
| 进程 | b | 不可中断睡眠进程数（等待 IO） | 持续 > 0 表示 IO 瓶颈 |
| 内存 | swpd | 交换分区使用量（KB） | 持续增长表示内存不足 |
| CPU | us | 用户态 CPU 时间占比 | > 70% 表示用户进程繁忙 |
| CPU | sy | 系统态 CPU 时间占比 | > 30% 表示系统调用频繁 |
| CPU | wa | 等待 IO 的 CPU 时间占比 | > 20% 表示磁盘 IO 瓶颈 |
2.1.3 iostat：磁盘 IO 深度分析
iostat 专门用于分析磁盘子系统的性能。在压力测试中，磁盘 IO 往往是容易被忽视的瓶颈。典型用法：
# 每 1 秒采集一次磁盘 IO 统计
iostat -x 1核心指标：
- r/s、w/s：每秒读/写请求数（IOPS）。
- rkB/s、wkB/s：每秒读/写数据量（吞吐量）。
- await：IO 请求的平均等待时间（毫秒），包括排队和服务时间。
- svctm：IO 请求的平均服务时间（毫秒）。
- %util：磁盘繁忙百分比。接近 100% 表示磁盘饱和。
2.1.4 sar：系统活动历史记录
sar 是 sysstat 包的核心工具，能够采集和报告系统长期的活动数据。在压力测试中，sar 的价值在于：
- 历史回溯：测试结束后复盘系统行为。
- 趋势分析：观察资源使用率随时间的变化曲线。
- 多维度覆盖：CPU、内存、磁盘、网络、上下文切换等。
常用命令示例：
# 实时采集 CPU 使用率，每 1 秒一次
sar -u 1 10
# 查看历史内存使用情况
sar -r -f /var/log/sysstat/saDD
# 查看历史网络流量
sar -n DEV 1 5sar -o /tmp/sar_output 1 0，将数据持续写入二进制文件，测试结束后使用 sar -f 读取分析。
2.2 数据采集频率与粒度选择
采集频率（采样间隔）和粒度（聚合窗口）的选择直接影响数据质量和分析效率。选择不当会导致数据噪声过大、存储爆炸或遗漏关键瞬态事件。
2.2.1 采集频率选择原则
| 场景 | 推荐频率 | 说明 |
|---|---|---|
| CPU 使用率 | 1 秒 | CPU 变化快，1 秒可捕捉瞬时尖峰 |
| 内存使用量 | 1 ~ 5 秒 | 内存变化相对平缓，可适当降低频率 |
| 磁盘 IO | 1 秒 | IO 突发性强，高频率才能捕捉队列堆积 |
| 网络流量 | 1 ~ 5 秒 | 取决于应用协议，短连接场景建议 1 秒 |
| 进程级指标 | 5 ~ 10 秒 | 进程状态变化较慢，过高频率增加开销 |
| 长时间稳定性测试 | 10 ~ 60 秒 | 关注趋势而非瞬态，降低存储压力 |
2.2.2 粒度选择：原始数据 vs 聚合数据
采集到的原始数据通常需要聚合后才能用于特征工程。常见的聚合粒度包括：
- 原始粒度（1 秒）：保留全部细节，适合分析瞬态尖峰和毛刺。
- 10 秒聚合：计算平均值、最大值、最小值，适合观察短期趋势。
- 1 分钟聚合：计算平均值和百分位数（P50、P90、P99），适合长时间测试的趋势分析。
- 5 分钟聚合：用于稳定性测试的宏观趋势，丢弃大部分噪声。
2.3 数据采集的常见陷阱
即使使用了正确的工具和频率，数据采集过程中仍然存在多个容易忽视的陷阱。以下是最常见的六类问题。
2.3.1 陷阱一：采集工具本身的开销
高频率采集（如 0.1 秒间隔）会消耗额外的 CPU 和 IO 资源，干扰被测系统的行为。尤其是在低配置服务器上，采集工具可能成为瓶颈。
- 表现：采集到的 CPU 使用率中包含采集进程自身的消耗。
- 对策：采集频率不低于 1 秒；使用
sar等低开销工具；避免在测试机上同时运行多个采集工具。
2.3.2 陷阱二：采样时间点对齐偏差
多个工具同时采集时，如果启动时间不同步，会导致数据点无法对齐，影响多维度关联分析。
- 表现：CPU 尖峰和 IO 尖峰在时间轴上错位。
- 对策：使用统一的采集调度脚本，所有工具在同一秒启动；采集数据时记录时间戳（精确到毫秒）。
2.3.3 陷阱三：平均值掩盖尖峰
长时间窗口的平均值会平滑掉瞬态尖峰，而这些尖峰往往是性能瓶颈的关键信号。
- 表现：1 分钟平均 CPU 只有 40%，但实际存在多次 100% 的尖峰。
- 对策：同时采集最大值和 P99 百分位数；保留原始 1 秒数据用于尖峰分析。
2.3.4 陷阱四：磁盘 %util 的误解
如前所述，%util 达到 100% 并不一定意味着磁盘饱和，尤其是对于 NVMe SSD 等支持多队列的设备。
- 表现：%util 100% 但 IOPS 仍在增长。
- 对策：结合 avgqu-sz（平均队列长度）和 await（平均等待时间）综合判断。
2.3.5 陷阱五：网络流量统计的遗漏
默认的 sar -n DEV 只统计物理网卡，容易遗漏虚拟网卡（如 docker0、veth）或 bond 接口的流量。
- 表现：网络流量数据远低于实际值。
- 对策：明确指定需要监控的接口；在容器化环境中同时监控宿主机和容器网络命名空间。
2.3.6 陷阱六：数据存储与命名混乱
多次测试的数据文件如果没有规范的命名和目录结构，后期复盘时难以定位。
- 表现：多个测试的 sar 输出文件混在一起，无法区分。
- 对策：建立统一的命名规范，例如：
testcase_2025-01-15_14-30-00_sar.dat。
2.4 数据采集架构总览
下图展示了压力测试中性能数据采集的整体架构，涵盖工具选择、采集频率、数据存储与特征工程的关系。
2.5 数据采集流程标准化
为避免上述陷阱，建议在每次压力测试前执行标准化的数据采集流程：
- 环境准备：确认 sysstat 包已安装，
sar后台采集已启动。 - 工具验证：执行一次
vmstat 1 3和iostat -x 1 3，确认输出正常。 - 时间同步：所有采集节点使用 NTP 同步时间。
- 启动采集：使用统一脚本同时启动 top、vmstat、iostat、sar 采集。
- 数据标记：在测试开始和结束时，在数据文件中插入标记行（如
# TEST_START）。 - 数据归档：按规范命名并压缩存储原始数据。
- 数据校验：快速检查数据完整性，确认无缺失时间窗口。
#!/bin/bash
# 采集启动脚本
TEST_NAME=$1
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
OUTPUT_DIR=/data/perf/${TEST_NAME}_${TIMESTAMP}
mkdir -p $OUTPUT_DIR
# 启动 sar 后台采集（1秒间隔）
sar -o $OUTPUT_DIR/sar.dat 1 0 &
# 启动 vmstat 采集（1秒间隔）
vmstat 1 > $OUTPUT_DIR/vmstat.log &
# 启动 iostat 采集（1秒间隔）
iostat -x 1 > $OUTPUT_DIR/iostat.log &
# 记录测试开始标记
echo "# TEST_START: $TIMESTAMP" >> $OUTPUT_DIR/vmstat.log
echo "# TEST_START: $TIMESTAMP" >> $OUTPUT_DIR/iostat.log
# 等待测试结束
wait
# 记录测试结束标记
echo "# TEST_END: $(date +%Y%m%d_%H%M%S)" >> $OUTPUT_DIR/vmstat.log通过标准化的采集流程和工具选择，能够为后续的特征工程提供高质量、可追溯、可对齐的原始性能数据。这是整个压力测试特征工程优化方法实操的基础保障。