ストレステスト

提供: ArchWiki
2023年5月31日 (水) 13:38時点におけるAshMyzk (トーク | 投稿記録)による版 ("エラーを発見する" を追加)
ナビゲーションに移動 検索に移動

関連記事

ストレステストとは、コンピュータ上で様々なワークロードを実行することでコンピュータの安定性を評価することです。オーバークロックされたハードウェアや電圧を落としたハードウェアの安定性を確実にチェックし、システムの熱的挙動 (例: 最大温度、スロットリング、ノイズレベル) を監視するためによく行われます。システムの様々な部分 (CPU、GPU、RAM、ストレージなど) を異なるタイプのワークロードを使ってストレステストするためのプログラムがいくつか存在します。

ストレステストのタスク

以下の表では、テストの種類と全体的なワークロードの大きさに基づいて、いくつかのストレステストソフトウェアをリストアップしています。多くのユースケースにおける安定性を検証するために、複数の負荷を混ぜてストレステストを行うことが重要です。

警告: この先に進む前に、システムの温度を監視する何らかの手段を確保しておくことが強く推奨されます。センサー を参照してください。
ワークロード テストされるハードウェア1 タスク 説明
Light2
CPU、ストレージ パッチのアップデート OpenWRT プロジェクトの数百ものカーネルパッチを更新するカスタムスクリプト。#OpenWRT のパッチ更新 を参照。
CPU、ストレージ ディスクイメージを書き込む。 #イメージファイルへの書き込み を参照。
RAM メモリに負荷をかける #MemTest86+ を参照。
Realistic3
CPU、RAM、ストレージ コンパイル 並列コンパイルは CPU のストレステストを行うのに良い方法です。#GCC を参照。
CPU、RAM 動画エンコード ffmpeg、x264、handbrake-cli などは、動画エンコードを行うために使用できます。#動画エンコード を参照。
CPU、RAM 暗号通貨マイニング xmrig - xmrig --stress は (CPU のモデルに基づいて) 異なる暗号通貨マイニングアルゴリズムを使用し、可能な限り最も高い負荷を掛けます。安定性と温度をテストするのに良い方法です。
GPU 3D レンダリング unigine-heavenAUR はループで実行される GPU ベンチマークです。これは、GPU をストレステストするのに良い方法です。ベンチマーク#グラフィックス を参照。
Synthetic4 CPU、RAM、ストレージ 合成ストレステスト stress は、CPU、メモリ、I/O、そしてディスクのシンプルなワークロードジェネレータです。C で実装されています。#stress を参照。
CPU、RAM 素数計算 mprime-binAUR は大きな整数を因数分解します。CPU とメモリに負荷を掛けるのに良い方法です。#MPrime を参照。
CPU 代数計算 linpackAUR - Linpack は BLAS (Basic Linear Algebra Subprograms) ライブラリを使用してベクトルと行列の基本的な演算を行います。CPU に負荷を掛けて安定性をテストするのに良い方法です。#Linpack を参照。
CPU 円周率の計算 systesterAUR Systester は、小数点以下 128,000,000 桁まで円周率を計算できるマルチスレッドのソフトウェアです。システムの安定性をチェックする機能が組み込まれています。#Systester を参照。
RAM メモリに負荷をかける stressapptestAUR はメモリインターフェイステストです。
  • 1 主なテスト対象。事実上、すべてのテストには CPU と RAM も含まれます。
  • 2 Light テストでは、(電力/熱が制限されるという点で) コンポーネントにあまり負荷をかけません。これらのテストは、特に低電圧なシステムでの低い電力レベル (P ステート) におけるハードウェアの挙動をテストするのに役立ちます。
  • 3 Realistic テストは、現実世界におけるワークロードに基づいています。
  • 4 Synthetic テストは、ハードウェアに可能な限りに大きな負荷をかけるように明示的に設計されており、現実世界におけるワークロードを代表するようなものではない場合があります。
ヒント: システムの安定性を確かなものにするには、。 To ensure the stability of a system, it is recommended to run such tests for a long period of time, from a few hours to a few days, in different temperature conditions. If the room temperature can for example vary significantly between winter and summer time, this is something to be considered.

OpenWRT のパッチ更新

A good stability test of a low load workload is to run though updating the patch sets in the OpenWRT project. Follow these steps.

ノート: Several dependencies including git and curl are needed, most others should be provided by the dependencies of the base-devel meta package. To be safe, users can always install the metapackage openwrt-develAUR.
git clone --depth 1 git@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 5.15

stress

stress performs a loop that calculates the square root of a random number in order to stress the CPU. It can run simultaneously several workers to load all the cores of a CPU for example. It can also generate memory, I/O or disk workload depending on the parameters passed. The FAQ provides examples and explanations.

To spawn 4 workers working on calculating a square root, use the command: 

$ stress --cpu 4

stress++

stress++AUR is a lightweight stress-testing program written by CodeLog that stimulates the processor by computing the Ackermann function.

MPrime

