「ストレステスト」の版間の差分
(同期) |
細 (→ストレステストのタスク: 修正) |
||
| 51行目: | 51行目: | ||
* <sup>1</sup> 主なテスト対象。事実上、すべてのテストには CPU と RAM も含まれます。 |
* <sup>1</sup> 主なテスト対象。事実上、すべてのテストには CPU と RAM も含まれます。 |
||
| − | * <sup>2</sup> |
+ | * <sup>2</sup> 軽量なテストでは、(電力/熱が制限されるという点で) コンポーネントにあまり負荷をかけません。これらのテストは、特に低電圧なシステムでの低い電力レベル (P ステート) におけるハードウェアの挙動をテストするのに役立ちます。 |
| − | * <sup>3</sup> |
+ | * <sup>3</sup> 現実的なテストは、現実世界におけるワークロードに基づいています。 |
| − | * <sup>4</sup> |
+ | * <sup>4</sup> 人工的なテストは、ハードウェアに可能な限りに大きな負荷をかけるように明示的に設計されており、現実世界におけるワークロードを代表するようなものではない場合があります。 |
{{Tip|システムの安定性を確かなものにするために、様々な温度条件下でストレステストを長い時間 (数時間から数日) 実行することが推奨されます。例えば、室温が冬や夏で大きく異なる場合、これを考慮すべきです。}} |
{{Tip|システムの安定性を確かなものにするために、様々な温度条件下でストレステストを長い時間 (数時間から数日) 実行することが推奨されます。例えば、室温が冬や夏で大きく異なる場合、これを考慮すべきです。}} |
||
2025年6月29日 (日) 16:04時点における版
関連記事
ストレステストとは、コンピュータ上で様々なワークロードを実行することでコンピュータの安定性を評価することです。オーバークロックされたハードウェアや電圧を落としたハードウェアの安定性を確実にチェックし、システムの熱的挙動 (例: 最大温度、スロットリング、ノイズレベル) を監視するためによく行われます。システムの様々な部分 (CPU、GPU、RAM、ストレージなど) を異なるタイプのワークロードを使ってストレステストするためのプログラムがいくつか存在します。
目次
ストレステストのタスク
以下の表では、テストの種類と全体的なワークロードの大きさに基づいて、いくつかのストレステストソフトウェアをリストアップしています。多くのユースケースにおける安定性を検証するために、複数の負荷を混ぜてストレステストを行うことが重要です。
| ワークロード | テストされるハードウェア1 | タスク | 説明 |
|---|---|---|---|
| 軽量2 | |||
| CPU、ストレージ | パッチのアップデート | OpenWRT プロジェクトの数百ものカーネルパッチを更新するカスタムスクリプト。#OpenWRT のパッチ更新 を参照。 | |
| CPU、ストレージ | ディスクイメージを書き込む。 | #イメージファイルへの書き込み を参照。 | |
| RAM | メモリに負荷をかける | #MemTest86+ を参照。 | |
| 現実的3 | |||
| CPU、RAM、ストレージ | コンパイル | 並列コンパイルは CPU のストレステストを行うのに良い方法です。#GCC を参照。 | |
| CPU、RAM | 動画エンコード | ffmpeg、x264、handbrake-cli などは、動画エンコードを行うために使用できます。#動画エンコード を参照。 | |
| CPU、RAM | 暗号通貨マイニング | xmrig - xmrig --stress は (CPU のモデルに基づいて) 異なる暗号通貨マイニングアルゴリズムを使用し、可能な限り最も高い負荷を掛けます。安定性と温度をテストするのに良い方法です。
| |
| GPU | 3D レンダリング | unigine-heavenAUR はループで実行される GPU ベンチマークです。これは、GPU をストレステストするのに良い方法です。ベンチマーク#グラフィックス を参照。 | |
| 人工的4 | CPU、RAM、ストレージ | 合成ストレステスト | stress は、CPU、メモリ、I/O、そしてディスクのシンプルなワークロードジェネレータです。C で実装されています。#stress を参照。 |
| CPU、RAM | 素数計算 | mprimeAUR は大きな整数を因数分解します。CPU とメモリに負荷を掛けるのに良い方法です。#MPrime を参照。 | |
| CPU | 代数計算 | linpackAUR - Linpack は BLAS (Basic Linear Algebra Subprograms) ライブラリを使用してベクトルと行列の基本的な演算を行います。CPU に負荷を掛けて安定性をテストするのに良い方法です。#Linpack を参照。 | |
| CPU | 円周率の計算 | systesterAUR Systester は、小数点以下 128,000,000 桁まで円周率を計算できるマルチスレッドのソフトウェアです。システムの安定性をチェックする機能が組み込まれています。#Systester を参照。 | |
| RAM | メモリに負荷をかける | stressapptestAUR はメモリインターフェイステストです。 | |
| CPU | 様々 | strainAUR 多機能ストレステストユーティリティ。Rust 製。 |
- 1 主なテスト対象。事実上、すべてのテストには CPU と RAM も含まれます。
- 2 軽量なテストでは、(電力/熱が制限されるという点で) コンポーネントにあまり負荷をかけません。これらのテストは、特に低電圧なシステムでの低い電力レベル (P ステート) におけるハードウェアの挙動をテストするのに役立ちます。
- 3 現実的なテストは、現実世界におけるワークロードに基づいています。
- 4 人工的なテストは、ハードウェアに可能な限りに大きな負荷をかけるように明示的に設計されており、現実世界におけるワークロードを代表するようなものではない場合があります。
OpenWRT のパッチ更新
低負荷なワークロードの安定性テストとしては、OpenWRT プロジェクトのパッチセットをアップデートするのが良いでしょう。以下のステップに従ってください。
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、ディスクのワークロードを生成することもできます。FAQ には例や説明があります。
4 つのワーカーを生成して平方根の計算を行うには、以下のコマンドを使ってください:
$ stress --cpu 4
s-tui
s-tui は、ターミナルベースの CPU ストレステスト及び監視ユーティリティです。CPU の使用率と温度を監視でき、CPU に負荷をかけることもできます。ターミナルグラフィカルインターフェイスで、1つの画面で必要な情報をすべて確認できるスイスナイフのようなツールです。
MPrime
MPrime (Windows と MacOS の実装では Prime95 とも) は、システムの安定性の事実上の指標の1つとして広く認知されています。耐久テスト (Torture Test) モードでは、MPrime は CPU に非常に大きな負荷を掛ける一連の計算を行い、得られた値を既知の良い値と比較します。
Linux の実装は mprimeAUR と呼ばれています。
mprime を実行するには、シェルを開き、"mprime" とタイプしてください:
$ mprime
ソフトウェアがロードされたら、最初の質問に '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 の両方に出力されます。24 時間 Large FFTs を実行できなければ、多くの人はシステムが安定しているとはみなさないでしょう。
~/results.txt の例です。6月26日からの2回の実行でハードウェア障害が発生していることが分かります。このケースでは、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! ...
Linpack
linpackAUR は BLAS (Basic Linear Algebra Subprograms) ライブラリを使用して基本的なベクトルと行列の演算を行います。CPU に負荷をかけて安定性を調べる素晴らしい方法です (Intel CPU のみをサポートしています)。インストール後、/usr/share/linpack/linpack.conf を ~/.config/linpack.conf にコピーし、システムのメモリ容量にあわせて設定を行ってください。
Systester
SystesterAUR (Windows 版では SuperPi) は、CLI と GUI の両方のバージョンが利用できます。1億2800桁の円周率を計算してシステムの安定性をテストし、エラーの確認も行います。2つの異なる計算アルゴリズムから選択できます: Borwein の2次収束の公式と 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-efiAUR でインストールできます。
- インストールしたら、GRUB を更新することで、GRUB はパッケージを自動で検出し、MemTest86 を直接起動できるようになります。
イメージファイルへの書き込み
低負荷ワークロードでの安定性テストとしては、dd を使ってイメージをフォーマットするのが良い方法でしょう。これは、物理ディスクでもループバックマウントのイメージでも可能です。以下のスクリプトは、マウントされたイメージを使用し、ループ1回毎に各コアを1つずつ使います。あなたのシステムと合致するようにスクリプト上部の変数を調整する必要があることに注意してください。デフォルトでは、このスクリプトは1コアあたり1回だけコマンドを実行します。for ループを変更することで、0 から n までのすべてのコアをスキャンするのではなく、既知の弱いコア上で実行するように容易にカスタマイズすることができます。以下のスクリプトを root として実行してください。
format-test.sh
#!/bin/bash
# イメージを保存するパスを定義します。読み書きを回避するために tmpfs でマウントされた場所が推奨されます。
img=/scratch/image.img
# マウントポイントを定義します。
mnt=/mnt/loop
# truncate に渡すサイズ引数。システムの空きメモリよりも小さい値にしてください。
# 利用可能なオプションは truncate --help を見てください。
size=40G
# デフォルトでは仮想コアの数よりも少ない 1 になります。必要に応じて手動で再定義してください。
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 build system の記事を読んでください)。この場合、カーネル/Arch build system#コンパイル 章の部分で 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 といった一部のストレステストアプリケーションには、結果の不一致によるエラーを発見するための一貫性チェックが組み込まれています。ハードウェアの不安定性を測定するためのより一般的でよりシンプルな方法は、カーネル自体に存在します。
journalctl で手動で検索する
以下のようにクラッシュに関する journal をフィルターしてください:
# journalctl -k --grep=mce
rasdaemon を使う
あるいは、rasdaemonAUR をビルドして、同梱されているサービスを起動する方法もあります。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
コアまでエラーをトラッキングする
設定を最適化する際には、BIOS のオーバークロックのセクションで用いられるような文脈でのコア単位の安定性について理解しておくことが重要になります。一つのコアには複数の CPU が含まれていることもあります。
Ryzen 9950X (物理コア16個、CPU 32個) での以下のジャーナルのエラーを考えてみてください:
[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
以下のスクリプトは、物理コアから CPU へのマッピングリストを生成する際に使用できます:
~/bin/gen_mapping.sh
#!/bin/bash file=/tmp/mapping.txt phycores=$(( $(nproc) / 2 - 1 )) echo "Core CPU" > $file for ((i=0; i<=phycores; i++)); do echo "$i $(cat /sys/devices/system/cpu/cpu$i/topology/core_cpus_list)" >> $file done column -t $file
カーネルの ID で 5 と 21 の両 CPU が物理コア 5 にマップされていることがわかります:
Core CPU 0 0,16 1 1,17 2 2,18 3 3,19 4 4,20 5 5,21 6 6,22 7 7,23 8 8,24 9 9,25 10 10,26 11 11,27 12 12,28 13 13,29 14 14,30 15 15,31