压力测试

压力测试是指在计算机上运行各种工作负载以评估其稳定性的过程。它通常用于可靠地检查超频/降压硬件的稳定性，并监控系统的散热表现（如最高温度、降频、噪音水平）。目前有多种程序可用于对 CPU、GPU、内存和存储等系统部件进行压力测试，并使用不同类型的工作负载。

压力测试任务

下表根据测试类型和工作负载的总体强度列出了一些压力测试软件。重要的是通过混合负载进行压力测试，以验证在多种使用场景下的稳定性。

警告在进行测试前，强烈建议用户有手段监控系统温度。请参阅传感器。

工作负载	测试硬件¹	任务	描述
轻度²
	CPU, 存储	更新补丁	自定义脚本，刷新 OpenWRT 项目中的数百个内核补丁。请参阅 #更新 OpenWRT 补丁。
	CPU, 存储	写入磁盘镜像	请参阅 #写入镜像文件。
	内存	内存压力测试	请参阅 #Memtest86+。
现实场景³
	CPU, 内存, 存储	编译	并行编译是测试 CPU 的好方法。请参阅 #GCC。
	CPU, 内存	视频编码	ffmpeg, x264, handbrake-cli 等可用于编码视频。请参阅 #视频编码。
	CPU, GPU, 内存	加密货币挖矿	xmrig 是一款 CPU/GPU 挖矿软件，使用不同的加密货币挖掘算法在 GPU 上生成负载，用于稳定性和温度测试。请参阅 Benchmarking#xmrig。
	GPU	3D 渲染	unigine-heaven^AUR 是一个循环运行的 GPU 基准测试工具。它是 GPU 压力测试的不错选择。请参阅 Benchmarking#Unigine Engine。
合成测试⁴	CPU, 内存, 存储	合成压力测试	stress 是一个用 C 语言实现的简单的 CPU、内存、I/O 和磁盘负载生成器。请参阅 #stress。
	CPU, 内存	素数计算	mprime^AUR 通过对大数进行因式分解，是测试 CPU 和内存极好的方法。请参阅 #MPrime。
	CPU	代数计算	linpack^AUR - Linpack 利用 BLAS（基础线性代数子程序）库来执行基础向量和矩阵运算，是测试 CPU 稳定性的极佳工具。请参阅 #Linpack。
	CPU	圆周率计算	systester^AUR 是一款多线程软件，能够将圆周率推导至 1.28 亿位。它具有内置的系统稳定性检查功能。请参阅 #Systester。
	内存	内存压力测试	stressapptest^AUR 是一种内存接口测试工具。
	CPU	其他	strain^AUR 一个多功能压力测试工具，使用 Rust 编写。

¹ 测试的主要目标，实际上所有测试在一定程度上也会涉及 CPU 和内存。
² 轻度测试不会对组件造成太大压力（指功率/热量限制）。这些测试对于评估硬件在较低功耗级别（P 状态）下的表现依然有用，特别适用于降压系统。
³ 现实场景测试基于真实的工作负载。
⁴ 合成测试专门设计用于尽可能压榨硬件，可能无法代表真实的工作负载。

提示为确保系统稳定性，建议在不同温度环境下长时间运行此类测试，从几小时到几天不等。如果室温在冬夏两季之间差异显著，这也是需要考虑的因素。

更新 OpenWRT 补丁

一种良好的低负载压力测试是运行 OpenWRT 项目中的补丁集更新。请按照以下步骤操作。

注意需要包括 git 和 curl 在内的若干依赖，其余大部分应由 base-devel 元软件包提供。

$ git clone --depth 1 https://github.com/openwrt/openwrt.git
$ cd openwrt
$ mkdir -p staging_dir/host/bin
$ cp /usr/bin/sed ./staging_dir/host/bin
$ curl -Os https://raw.githubusercontent.com/KanjiMonster/maintainer-tools/master/update_kernel.sh
$ chmod +x update_kernel.sh
$ ./update_kernel.sh -v -u 6.6

stress

stress 通过循环计算随机数的平方根来压测 CPU。它可以同时运行多个工作线程，例如加载 CPU 的所有核心。根据传递的参数，它还可以生成内存、I/O 或磁盘负载。常见问题解答提供了示例和解释。

要生成 4 个工作线程来计算平方根，请使用以下命令

$ stress --cpu 4

s-tui

s-tui 是一款基于终端的 CPU 压力测试和监控实用工具。它既能监控 CPU 使用率和温度，也能进行 CPU 压力测试。这是一个一站式工具，通过终端图形界面即可在一个屏幕上查看所有需要的信息。

MPrime

MPrime（在 Windows 和 MacOS 实现中被称为 Prime95）被普遍公认为系统稳定性的事实标准衡量工具。MPrime 在拷机模式（Torture test）下会执行一系列极其消耗 CPU 的计算，并将结果与已知正确值进行比较。

其 Linux 实现名为 mprime^AUR。

运行 mprime 只需打开 shell 并输入 "mprime"

