4. 压力测试方法论：CPU、内存、IO与网络

各位同学，咱们今天聊点硬核的——压力测试。说白了，就是给机顶盒系统「上强度」。你想想看，用户买回去的盒子，可能一边看4K视频，一边后台下载更新，还连着蓝牙手柄打游戏。这种场景下系统稳不稳？不测怎么知道。

我个人习惯，压力测试不是瞎跑工具。你得有章法。先测什么？后测什么？每个工具看什么指标？这些心里要有数。今天我就把这四板斧——CPU、内存、IO、网络，挨个给你们拆开讲透。

4.1 CPU压力测试：用stress工具把核心跑满

CPU压力测试，目的很简单：让所有核心满载运行，看系统会不会崩，看温度会不会爆表，看调度器会不会抽风。

我最常用的工具是stress。它轻量、直接，没有花里胡哨的东西。安装也简单：

# 在机顶盒上安装 stress
apt-get install stress
# 或者编译安装，源码也就几百K

跑起来更简单。比如我要压满4个核心，持续60秒：

stress --cpu 4 --timeout 60

嗯，这里要注意。机顶盒的CPU通常不是桌面级的。我遇到过一款海思芯片的盒子，跑stress --cpu 8直接过热关机。后来发现它只有4个物理核心，超线程都没开。你压8个线程，反而让系统频繁上下文切换，得不偿失。

避坑指南： 我曾经在项目里犯过这个错——用stress --cpu $(nproc)自动检测核心数。结果某款盒子报告了8核，实际上是4核+4个低功耗小核。压力一上来，小核直接罢工，系统日志里全是「thermal throttling」。后来我改成手动指定核心数，问题解决。

除了stress，我偶尔也用stress-ng。它功能更丰富，可以指定CPU计算方式：

# 用矩阵运算压CPU，更贴近实际场景
stress-ng --matrix 4 --timeout 60s

为什么推荐矩阵运算？因为机顶盒的GPU虽然强，但很多解码任务还是靠CPU做矩阵运算。你想想看，H.265解码、图像缩放、色彩空间转换，哪个不是矩阵？用--matrix压出来的结果，比纯整数运算更有参考价值。

我的小技巧： 跑CPU压力时，同时开一个top或htop观察。重点关注三个指标：
1. 每个核心的使用率是否均匀（不均匀说明调度有问题）
2. 温度是否超过85°C（超过就要考虑散热）
3. 系统负载（load average）是否持续攀升（攀升说明有瓶颈）

4.2 内存压力测试：memtester让内存原形毕露

内存问题，是机顶盒最隐蔽的坑。我见过太多案例——平时用着没事，一跑4K视频就花屏、重启。查到最后，全是内存颗粒的锅。

memtester是我包里常备的工具。它通过反复读写内存，检测位翻转、地址线短路等问题。用法很直接：

# 测试256MB内存，循环5次
memtester 256M 5

但这里有个关键点：机顶盒的内存通常不大，2GB、4GB很常见。你测试时不能把全部内存都占了，否则系统会OOM（内存耗尽）。我一般留出200MB给系统和后台服务。

比如盒子有2GB内存，我会这样测：

# 测试1.8GB，留200MB给系统
memtester 1800M 3
重要： memtester的测试项很多，我重点关注这几个：
  • Stuck Address：地址线是否短路。这个不过，直接换内存颗粒。
  • Random Value：随机读写一致性。这个不过，说明内存有软错误。
  • Compare XOR：异或校验。这个不过，可能是时序问题。

我曾经在一个项目里，连续跑了12小时memtester，第8小时才报错。你想想看，这种间歇性故障，普通功能测试根本发现不了。所以我的建议是：内存压力测试，至少跑4小时起步。别心疼时间，总比用户退货强。

4.3 IO压力测试：dd和fio，一个粗一个细

机顶盒的IO，主要是eMMC或NAND Flash。这类存储有个特点：读写速度不对称，而且有写放大效应。压力测试要模拟真实场景——比如一边录播、一边回放、一边下载。

先说dd，它简单粗暴。 适合快速验证IO能不能跑满：

# 写测试：写入1GB文件，观察速度
dd if=/dev/zero of=/tmp/test.img bs=1M count=1024 conv=fdatasync

# 读测试：读取1GB文件，观察速度
dd if=/tmp/test.img of=/dev/null bs=1M count=1024