MPrime (also known as Prime95 in its Windows and MacOS implementation) is recognised universally as one defacto measure of system stability. MPrime under torture test mode will perform a series of very CPU intensive calculations and compare the values it gets to known good values.

The Linux implementation is called mprimeAUR.

To run mprime, simply open a shell and type "mprime": 

$ mprime
ノート: If using CPU frequency scaling, sometimes users need to manually set the processor to run with its highest multiplier because mprime uses a nice value that does not always trip the step-up in multiplier.

When the software loads, simply answer 'N' to the first question to begin the torture testing: 

Main Menu

1.  Test/Primenet
2.  Test/Worker threads
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/Preferences
15.  Options/Torture Test
16.  Options/Benchmark
17.  Help/About
18.  Help/About PrimeNet Server

There are several options for the torture test (menu option 15).

  • Small FFTs (option 1) to stress the CPU
  • In-place large FFTs (option 2) to test the CPU and memory controller
  • Blend (option 3) is the default and constitutes a hybrid mode which stresses the CPU and RAM.

Errors will be reported should they occur both to stdout and to ~/results.txt for review later. Many do not consider a system as 'stable' unless it can run the Large FFTs for a 24 hour period.

Example ~/results.txt; note that the two runs from 26-June indicate a hardware failure. In this case, due to insufficient vcore to the CPU: 