$ mprime

注意如果使用 CPU 频率调节，用户有时需要手动设置处理器以最高倍频运行，因为 mprime 使用的 nice 值并不总是能触发倍频提升。

软件启动后，只需回答“N”开始拷机测试即可。

     Main Menu

 1.  Test/Primenet
 2.  Test/Workers
 3.  Test/Status
 4.  Test/Continue
 5.  Test/Exit
 6.  Advanced/Test
 7.  Advanced/Time
 8.  Advanced/P-1
 9.  Advanced/ECM
10.  Advanced/Manual Communication
11.  Advanced/Unreserve Exponent
12.  Advanced/Quit Gimps
13.  Options/CPU
14.  Options/Resource Limits
15.  Options/Preferences
16.  Options/Torture Test
17.  Options/Benchmark
18.  Help/About
19.  Help/About PrimeNet Server

拷机测试有几种选项（菜单选项 16）。

Smallest FFTs：用于测试 CPU L1/L2 缓存（极高的 CPU 压力）
Small FFTs：用于测试 CPU L1/L2/L3 缓存（最大的 CPU 压力）
Large FFTs：用于测试内存控制器和内存（中等 CPU 压力）
Blend 是默认选项，属于混合模式，同时对 CPU 和内存施压。

“Customize settings (N)”提示符允许您自定义 FFT 大小范围和内存使用等设置。Large 和 Blend 模式的默认设置是使用约 90% 的当前可用内存，并在内存内 FFT 和原位 FFT 之间切换。

如果发生错误，错误信息将报告在标准输出（stdout）以及 ~/results.txt 文件中供稍后查看。许多人认为，除非系统能无错运行 Large FFTs 24 小时，否则不能称为“稳定”。（标准输出更有用，因为它包含了是哪个 worker 产生了错误的信息，因此可以考虑使用 tee 或 script 来保存标准输出。默认情况下，每个核心分配一个 worker，因此可以轻松识别性能较弱的核心。）

~/results.txt 示例；请注意 6 月 26 日的两次运行表明存在硬件故障。在这种情况下，是因为 CPU 的 vcore 电压不足。

[Sun Jun 26 20:10:35 2011]
FATAL ERROR: Rounding was 0.5, expected less than 0.4
Hardware failure detected, consult stress.txt file.
FATAL ERROR: Rounding was 0.5, expected less than 0.4
Hardware failure detected, consult stress.txt file.
[Sat Aug 20 10:50:45 2011]
Self-test 480K passed!
Self-test 480K passed!
[Sat Aug 20 11:06:02 2011]
Self-test 128K passed!
Self-test 128K passed!
[Sat Aug 20 11:22:10 2011]
Self-test 560K passed!
Self-test 560K passed!
...

注意怀疑内存或内存控制器损坏的用户应首先尝试 Blend 或 Large 测试，因为 Small FFT 测试使用的内存很少。

Linpack

linpack^AUR 利用 BLAS 库执行基础向量和矩阵运算。这是测试 CPU 稳定性的绝佳方法（仅支持 Intel CPU）。安装后，用户应将 /usr/share/linpack/linpack.conf 复制到 ~/.config/linpack.conf 并根据系统内存大小进行调整。

Systester

Systester^AUR (即 Windows 下的 SuperPi) 提供 CLI 和 GUI 版本。它通过计算多达 1.28 亿位圆周率来测试系统稳定性，并包含错误检查功能。注意，用户可以选择两种不同的计算算法：Borwein 二次收敛和 Gauss-Legendre。后者与 Windows 下流行的 SuperPi 使用的方法相同。

这里提供了一个使用 8 个线程的 CLI 示例

$ systester-cli -gausslg 64M -threads 8

Memtest86+

使用 MemTest86（专有）或 Memtest86+（GPL）来测试您的内存（RAM）。

GPL 版本可在 Arch Linux 安装镜像上找到。安装方式为：
- EFI 系统安装 memtest86+-efi，
- 或者 BIOS 系统安装 memtest86+。
专有版本不支持 BIOS，通过 memtest86-efi^AUR 安装。
安装后，用户可以更新 GRUB；它会自动检测该包并允许用户直接启动进入。
systemd-boot 用户必须手动配置引导项。

提示

版本历史的可靠来源是 memtest86.com 上的 MemTest86 历史部分，特别是“2002 - 2004”及后续部分。请注意，5 到 7 版本的专有 MemTest86 虽然声称同时支持 BIOS 和 UEFI，但它们仅仅是打包了新旧版本。
让测试运行至少 10 个周期且无错误通常就足够了。

写入镜像文件

低负载下的一种良好的稳定性测试是使用 dd 格式化一个镜像。这可以是物理磁盘或循环挂载的镜像。下面的脚本使用挂载的镜像，并逐个遍历每个核心。请注意，您应该调整脚本顶部的变量以匹配您的系统。默认情况下，该脚本每个核心只运行一次命令。通过修改 for 循环，可以轻松自定义为在已知较弱的核心上运行，而不是扫描从 0 到 n 的所有核心。请以 root 权限运行此脚本。

