「ストレステスト」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(冒頭を同期)
(同期)
 
(同じ利用者による、間の14版が非表示)
1行目: 1行目:
 
[[Category:CPU]]
  
[[Category:CPU]]
 
[[en:Stress testing]]
  
[[en:Stress testing]]
  +
[[pl:Stress testing]]
 
{{Related articles start}}
  
{{Related articles start}}
 
{{Related|ベンチマーク}}
  
{{Related|ベンチマーク}}
7行目: 8行目:
 
ストレステストとは、コンピュータ上で様々なワークロードを実行することでコンピュータの安定性を評価することです。オーバークロックされたハードウェアや電圧を落としたハードウェアの安定性を確実にチェックし、システムの熱的挙動 (例: 最大温度、スロットリング、ノイズレベル) を監視するためによく行われます。システムの様々な部分 (CPU、GPU、RAM、ストレージなど) を異なるタイプのワークロードを使ってストレステストするためのプログラムがいくつか存在します。
  
ストレステストとは、コンピュータ上で様々なワークロードを実行することでコンピュータの安定性を評価することです。オーバークロックされたハードウェアや電圧を落としたハードウェアの安定性を確実にチェックし、システムの熱的挙動 (例: 最大温度、スロットリング、ノイズレベル) を監視するためによく行われます。システムの様々な部分 (CPU、GPU、RAM、ストレージなど) を異なるタイプのワークロードを使ってストレステストするためのプログラムがいくつか存在します。
   
−
== エラーの確認 ==
 +
== ストレステストのタスク ==
−
mprime や linpack (下を参照) などのストレスアプリケーションは結果の不一致によってエラーをチェックする機能が組み込まれています。カーネルの中にもハードウェアが不安定であることを計測する汎用機能が入っています。以下のコマンドでカーネルのリングバッファを出力してみてください:
  
−
# cat /proc/kmsg
  
   
  +