注意那个conv=fdatasync。不加这个参数，dd可能只写到缓存就返回了，测出来速度虚高。我见过有人拿这个数据交差，结果实际写入慢得像蜗牛。

再说fio，它是专业选手。 可以模拟各种IO模式：顺序、随机、混合读写。我常用的配置：

# 随机4K读写，模拟数据库或日志场景
fio --name=randrw --rw=randrw --bs=4k --size=512M --numjobs=4 \
    --runtime=60 --time_based --group_reporting

这个命令什么意思？--rw=randrw是随机混合读写，--bs=4k是4K块大小，--numjobs=4是4个并发任务。机顶盒的eMMC，随机4K性能通常只有几十MB/s。如果测出来低于10MB/s，那就要警惕了——可能是eMMC磨损严重，或者文件系统碎片太多。

我的经验： 跑fio时，重点关注latency（延迟）指标。机顶盒对IO延迟很敏感。比如播放视频时，如果某个IO请求延迟超过500ms，画面就会卡顿。我一般要求99%的IO延迟在100ms以内。

4.4 网络压力测试：iperf3测出真实带宽

网络问题，是机顶盒用户投诉的重灾区。用户说「网速慢」，但到底是Wi-Fi信号差、路由器瓶颈、还是盒子网卡不行？iperf3可以帮你定位。

用法分两端：服务端和客户端。

服务端（在机顶盒上跑）：

iperf3 -s -p 5201

客户端（在PC或另一台设备上跑）：

iperf3 -c 192.168.1.100 -p 5201 -t 30 -P 4

这里-t 30是测试30秒，-P 4是4个并发流。为什么要并发？因为很多机顶盒的TCP协议栈优化不好，单流跑不满带宽。我遇到过一款盒子，单流只能跑200Mbps，但4个并发流能跑到800Mbps。你想想看，如果只测单流，是不是就误判了？

避坑指南： 我曾经在项目里用iperf3测Wi-Fi，结果怎么都跑不满。折腾了半天，发现是机顶盒的Wi-Fi天线没接好。所以测网络前，先确认物理连接没问题。另外，iperf3默认用TCP，但机顶盒很多场景是UDP（比如视频流）。建议也测一下UDP：
iperf3 -c 192.168.1.100 -u -b 100M -t 30
这个命令会以100Mbps的速率发UDP包，看丢包率和抖动。

网络压力测试，我一般跑三轮：

  1. 有线千兆：验证网卡和驱动没问题，目标950Mbps以上。
  2. Wi-Fi 5G：验证无线性能，目标300Mbps以上（视环境而定）。
  3. Wi-Fi 2.4G：验证抗干扰能力，目标50Mbps以上。

如果哪一轮没达标，就逐段排查——网线、路由器、信道干扰、盒子网卡驱动。别一上来就怪盒子，很多时候是环境问题。

4.5 综合压力测试：把四板斧组合起来

单个工具测完了，还得组合起来。因为真实场景下，CPU、内存、IO、网络是同时工作的。我习惯写一个脚本，同时启动四个压力：

#!/bin/sh
# 综合压力测试脚本

# CPU压力：4核矩阵运算
stress-ng --matrix 4 --timeout 300s &

# 内存压力：1.8GB测试
memtester 1800M 1 &

# IO压力：随机4K读写
fio --name=stress --rw=randrw --bs=4k --size=512M --runtime=300 &

# 网络压力：UDP 100Mbps
iperf3 -c 192.168.1.100 -u -b 100M -t 300 &

# 等待所有后台任务完成
wait
echo "综合压力测试完成"

这个脚本跑起来，机顶盒基本就是满负荷运转了。我一般让它跑4小时，同时用dmesg监控内核日志，用top记录资源使用。如果4小时内没有报错、没有重启、没有卡顿，那这个系统基本就稳了。

总结一下：
  • CPU压力：stress/stress-ng，跑满核心，盯温度和负载。
  • 内存压力：memtester，跑4小时以上，盯地址线和随机读写。
  • IO压力：dd粗测，fio精测，盯延迟和随机性能。
  • 网络压力：iperf3，TCP和UDP都测，盯带宽和丢包。
  • 综合压力：组合起来跑，模拟真实场景。

好了，这一章的内容就这些。工具都不难，难的是你怎么理解结果、怎么定位问题。下一章我们聊聊如何分析压力测试的日志和指标，到时候我会分享一些实战中遇到的奇葩案例。嗯，保证让你大开眼界。

← 上一章 📖 返回目录 下一章 →