format-test.sh

#!/bin/bash

# define the path to store the image, recommended to be a tmpfs mounted location to avoid read/writes
img=/scratch/image.img

# define the mount point
mnt=/mnt/loop

# size of time arg to pass to truncate, make sure you select something less than the free memory on the system
# see truncate --help for available options
size=40G

# defaults to 1 less than the number of virtual cores, manually redefine if desired
max=$(($(nproc) - 1))

if [[ ! -f $img ]]; then
  truncate -s $size $img
  mkfs.ext4 $img
  [[ -d $mnt ]] || mkdir -p $mnt
  if ! mountpoint -q $mnt; then
    mount -o loop $img $mnt || exit 1
  fi
fi

for i in $(eval echo "{0..$max}"); do
  echo "using core $i of $max"
  taskset -c "$i" time dd if=/dev/zero of=$mnt/zerofill status=progress
done

umount $mnt
rm $img

GCC

使用 GCC（或其他编译器）进行并行编译会对 CPU 和内存产生沉重负载。为避免 I/O 瓶颈，请在 SSD 或 tmpfs 上进行编译。

一个很好的例子是编译内核：详细说明请参阅内核/Arch 构建系统，在内核/Arch 构建系统#编译处运行 makepkg -sf MAKEFLAGS="-j$(nproc)"。

视频编码

大多数视频编码器高度并行，旨在利用 CPU 的大部分能力。下面的示例将使用 x265 对噪声进行编码，并丢弃结果。这将给 CPU 带来沉重负载。

ffmpeg -y -f rawvideo -video_size 1920x1080 -pixel_format yuv420p -framerate 60 -i /dev/urandom -c:v libx265 -preset placebo -f matroska /dev/null

发现错误

一些压力测试应用如 #MPrime, #Linpack 或 systester 具有内置的一致性检查功能，可以发现因结果不匹配而导致的错误。这比寻找内核错误更灵敏，应优先使用。

一种更通用的衡量硬件不稳定的方法可以在内核本身中找到，即通过硬件错误检测或直接故障。大多数数据传输或计算中的错误不会触发严重到足以被报告为机器检查错误（Machine Check Error）的故障。

使用 journalctl 手动搜索

只需过滤日志以识别机器检查错误

# journalctl -k --grep=mce

使用 rasdaemon

另外，构建 rasdaemon^AUR 并启动附带的服务。Rasdaemon 保存一个 sqlite 错误数据库，可以使用包含的 ras-mc-ctl 二进制文件进行查询。示例：

# ras-mc-ctl --errors
No Memory errors.
No PCIe AER errors.
No ARM processor errors.
No Extlog errors.
No devlink errors.
MCE events:
1 2025-06-23 08:24:48 -0400 error: Corrected error, no action required., CPU 2, bank Load Store Unit (bank=0), mcg mcgstatus=0, mci CECC, mca DC data error type 2. Ext Err Code: 13 Memory Error 'mem-tx: evict, tx: data, level: L1', mcgcap=0x00000107, status=0x9c204000000d0175, addr=0x185dd56627, misc=0xd01a000100000000, walltime=0x68594791, cpu=0x00000002, cpuid=0x00b40f40, apicid=0x00000004, microcode=0x0b404032

追踪错误到具体的 CPU 核心

在优化设置时，了解基于核心的稳定性变得至关重要，这也是许多 BIOS 超频部分使用的上下文。一个物理核心可以包含多个逻辑 CPU。

请考虑 Ryzen 9950X（16 物理核心/32 逻辑 CPU）日志中的以下错误

[Hardware Error]: Corrected error, no action required.
[Hardware Error]: CPU:5 (1a:44:0) MC0_STATUS[-|CE|MiscV|AddrV|-|-|SyndV|CECC|-|-|-]: 0x9c204000000d0175
[Hardware Error]: Error Addr: 0x000000185d960d07
[Hardware Error]: IPID: 0x000000b000000000, Syndrome: 0x0000000b1a173405
[Hardware Error]: Load Store Unit Ext. Error Code: 13
[Hardware Error]: cache level: L1, tx: DATA, mem-tx: EV

逻辑到物理处理单元（PU）的映射可以通过 hwloc 中的 lstopo-no-graphics 获取。

$ lstopo-no-graphics --only PU

PU L#0 (P#0)
PU L#1 (P#10)
PU L#2 (P#1)
PU L#3 (P#11)
PU L#4 (P#2)
PU L#5 (P#12)
PU L#6 (P#3)
PU L#7 (P#13)
PU L#8 (P#4)
PU L#9 (P#14)
PU L#10 (P#5)
PU L#11 (P#15)
PU L#12 (P#6)
PU L#13 (P#16)
PU L#14 (P#7)
PU L#15 (P#17)
PU L#16 (P#8)
PU L#17 (P#18)
PU L#18 (P#9)
PU L#19 (P#19)