以下の表では、テストの種類と全体的なワークロードの大きさに基づいて、いくつかのストレステストソフトウェアをリストアップしています。多くのユースケースにおける安定性を検証するために、複数の負荷を混ぜてストレステストを行うことが重要です。
−
以下のような出力がエラーです:
  
   
  +
{{Warning|この先に進む前に、システムの温度を監視する何らかの手段を確保しておくことが'''強く'''推奨されます。[[センサー]] を参照してください。}}
−
[Hardware Error]: Machine check events logged
  
   
  +
{| class="wikitable" align="center"
−
mprime が計算を終了してエラーを報告する前に、mprime の実行中にカーネルによって上記のエラーが出力される可能性があります。
  
  +
|-
  +
! ワークロード !! テストされるハードウェア<sup>1</sup> !! タスク !! 説明
  +
|-
  +
| rowspan="4" {{B|Light<sup>2</sup>}}
  +
|-
  +
| CPU、ストレージ || パッチのアップデート || OpenWRT プロジェクトの数百ものカーネルパッチを更新するカスタムスクリプト。[[#OpenWRT のパッチ更新]] を参照。
  +
|-
  +
| CPU、ストレージ || ディスクイメージを書き込む。 || [[#イメージファイルへの書き込み]] を参照。
  +
|-
  +
| RAM || メモリに負荷をかける || [[#MemTest86+]] を参照。
  +
|-
  +
| rowspan="5" {{Y|Realistic<sup>3</sup>}}
  +
|-
  +
| CPU、RAM、ストレージ || コンパイル || 並列コンパイルは CPU のストレステストを行うのに良い方法です。[[#GCC]] を参照。
  +
|-
  +
| CPU、RAM || 動画エンコード || {{Pkg|ffmpeg}}、{{Pkg|x264}}、{{Pkg|handbrake-cli}} などは、動画エンコードを行うために使用できます。[[#動画エンコード]] を参照。
  +
|-
  +
| CPU、RAM || 暗号通貨マイニング || {{Pkg|xmrig}} - {{ic|xmrig --stress}} は (CPU のモデルに基づいて) 異なる暗号通貨マイニングアルゴリズムを使用し、可能な限り最も高い負荷を掛けます。安定性と温度をテストするのに良い方法です。
  +
|-
  +
| GPU || 3D レンダリング || {{AUR|unigine-heaven}} はループで実行される GPU ベンチマークです。これは、GPU をストレステストするのに良い方法です。[[ベンチマーク#グラフィックス]] を参照。
  +
|-
  +
| rowspan="5" {{R|Synthetic<sup>4</sup>}}
  +
| CPU、RAM、ストレージ || 合成ストレステスト || {{Pkg|stress}} は、CPU、メモリ、I/O、そしてディスクのシンプルなワークロードジェネレータです。C で実装されています。[[#stress]] を参照。
  +
|-
  +
| CPU、RAM || 素数計算 || {{AUR|mprime-bin}} は大きな整数を因数分解します。CPU とメモリに負荷を掛けるのに良い方法です。[[#MPrime]] を参照。
  +
|-
  +
| CPU || 代数計算 || {{AUR|linpack}} - Linpack は BLAS (Basic Linear Algebra Subprograms) ライブラリを使用してベクトルと行列の基本的な演算を行います。CPU に負荷を掛けて安定性をテストするのに良い方法です。[[#Linpack]] を参照。
  +
|-
  +
| CPU || 円周率の計算 || {{AUR|systester}} Systester は、小数点以下 128,000,000 桁まで円周率を計算できるマルチスレッドのソフトウェアです。システムの安定性をチェックする機能が組み込まれています。[[#Systester]] を参照。
  +
|-
  +
| RAM || メモリに負荷をかける || {{AUR|stressapptest}} はメモリインターフェイステストです。
  +
|-
  +
|}
   
  +
* <sup>1</sup> 主なテスト対象。事実上、すべてのテストには CPU と RAM も含まれます。
−
== CPU に負担をかけるプログラム ==
  
  +
* <sup>2</sup> Light テストでは、(電力/熱が制限されるという点で) コンポーネントにあまり負荷をかけません。これらのテストは、特に低電圧なシステムでの低い電力レベル (P ステート) におけるハードウェアの挙動をテストするのに役立ちます。
  +
* <sup>3</sup> Realistic テストは、現実世界におけるワークロードに基づいています。
  +
* <sup>4</sup> Synthetic テストは、ハードウェアに可能な限りに大きな負荷をかけるように明示的に設計されており、現実世界におけるワークロードを代表するようなものではない場合があります。
   
  +
{{Tip|システムの安定性を確かなものにするために、様々な温度条件下でストレステストを長い時間 (数時間から数日) 実行することが推奨されます。例えば、室温が冬や夏で大きく異なる場合、これを考慮すべきです。}}
−
必要電圧に応じて2つのカテゴリに分けられます。システムの安定性を評価する際は両方のカテゴリのプログラムを使うことが重要です。皮肉にも、高電圧カテゴリのプログラムよりも中電圧カテゴリのプログラムの方がテストに落ちやすいことがあります。高電圧が必要なプログラムはハードウェアの使用量が激しいため最大の vcore を必要とします。中電圧が必要なプログラムは実行時にいつも最大 vcore を必要とするわけではなく要求されたクロック速度と比較して電圧が低い場合にエラーが発生しないかどうか確認することができます。
  
   
  +
=== OpenWRT のパッチ更新 ===
−
オーバークロックした i7-3770K (4.50 GHz) で各プログラムを実行すると以下のようになります。vcore はオフセットモードの +0.020 V で、全ての省電力機能は有効にしています。
  
   
  +
低負荷なワークロードの安定性テストとしては、OpenWRT プロジェクトのパッチセットをアップデートするのが良いでしょう。以下のステップに従ってください。
−
Idle: 0.7440 V - 0.8320 V (varies).
  
−
Mprime small FFTs: 1.2880 V (steady).
  
−
Mprime large FFTs: 1.3040 V (steady).
  
−
Mprime blend: 1.2960 V (steady).
  
−
Linpack: 1.2320 V - 1.2720 V (varies).
  
−
x264 encoding: 1.2320 V - 1.2720 V (varies).
  
−
gcc compiling: 1.2720 V (steady).
  
   
  +
{{Note|git や curl など、いくつかの依存パッケージが必要になります。その他のパッケージは {{Pkg|base-devel}} メタパッケージによってほとんど提供されるはずです。念の為に {{AUR|openwrt-devel}} メタパッケージをインストールすることができます。}}
−
上記のマシンでは vcode を +0.005 (オフセットモード) にして動作させたとき mprime と linpack では数時間安定していますが、x264 と gcc では数分でエラーが起こっています。
  
   
  +
git clone --depth 1 git@github.com:openwrt/openwrt.git
−
{| class="wikitable" align="center"
  
  +
cd openwrt
−
! 必要電圧 !! プログラム !! 説明
  
  +
mkdir -p staging_dir/host/bin
−
|-
  
  +
cp /usr/bin/sed ./staging_dir/host/bin
−
| rowspan="4" bgcolor=#fffacd| '''<span style="color: #CD8500;">Medium</span>'''
  
  +
curl -Os https://raw.githubusercontent.com/KanjiMonster/maintainer-tools/master/update_kernel.sh
−
|-
 
  +
chmod +x update_kernel.sh
−
| ''Cc/Gcc'' || cc/gcc のコンパイルは負担テストにうってつけです。両方とも {{Grp|base-devel}} グループに含まれています。
  
  +
./update_kernel.sh -v -u 5.15
−
|-
 
−
| ''HandBrake-cli'' || {{Pkg|handbrake-cli}} を使って高品質設定でエンコードしてみてください。
  
−
|-
 
−
| ''Systester'' || {{AUR|systester}} は1億2800万桁まで円周率を計算するマルチスレッドソフトウェアです。システムの安定性をチェックする機能が組み込まれています。
  
−
|-
  
−
| rowspan="2" bgcolor=#f7e3e3| '''<span style="color: #e62c2c;">High</span>'''
  
−
| ''mprime'' || {{AUR|mprime-bin}} は巨大な数を因数分解して CPU とメモリに負担をかけます。
  
−
|-
 
−
| ''linpack'' || Linpack は BLAS (Basic Linear Algebra Subprograms) ライブラリを使用してベクター演算・行列演算を行います。
  
−
|}
  
   
  +
=== stress ===
−
== CPU とメモリに負担をかけるプログラム ==
  
−
===Mprime (Windows と MacOS における Prime95)===
  
   
  +
{{Pkg|stress}} は、乱数の平方根を計算するループを実行して CPU に負荷を掛けます。例えば、複数のワーカーを同時に実行して CPU の全コアに負荷を掛けることができます。また、渡されたパラメータに応じてメモリや I/O、ディスクのワークロードを生成することもできます。[https://web.archive.org/web/20190629131203/http://people.seas.harvard.edu/~apw/stress/FAQ FAQ] には例や説明があります。
−
Prime95 はシステムの安定性を計測するときに使われる標準的なプログラムです。耐久テストモードで Mprime を実行すると CPU の負担が著しい計算を行ってから値が正しいかどうか比較します。
  
   
  +
4 つのワーカーを生成して平方根の計算を行うには、以下のコマンドを使ってください:
−
Linux 版の Prime95 は {{AUR|mprime}} と呼ばれ AUR からインストールできます。
  
   
  +
$ stress --cpu 4
−
{{Warning|計算を実行する前に、CPU 温度を監視する手段を用意することを強く推奨します。[[Lm sensors]] などのパッケージで監視できます。}}
  
  +
  +
=== s-tui ===
  +
  +
{{Pkg|s-tui}} は、ターミナルベースの CPU ストレステスト及び監視ユーティリティです。CPU の使用率と温度を監視でき、CPU に負荷をかけることもできます。ターミナルグラフィカルインターフェイスで、1つの画面で必要な情報をすべて確認できるスイスナイフのようなツールです。
  +
  +
=== MPrime ===
  +
  +
MPrime (Windows と MacOS の実装では Prime95 とも) は、システムの安定性の事実上の指標の1つとして広く認知されています。耐久テスト (Torture Test) モードでは、MPrime は CPU に非常に大きな負荷を掛ける一連の計算を行い、得られた値を既知の良い値と比較します。
  +
  +
Linux の実装は {{AUR|mprime}} と呼ばれています。
  +
  +
mprime を実行するには、シェルを開き、"mprime" とタイプしてください:
   
−
mprime を実行するにはシェルを開いて "mprime" と入力します:
  
 
$ mprime
  
$ mprime
   
−
{{note|[[cpufrequtils]] などの CPU 周波数スケーリングを使用する場合、mprime は nice 値を使用するため最大周波数で動作するように手動でプロセッサを設定する必要があります。}}
 +
{{Note|[[CPU 周波数スケーリング]]を使用している場合、プロセッサが最高のクロック倍率で動作するように手動で設定する必要がある場合があります。mprime は、倍数のステップアップを発生させないような nice 値を使用するからです。}}
   
−
ソフトウェアがロードされたら、最初の質問に 'N' と答えると耐久テストが始まります:
 +
ソフトウェアがロードされたら、最初の質問に 'N' と答えるだけで耐久テストが始まります:
   
  +
{{bc|
−
Main Menu
  
  +
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
  
   
  +
1. Test/Primenet
−
耐久テストには複数のオプションが存在します (メニューのオプション15)。
  
  +
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 とメモリに負担をかけるハイブリッドモードです。
  
   
  +
* CPU に負担をかけるには Small FFTs (オプション 1)。
−
エラーは標準出力と {{ic|~/results.txt}} に吐き出されます。Large FFTs を24時間実行できなければシステムが安定しているとは言えません。
  
  +
* CPU とメモリコントローラをテストするには In-place large FFTs (オプション 2)。
  +
* Blend (オプション 3) はデフォルトであり、CPU とメモリに負担をかけるハイブリッドモードです。
   
−
{{ic|~/results.txt}} は以下のように出力されます。以下の例では CPU の vcore 電圧が不足しているために2回エラーが発生しています:
 +
エラーが発生した場合は、標準出力と {{ic|~/results.txt}} の両方に出力されます。24 時間 Large FFTs を実行できなければ、多くの人はシステムが安定しているとはみなさないでしょう。
  +
−
<pre>[Sun Jun 26 20:10:35 2011]
  
  +
{{ic|~/results.txt}} の例です。6月26日からの2回の実行でハードウェア障害が発生していることが分かります。このケースでは、CPU のコア電圧が不足していることが原因です:
  +
  +
{{bc|
  +
[Sun Jun 26 20:10:35 2011]
 
FATAL ERROR: Rounding was 0.5, expected less than 0.4
  
FATAL ERROR: Rounding was 0.5, expected less than 0.4
 
Hardware failure detected, consult stress.txt file.
  
Hardware failure detected, consult stress.txt file.
110行目: 144行目:
 
Self-test 560K passed!
  
Self-test 560K passed!
 
Self-test 560K passed!
  
Self-test 560K passed!
−
...</pre>
 +
...
  +
}}
   
−
{{Note|small FFT テストはメモリをほとんど使用しないためメモリに不良がないかどうか確認したいときは blend テストを実行してください。}}
 +
{{Note|メモリやメモリコントローラの問題を疑っている場合、まず Blend テストを実行してみるべきです。Small FFT テストは僅かなメモリしか使用しないからです。}}
   
 
=== Linpack ===
  
=== Linpack ===
   
−
{{AUR|linpack}} は BLAS (Basic Linear Algebra Subprograms) ライブラリを使用して基本的なベクター・行列演算を行います。CPU に負担をかけて安定性を調べることができます (Intel の CPU だけがサポートされています)。インストール後、{{ic|/usr/share/linpack/linpack.conf}} を {{ic|~/.config/linpack.conf}} にコピーしてメモリ容量にあわせて設定を行ってください。
 +
{{AUR|linpack}} は BLAS (Basic Linear Algebra Subprograms) ライブラリを使用して基本的なベクトルと行列の演算を行います。CPU に負荷をかけて安定性を調べる素晴らしい方法です (Intel CPU のみをサポートしています)。インストール後、{{ic|/usr/share/linpack/linpack.conf}} を {{ic|~/.config/linpack.conf}} にコピーし、システムのメモリ容量にあわせて設定を行ってください。
   
−
=== Systester (Windows の SuperPi) ===
 +
=== Systester ===
  +
−
AUR の {{AUR|Systester}} は cli と gui の両方が使えます。円周率を計算してエラーチェックを行いシステムの安定性をテストします。2つの異なる計算アルゴリズムを選択できます: Quadratic Convergence of Borwein と Gauss-Legendre です。後者は Windows の SuperPi が使っている方法と同じです。
  
  +
{{AUR|Systester}} (Windows 版では SuperPi) は、CLI と GUI の両方のバージョンが利用できます。1億2800桁の円周率を計算してシステムの安定性をテストし、エラーの確認も行います。2つの異なる計算アルゴリズムから選択できます: Borwein の2次収束の公式と Gauss-Legendre 公式です。後者は Windows の人気な SuperPi が使っている方法と同じです。
  +
  +
8スレッドを使用する CLI の例は以下のようになります:
   
−
8スレッドで動作させるコマンドは以下のようになります:
  
 
$ systester-cli -gausslg 64M -threads 8
  
$ systester-cli -gausslg 64M -threads 8
   
−
=== Intel Processor Diagnostic Tool ===
 +
=== MemTest86+ ===
  +
  +
[https://www.memtest86.com/ MemTest86] (プロプライエタリ) か [https://www.memtest.org/ Memtest86+] (GPL) を使ってメモリ (RAM) をテストします。
  +
  +
* GPL のバージョンは [https://archlinux.org/download/ Arch Linux のインストールイメージ]で入手できます。以下でインストールできます:
  +
** EFI システムの場合は {{Pkg|memtest86+-efi}}
  +
** BIOS システムの場合は {{Pkg|memtest86+}}
  +
* プロプライエタリなバージョンは BIOS をサポートしていません。{{AUR|memtest86-efi}} でインストールできます。
  +
* インストールしたら、[[GRUB#メイン設定ファイルの生成|GRUB を更新]]することで、GRUB はパッケージを自動で検出し、MemTest86 を直接起動できるようになります。
  +
  +
{{Tip|
  +
* バージョン履歴の信頼できるソースは memtest86.com の [https://www.memtest86.com/memtest86.html History of MemTest86] セクションです。特に "2002 - 2004" とそれ以降のセクションです。プロプライエタリな MemTest86 のバージョン 5 から 7 までは BIOS と UEFI の両方をサポートしていると主張していますが、単に古いバージョンと新しいバージョンをバンドルしているだけだということに注意してください。
  +
* 通常、テストをエラー無しで 10 サイクル以上実行できたら十分です。
  +
}}
  +
  +
=== イメージファイルへの書き込み ===
  +
  +
低負荷ワークロードでの安定性テストとしては、{{ic|dd}} を使ってイメージをフォーマットするのが良い方法でしょう。これは、物理ディスクでもループバックマウントのイメージでも可能です。以下のスクリプトは、マウントされたイメージを使用し、ループ1回毎に各コアを1つずつ使います。あなたのシステムと合致するようにスクリプト上部の変数を調整する必要があることに注意してください。デフォルトでは、このスクリプトは1コアあたり1回だけコマンドを実行します。for ループを変更することで、0 から n までのすべてのコアをスキャンするのではなく、既知の弱いコア上で実行するように容易にカスタマイズすることができます。以下のスクリプトを root として実行してください。
  +
  +
{{hc|format-test.sh|<nowiki>
  +
#!/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
  +
</nowiki>}}
  +
  +
=== GCC ===
  +
  +
GCC (または他のコンパイラ) を使った並列コンパイルは、CPU とメモリに大きな負荷をかけます。I/O のボトルネックを回避するために、SSD 上または [[tmpfs]] 内でコンパイルしてください。
  +
  +
カーネルをコンパイルするのが良い例でしょう (詳細な手順は [[カーネル/Arch build system]] の記事を読んでください)。この場合、[[カーネル/Arch build system#コンパイル]] 章の部分で {{ic|1=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]] といった一部のストレステストアプリケーションには、結果の不一致によるエラーを発見するための一貫性チェックが組み込まれています。ハードウェアの不安定性を測定するためのより一般的でよりシンプルな方法は、カーネル自体に存在します。それを使用するには、以下のように単にクラッシュに関する journal をフィルターしてください:
  +
  +
# journalctl -k --grep=mce
  +
  +
複数コアのチップは、どの物理/論理コアがエラーを吐いたのかに関する情報も提供します。これは、ユーザがコア単位で設定を最適化している場合に重要である場合があります。
   
  +
カーネルはストレステストアプリケーションの実行中に (計算が終わってエラーを報告する前に) これらのエラーを投げる可能性があるため、安定性を評価するための非常に高感度な手法を提供しています。Ryzen 5900X の以下エラーについて考えてみましょう:
−
[https://downloadcenter.intel.com/download/19792/Intel-Processor-Diagnostic-Tool-64-bit- Intel Processor Diagnostic Tool] は CPU の耐久試験を行って Intel のマイクロプロセッサの機能を確認するツールです。Fedora Linux の LiveUSB ISO イメージが[http://www.tcsscreening.com/files/users/IPDT_LiveUSB/LiveUSB/index.html 存在しています]。LiveUSB イメージを使うことでメインのオペレーティングシステムを使わずに耐久テストを行うことができます。
  
   
  +
mce: [Hardware Error]: Machine check events logged
−
[[dd]] や Gnome Disks を使って USB スティックにイメージを書き込んで起動してください。起動したら、ターミナルを開いて以下のコマンドを実行することで64ビットマシン用の Intel Processor Diagnostic Tool をインストールします:
  
  +
mce: [Hardware Error]: CPU 21: Machine Check: 0 Bank 5: baa0000000030150
−
$ install64
  
  +
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 まで遡ることができます。{{Pkg|hwloc}} の ''lstopo'' を使ってハードウェアトポロジを表示してみます。
−
インストールしたら、デスクトップ上に表示された IPDT nおアイコンをクリックすることで診断ツールを起動できます。
  
   
  +
Core 0 = CPU 0 + CPU 1
−
== メモリに負担をかけるプログラム ==
  
  +
Core 1 = CPU 2 + CPU 3
−
メモリの負担テストの場合は [http://www.memtest.org/ Memtest86+] が良いでしょう。有名な Chris Brady によって書かれた memtest86 が元になっています。Memtest86+ はオリジナル版と同じように GNU General Public License (GPL) の元で配布されています。
  
  +
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
   
  +
{{Note|ナンバリングは CPU のモデルやベンダごとに異なっていますが、一般に、コアと CPU の番号は 1 ではなく 0 から始まります。}}
−
=== Memtest86+ の実行 ===
  
−
ISO をダウンロードして CD に書き込んで起動するか、[[公式リポジトリ]]から {{Pkg|memtest86+}} をインストールして [[GRUB#メイン設定ファイルの生成|GRUB を更新]]するとパッケージが自動で認識されて直接起動できるようになります (BIOS の場合のみ。EFI の場合は memtest86+ のかわりに {{AUR|memtest86-efi}} を使用するか [https://www.archlinux.jp/download/ Arch Linux のインストールイメージ] から memtest86+ を起動してください)。
  
   
  +
{{TranslationStatus|Stress testing|2024-04-19|806147}}
−
{{tip|Memtest86+ を10回以上実行してエラーが出なければ問題ありません。}}
  

2024年4月19日 (金) 14:55時点における最新版

関連記事

ストレステストとは、コンピュータ上で様々なワークロードを実行することでコンピュータの安定性を評価することです。オーバークロックされたハードウェアや電圧を落としたハードウェアの安定性を確実にチェックし、システムの熱的挙動 (例: 最大温度、スロットリング、ノイズレベル) を監視するためによく行われます。システムの様々な部分 (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 テストは、ハードウェアに可能な限りに大きな負荷をかけるように明示的に設計されており、現実世界におけるワークロードを代表するようなものではない場合があります。
ヒント: システムの安定性を確かなものにするために、様々な温度条件下でストレステストを長い時間 (数時間から数日) 実行することが推奨されます。例えば、室温が冬や夏で大きく異なる場合、これを考慮すべきです。

OpenWRT のパッチ更新

低負荷なワークロードの安定性テストとしては、OpenWRT プロジェクトのパッチセットをアップデートするのが良いでしょう。以下のステップに従ってください。

ノート: git や curl など、いくつかの依存パッケージが必要になります。その他のパッケージは base-devel メタパッケージによってほとんど提供されるはずです。念の為に 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 は、乱数の平方根を計算するループを実行して 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
ノート: 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 の両方に出力されます。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!
...
ノート: メモリやメモリコントローラの問題を疑っている場合、まず Blend テストを実行してみるべきです。Small FFT テストは僅かなメモリしか使用しないからです。

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 のインストールイメージで入手できます。以下でインストールできます:
  • プロプライエタリなバージョンは BIOS をサポートしていません。memtest86-efiAUR でインストールできます。
  • インストールしたら、GRUB を更新することで、GRUB はパッケージを自動で検出し、MemTest86 を直接起動できるようになります。
ヒント:
  • バージョン履歴の信頼できるソースは memtest86.com の History of MemTest86 セクションです。特に "2002 - 2004" とそれ以降のセクションです。プロプライエタリな MemTest86 のバージョン 5 から 7 までは BIOS と UEFI の両方をサポートしていると主張していますが、単に古いバージョンと新しいバージョンをバンドルしているだけだということに注意してください。
  • 通常、テストをエラー無しで 10 サイクル以上実行できたら十分です。

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

低負荷ワークロードでの安定性テストとしては、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 といった一部のストレステストアプリケーションには、結果の不一致によるエラーを発見するための一貫性チェックが組み込まれています。ハードウェアの不安定性を測定するためのより一般的でよりシンプルな方法は、カーネル自体に存在します。それを使用するには、以下のように単にクラッシュに関する 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 から始まります。
翻訳ステータス: このページは en:Stress testing の翻訳バージョンです。最後の翻訳日は 2024-04-19 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。
「https://wiki.archlinux.jp/index.php?title=ストレステスト&oldid=37108」から取得