[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!
...
ノート: Users suspecting bad memory or memory controllers should try the blend test first as the small FFT test uses very little memory.

Linpack

linpackAUR makes use of the BLAS (Basic Linear Algebra Subprograms) libraries for performing basic vector and matrix operations. It is an excellent way to stress CPUs for stability (only Intel CPUs are supported). After installation, users should copy /usr/share/linpack/linpack.conf to ~/.config/linpack.conf and adjust it according to the amount of memory on the system.

Systester

SystesterAUR (aka SuperPi for Windows) is available in both CLI and GUI version. It tests system stability by calculating up to 128 millions of Pi digits and includes error checking. Note that one can select from two different calculation algorithms: Quadratic Convergence of Borwein and Gauss-Legendre. The latter being the same method that the popular SuperPi for Windows uses.

A CLI example using 8 threads is given: 

$ systester-cli -gausslg 64M -threads 8

Intel Processor Diagnostic Tool

The Intel Processor Diagnostic Tool is a tool that verifies the functionality of an Intel Microprocessor by stress testing the CPU. A Fedora Linux LiveUSB ISO images are available. The LiveUSB image allows you to stress test your machine without using your main operating system; such method might be useful in extreme cases especially when dealing with cold reboots/crashes.

Burn the image to a USB stick by using dd or Gnome Disks and then boot the Live CD. Once booted, open the terminal and type the following command to install Intel Processor Diagnostic Tool for 64-bit machines: 

$ install64

Once it is installed, you can run the Diagnostic Tool by clicking on the IPDT Icon that is located on the desktop.

MemTest86+

Use MemTest86 (proprietary) or Memtest86+ (GPL) to test your memory (RAM).

ヒント:
  • A reliable source of the version history is the History of MemTest86 section in memtest86.com, in particular the section "2002 - 2004" and following. Notice the proprietary MemTest86 from version 5 through 7 claims to support both BIOS and UEFI, but they simply bundle old and new versions.
  • Allowing tests to run for at least 10 cycles without errors is usually sufficient.

イメージファイルへの書き込み

A good stability test under a low load workload is using dd to format an image. This can be a physical disk or a loop mounted image. The script below uses mounted image and cycles through each core one-by-one. Note that you should adjust the variables in the top of script to match your system. By default the script will run the command just once per core. It can be easily customised to run on known-weak cores rather than scanning all core 0 through n by altering the for loop. Run the script as 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

Parallel compilation using GCC (or other compilers) will generate a heavy load on the CPU and memory. To avoid I/O bottlenecking, compile on a SSD or in a tmpfs.

The example below will compile the Linux kernel. 

pacman -Syu asp
asp export linux
cd linux
makepkg -sf MAKEFLAGS="-j$(nproc)"

動画エンコード

Most video encoders are highly parallel and are designed to use most of a CPU's capabilities. The example below will encode noise using x265, and discard the result. This will heavily load the 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

CPU とメモリに負担をかけるプログラム

Mprime (Windows と MacOS における Prime95)

Prime95 はシステムの安定性を計測するときに使われる標準的なプログラムです。耐久テストモードで Mprime を実行すると CPU の負担が著しい計算を行ってから値が正しいかどうか比較します。

Linux 版の Prime95 は mprimeAUR と呼ばれ AUR からインストールできます。

警告: 計算を実行する前に、CPU 温度を監視する手段を用意することを強く推奨します。Lm sensors などのパッケージで監視できます。

mprime を実行するにはシェルを開いて "mprime" と入力します: 

$ mprime
ノート: cpufrequtils などの CPU 周波数スケーリングを使用する場合、mprime は nice 値を使用するため最大周波数で動作するように手動でプロセッサを設定する必要があります。

ソフトウェアがロードされたら、最初の質問に 'N' と答えると耐久テストが始まります: 

Main Menu

1.  Test/Primenet
2.  Test/Worker threads
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/Preferences
15.  Options/Torture Test
16.  Options/Benchmark
17.  Help/About
18.  Help/About PrimeNet Server

耐久テストには複数のオプションが存在します (メニューのオプション15)。

  • CPU に負担をかけるには Small FFTs (オプション1) を選択。
  • CPU とメモリコントローラをテストするには In-place large FFTs (オプション2) を選択。
  • Blend (オプション3) はデフォルトで CPU とメモリに負担をかけるハイブリッドモードです。

エラーは標準出力と ~/results.txt に吐き出されます。Large FFTs を24時間実行できなければシステムが安定しているとは言えません。

~/results.txt は以下のように出力されます。以下の例では CPU の vcore 電圧が不足しているために2回エラーが発生しています: 

[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!
...
ノート: small FFT テストはメモリをほとんど使用しないためメモリに不良がないかどうか確認したいときは blend テストを実行してください。

Linpack

linpackAUR は BLAS (Basic Linear Algebra Subprograms) ライブラリを使用して基本的なベクター・行列演算を行います。CPU に負担をかけて安定性を調べることができます (Intel の CPU だけがサポートされています)。インストール後、/usr/share/linpack/linpack.conf を ~/.config/linpack.conf にコピーしてメモリ容量にあわせて設定を行ってください。

Systester (Windows の SuperPi)

AUR の SystesterAUR は cli と gui の両方が使えます。円周率を計算してエラーチェックを行いシステムの安定性をテストします。2つの異なる計算アルゴリズムを選択できます: Quadratic Convergence of Borwein と Gauss-Legendre です。後者は Windows の SuperPi が使っている方法と同じです。

8スレッドで動作させるコマンドは以下のようになります: 

$ systester-cli -gausslg 64M -threads 8

Intel Processor Diagnostic Tool

Intel Processor Diagnostic Tool は CPU の耐久試験を行って Intel のマイクロプロセッサの機能を確認するツールです。Fedora Linux の LiveUSB ISO イメージが存在しています。LiveUSB イメージを使うことでメインのオペレーティングシステムを使わずに耐久テストを行うことができます。

dd や Gnome Disks を使って USB スティックにイメージを書き込んで起動してください。起動したら、ターミナルを開いて以下のコマンドを実行することで64ビットマシン用の Intel Processor Diagnostic Tool をインストールします: 

$ install64

インストールしたら、デスクトップ上に表示された IPDT nおアイコンをクリックすることで診断ツールを起動できます。

エラーを発見する

#MPrime や #Linpack といった一部のストレステストアプリケーションには、結果の不一致によるエラーを発見するための一貫性チェックが組み込まれています。ハードウェアの不安定性を測定するためのより一般的でよりシンプルな方法は、カーネル自体に存在します。それを使用するには、以下のように単にクラッシュに関する journal をフィルターしてください: 

# journalctl -k --grep=mce

複数コアのチップは、どの物理/論理コアがエラーを吐いたのかに関する情報も提供します。これは、ユーザがコア単位で設定を最適化している場合に重要である場合があります。

カーネルはストレステストアプリケーションの実行中に (計算が終わってエラーを報告する前に) これらのエラーを投げる可能性があるため、安定性を評価するための非常に高感度な手法を提供しています。Ryzen 5900X の以下エラーについて考えてみましょう: 

mce: [Hardware Error]: Machine check events logged
mce: [Hardware Error]: CPU 21: Machine Check: 0 Bank 5: baa0000000030150
mce: [Hardware Error]: TSC 0 MISC d012000100000000 SYND 4d000002 IPID 500b000000000
mce: [Hardware Error]: PROCESSOR 2:a20f10 TIME 1625265814 SOCKET 0 APIC 4 microcode a201016

このチップは 12 個の物理コアを搭載しています。この場合、CPU 21 は物理コア 10 まで遡ることができます。hwloc の lstopo を使ってハードウェアトポロジを表示してみます。 

Core 0 = CPU 0 + CPU 1
Core 1 = CPU 2 + CPU 3
Core 2 = CPU 4 + CPU 5
Core 3 = CPU 6 + CPU 7
Core 4 = CPU 8 + CPU 9
Core 5 = CPU 10 + CPU 11
Core 6 = CPU 12 + CPU 13
Core 7 = CPU 14 + CPU 15
Core 8 = CPU 16 + CPU 17
Core 9 = CPU 18 + CPU 19
Core 10 = CPU 20 + CPU 21
Core 11 = CPU 22 + CPU 23
ノート: ナンバリングは CPU のモデルやベンダごとに異なっていますが、一般に、コアと CPU の番号は 1 ではなく 0 から始まります。
「https://wiki.archlinux.jp/index.php?title=ストレステスト&oldid=31945」から取得