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

提供: ArchWiki
ナビゲーションに移動 検索に移動
("ストレステストのタスク" を追加)
(同期)
 
(同じ利用者による、間の13版が非表示)
1行目: 1行目:
 
[[Category:CPU]]
  
[[Category:CPU]]
 
[[en:Stress testing]]
  
[[en:Stress testing]]
  +
[[pl:Stress testing]]
 
{{Related articles start}}
  
{{Related articles start}}
 
{{Related|ベンチマーク}}
  
{{Related|ベンチマーク}}
53行目: 54行目:
 
* <sup>4</sup> Synthetic テストは、ハードウェアに可能な限りに大きな負荷をかけるように明示的に設計されており、現実世界におけるワークロードを代表するようなものではない場合があります。
  
* <sup>4</sup> Synthetic テストは、ハードウェアに可能な限りに大きな負荷をかけるように明示的に設計されており、現実世界におけるワークロードを代表するようなものではない場合があります。
   
−
{{Tip|システムの安定性を確かなものにするには、。
 +
{{Tip|システムの安定性を確かなものにするために、様々な温度条件下でストレステストを長い時間 (数時間から数日) 実行することが推奨されます。例えば、室温が冬や夏で大きく異なる場合、これを考慮すべきです。}}
−  
−
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 のパッチ更新 ===
  
=== OpenWRT のパッチ更新 ===
   
  +
低負荷なワークロードの安定性テストとしては、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.
  
   
  +
{{Note|git や curl など、いくつかの依存パッケージが必要になります。その他のパッケージは {{Pkg|base-devel}} メタパッケージによってほとんど提供されるはずです。念の為に {{AUR|openwrt-devel}} メタパッケージをインストールすることができます。}}
−
{{Note|Several dependencies including git and curl are needed, most others should be provided by the dependencies of the {{Pkg|base-devel}} [[meta package]]. To be safe, users can always install the metapackage {{AUR|openwrt-devel}}.}}
  
   
 
git clone --depth 1 git@github.com:openwrt/openwrt.git
  
git clone --depth 1 git@github.com:openwrt/openwrt.git
73行目: 72行目:
 
=== stress ===
  
=== stress ===
   
−
{{Pkg|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 [https://web.archive.org/web/20190629131203/http://people.seas.harvard.edu/~apw/stress/FAQ FAQ] provides examples and explanations.
 +
{{Pkg|stress}} は、乱数の平方根を計算するループを実行して CPU に負荷を掛けます。例えば、複数のワーカーを同時に実行して CPU の全コアに負荷を掛けることができます。また、渡されたパラメータに応じてメモリや I/O、ディスクのワークロードを生成することもできます。[https://web.archive.org/web/20190629131203/http://people.seas.harvard.edu/~apw/stress/FAQ FAQ] には例や説明があります。
   
  +
4 つのワーカーを生成して平方根の計算を行うには、以下のコマンドを使ってください:
−
To spawn 4 workers working on calculating a square root, use the command:
  
   
 
$ stress --cpu 4
  
$ stress --cpu 4
   
−
=== stress++ ===
 +
=== s-tui ===
   
  +
{{Pkg|s-tui}} は、ターミナルベースの CPU ストレステスト及び監視ユーティリティです。CPU の使用率と温度を監視でき、CPU に負荷をかけることもできます。ターミナルグラフィカルインターフェイスで、1つの画面で必要な情報をすべて確認できるスイスナイフのようなツールです。
−
{{AUR|stress++}} is a lightweight stress-testing program written by CodeLog that stimulates the processor by computing the [[Wikipedia:Ackermann function|Ackermann function]].
  
   
 
=== MPrime ===
  
=== MPrime ===
   
  +
MPrime (Windows と MacOS の実装では Prime95 とも) は、システムの安定性の事実上の指標の1つとして広く認知されています。耐久テスト (Torture Test) モードでは、MPrime は CPU に非常に大きな負荷を掛ける一連の計算を行い、得られた値を既知の良い値と比較します。
−
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 {{AUR|mprime}}.
 +
Linux の実装は {{AUR|mprime}} と呼ばれています。
   
  +
mprime を実行するには、シェルを開き、"mprime" とタイプしてください:
−
To run mprime, simply open a shell and type "mprime":
  
   
 
$ mprime
  
$ mprime
   
  +
{{Note|[[CPU 周波数スケーリング]]を使用している場合、プロセッサが最高のクロック倍率で動作するように手動で設定する必要がある場合があります。mprime は、倍数のステップアップを発生させないような nice 値を使用するからです。}}
−
{{Note|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.}}
  
   
  +
ソフトウェアがロードされたら、最初の質問に 'N' と答えるだけで耐久テストが始まります:
−
When the software loads, simply answer 'N' to the first question to begin the torture testing:
  
   
 
{{bc|
  
{{bc|
120行目: 119行目:
 
}}
  
}}
   
  +
耐久テスト (メニューオプション 15) にはいくつかのオプションが存在します。
−
There are several options for the torture test (menu option 15).
  
   
−
* Small FFTs (option 1) to stress the CPU
 +
* CPU に負担をかけるには Small FFTs (オプション 1)。
  +
* CPU とメモリコントローラをテストするには In-place large FFTs (オプション 2)。
−
* In-place large FFTs (option 2) to test the CPU and memory controller
  
  +
* Blend (オプション 3) はデフォルトであり、CPU とメモリに負担をかけるハイブリッドモードです。
−
* Blend (option 3) is the default and constitutes a hybrid mode which stresses the CPU and RAM.
  
   
  +
エラーが発生した場合は、標準出力と {{ic|~/results.txt}} の両方に出力されます。24 時間 Large FFTs を実行できなければ、多くの人はシステムが安定しているとはみなさないでしょう。
−
Errors will be reported should they occur both to stdout and to {{ic|~/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.
  
   
  +
{{ic|~/results.txt}} の例です。6月26日からの2回の実行でハードウェア障害が発生していることが分かります。このケースでは、CPU のコア電圧が不足していることが原因です:
−
Example {{ic|~/results.txt}}; note that the two runs from 26-June indicate a hardware failure. In this case, due to insufficient vcore to the CPU:
  
   
 
{{bc|
  
{{bc|
148行目: 147行目:
 
}}
  
}}
   
  +
{{Note|メモリやメモリコントローラの問題を疑っている場合、まず Blend テストを実行してみるべきです。Small FFT テストは僅かなメモリしか使用しないからです。}}
−
{{Note|Users suspecting bad memory or memory controllers should try the blend test first as the small FFT test uses very little memory.}}
  
   
 
=== Linpack ===
  
=== Linpack ===
   
−
{{AUR|linpack}} 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 {{ic|/usr/share/linpack/linpack.conf}} to {{ic|~/.config/linpack.conf}} and adjust it according to the amount of memory on the system.
 +
{{AUR|linpack}} は BLAS (Basic Linear Algebra Subprograms) ライブラリを使用して基本的なベクトルと行列の演算を行います。CPU に負荷をかけて安定性を調べる素晴らしい方法です (Intel CPU のみをサポートしています)。インストール後、{{ic|/usr/share/linpack/linpack.conf}} を {{ic|~/.config/linpack.conf}} にコピーし、システムのメモリ容量にあわせて設定を行ってください。
   
 
=== Systester ===
  
=== Systester ===
   
  +
{{AUR|Systester}} (Windows 版では SuperPi) は、CLI と GUI の両方のバージョンが利用できます。1億2800桁の円周率を計算してシステムの安定性をテストし、エラーの確認も行います。2つの異なる計算アルゴリズムから選択できます: Borwein の2次収束の公式と Gauss-Legendre 公式です。後者は Windows の人気な SuperPi が使っている方法と同じです。
−
{{AUR|Systester}} (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.
  
   
  +
8スレッドを使用する CLI の例は以下のようになります:
−
A CLI example using 8 threads is given:
  
   
 
$ systester-cli -gausslg 64M -threads 8
  
$ systester-cli -gausslg 64M -threads 8
−  
−
=== Intel Processor Diagnostic Tool ===
  
−  
−
The [https://downloadcenter.intel.com/download/19792/Intel-Processor-Diagnostic-Tool-64-bit- 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 [https://web.archive.org/web/20181005045417/http://www.tcsscreening.com/files/users/IPDT_LiveUSB/LiveUSB/index.html 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+ ===
  
=== MemTest86+ ===
   
−
Use [https://www.memtest86.com/ MemTest86] (proprietary) or [https://www.memtest.org/ Memtest86+] (GPL) to test your memory (RAM).
+
[https://www.memtest86.com/ MemTest86] (プロプライエタリ) か [https://www.memtest.org/ Memtest86+] (GPL) を使ってメモリ (RAM) をテストします。
   
−
* The GPL version is available on the [https://archlinux.org/download/ Arch Linux install image]. It can be installed:
+
* GPL のバージョンは [https://archlinux.org/download/ Arch Linux のインストールイメージ]で入手できます。以下でインストールできます:
−
** for EFI systems with {{Pkg|memtest86+-efi}},
+
** EFI システムの場合は {{Pkg|memtest86+-efi}}
−
** for BIOS systems with {{Pkg|memtest86+}}
 +
** BIOS システムの場合は {{Pkg|memtest86+}}
  +
* プロプライエタリなバージョンは BIOS をサポートしていません。{{AUR|memtest86-efi}} でインストールできます。
−
* The proprietary versions does not support BIOS. Install it as {{AUR|memtest86-efi}}.
  
  +
* インストールしたら、[[GRUB#メイン設定ファイルの生成|GRUB を更新]]することで、GRUB はパッケージを自動で検出し、MemTest86 を直接起動できるようになります。
−
* After installation, its users can [[GRUB#Generate the main configuration file|update GRUB]]: it will auto-detect the package and allow users to boot directly to it.
  
   
 
{{Tip|
  
{{Tip|
  +
* バージョン履歴の信頼できるソースは memtest86.com の [https://www.memtest86.com/memtest86.html History of MemTest86] セクションです。特に "2002 - 2004" とそれ以降のセクションです。プロプライエタリな MemTest86 のバージョン 5 から 7 までは BIOS と UEFI の両方をサポートしていると主張していますが、単に古いバージョンと新しいバージョンをバンドルしているだけだということに注意してください。
−
* A reliable source of the version history is the [https://www.memtest86.com/memtest86.html 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.
  
  +
* 通常、テストをエラー無しで 10 サイクル以上実行できたら十分です。
−
* Allowing tests to run for at least 10 cycles without errors is usually sufficient.
  
 
}}
  
}}
   
 
=== イメージファイルへの書き込み ===
  
=== イメージファイルへの書き込み ===
   
  +
低負荷ワークロードでの安定性テストとしては、{{ic|dd}} を使ってイメージをフォーマットするのが良い方法でしょう。これは、物理ディスクでもループバックマウントのイメージでも可能です。以下のスクリプトは、マウントされたイメージを使用し、ループ1回毎に各コアを1つずつ使います。あなたのシステムと合致するようにスクリプト上部の変数を調整する必要があることに注意してください。デフォルトでは、このスクリプトは1コアあたり1回だけコマンドを実行します。for ループを変更することで、0 から n までのすべてのコアをスキャンするのではなく、既知の弱いコア上で実行するように容易にカスタマイズすることができます。以下のスクリプトを root として実行してください。
−
A good stability test under a low load workload is using {{ic|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.
  
   
 
{{hc|format-test.sh|<nowiki>
  
{{hc|format-test.sh|<nowiki>
 
#!/bin/bash
  
#!/bin/bash
   
  +
# イメージを保存するパスを定義します。読み書きを回避するために tmpfs でマウントされた場所が推奨されます。
−
# define the path to store the image, recommended to be a tmpfs mounted location to avoid read/writes
  
 
img=/scratch/image.img
  
img=/scratch/image.img
   
  +
# マウントポイントを定義します。
−
# define the mount point
  
 
mnt=/mnt/loop
  
mnt=/mnt/loop
   
  +
# truncate に渡すサイズ引数。システムの空きメモリよりも小さい値にしてください。
−
# 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
 +
# 利用可能なオプションは truncate --help を見てください。
 
size=40G
  
size=40G
   
  +
# デフォルトでは仮想コアの数よりも少ない 1 になります。必要に応じて手動で再定義してください。
−
# defaults to 1 less than the number of virtual cores, manually redefine if desired
  
 
max=$(($(nproc) - 1))
  
max=$(($(nproc) - 1))
   
227行目: 216行目:
 
=== GCC ===
  
=== GCC ===
   
  +
GCC (または他のコンパイラ) を使った並列コンパイルは、CPU とメモリに大きな負荷をかけます。I/O のボトルネックを回避するために、SSD 上または [[tmpfs]] 内でコンパイルしてください。
−
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]].
  
   
  +
カーネルをコンパイルするのが良い例でしょう (詳細な手順は [[カーネル/Arch build system]] の記事を読んでください)。この場合、[[カーネル/Arch build system#コンパイル]] 章の部分で {{ic|1=makepkg -sf MAKEFLAGS="-j$(nproc)"}} を実行してください。
−
The example below will compile the Linux kernel.
  
−  
−
pacman -Syu asp
  
−
asp export linux
  
−
cd linux
  
−
makepkg -sf MAKEFLAGS="-j$(nproc)"
  
   
 
=== 動画エンコード ===
  
=== 動画エンコード ===
   
  +
ほとんどの動画エンコーダは非常に良く並列化されており、CPU の計算能力をほぼ全て使うように設計されています。以下の例では、x265 を使ってノイズをエンコードし、結果を破棄します。CPU に大きな負荷がかかります。
−
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
  
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 (下を参照) などのストレスアプリケーションは結果の不一致によってエラーをチェックする機能が組み込まれています。カーネルの中にもハードウェアが不安定であることを計測する汎用機能が入っています。以下のコマンドでカーネルのリングバッファを出力してみてください:
  
−
# cat /proc/kmsg
  
   
  +
[[#MPrime]] や [[#Linpack]] といった一部のストレステストアプリケーションには、結果の不一致によるエラーを発見するための一貫性チェックが組み込まれています。ハードウェアの不安定性を測定するためのより一般的でよりシンプルな方法は、カーネル自体に存在します。それを使用するには、以下のように単にクラッシュに関する journal をフィルターしてください:
−
以下のような出力がエラーです:
  
   
  +
# journalctl -k --grep=mce
−
[Hardware Error]: Machine check events logged
  
−  
−
mprime が計算を終了してエラーを報告する前に、mprime の実行中にカーネルによって上記のエラーが出力される可能性があります。
  
−  
−
== CPU に負担をかけるプログラム ==
  
−  
−
必要電圧に応じて2つのカテゴリに分けられます。システムの安定性を評価する際は両方のカテゴリのプログラムを使うことが重要です。皮肉にも、高電圧カテゴリのプログラムよりも中電圧カテゴリのプログラムの方がテストに落ちやすいことがあります。高電圧が必要なプログラムはハードウェアの使用量が激しいため最大の vcore を必要とします。中電圧が必要なプログラムは実行時にいつも最大 vcore を必要とするわけではなく要求されたクロック速度と比較して電圧が低い場合にエラーが発生しないかどうか確認することができます。
  
−  
−
オーバークロックした i7-3770K (4.50 GHz) で各プログラムを実行すると以下のようになります。vcore はオフセットモードの +0.020 V で、全ての省電力機能は有効にしています。
  
−  
−
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).
  
−  
−
上記のマシンでは vcode を +0.005 (オフセットモード) にして動作させたとき mprime と linpack では数時間安定していますが、x264 と gcc では数分でエラーが起こっています。
  
−  
−
{| class="wikitable" align="center"
  
−
! 必要電圧 !! プログラム !! 説明
  
−
|-
  
−
| rowspan="4" bgcolor=#fffacd| '''<span style="color: #CD8500;">Medium</span>'''
  
−
|-
 
−
| ''Cc/Gcc'' || cc/gcc のコンパイルは負担テストにうってつけです。両方とも {{Grp|base-devel}} グループに含まれています。
  
−
|-
 
−
| ''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) ライブラリを使用してベクター演算・行列演算を行います。
  
−
|}
  
−  
−
== CPU とメモリに負担をかけるプログラム ==
  
−
===Mprime (Windows と MacOS における Prime95)===
  
−  
−
Prime95 はシステムの安定性を計測するときに使われる標準的なプログラムです。耐久テストモードで Mprime を実行すると CPU の負担が著しい計算を行ってから値が正しいかどうか比較します。
  
−  
−
Linux 版の Prime95 は {{AUR|mprime}} と呼ばれ AUR からインストールできます。
  
−  
−
{{Warning|計算を実行する前に、CPU 温度を監視する手段を用意することを強く推奨します。[[Lm sensors]] などのパッケージで監視できます。}}
  
−  
−
mprime を実行するにはシェルを開いて "mprime" と入力します:
  
−
$ mprime
  
−  
−
{{note|[[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 とメモリに負担をかけるハイブリッドモードです。
  
−  
−
エラーは標準出力と {{ic|~/results.txt}} に吐き出されます。Large FFTs を24時間実行できなければシステムが安定しているとは言えません。
  
−  
−
{{ic|~/results.txt}} は以下のように出力されます。以下の例では CPU の vcore 電圧が不足しているために2回エラーが発生しています:
  
−
<pre>[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!
  
−
...</pre>
  
−  
−
{{Note|small FFT テストはメモリをほとんど使用しないためメモリに不良がないかどうか確認したいときは blend テストを実行してください。}}
  
−  
−
=== Linpack ===
  
−  
−
{{AUR|linpack}} は BLAS (Basic Linear Algebra Subprograms) ライブラリを使用して基本的なベクター・行列演算を行います。CPU に負担をかけて安定性を調べることができます (Intel の CPU だけがサポートされています)。インストール後、{{ic|/usr/share/linpack/linpack.conf}} を {{ic|~/.config/linpack.conf}} にコピーしてメモリ容量にあわせて設定を行ってください。
  
−  
−
=== Systester (Windows の SuperPi) ===
  
−
AUR の {{AUR|Systester}} は cli と gui の両方が使えます。円周率を計算してエラーチェックを行いシステムの安定性をテストします。2つの異なる計算アルゴリズムを選択できます: Quadratic Convergence of Borwein と Gauss-Legendre です。後者は Windows の SuperPi が使っている方法と同じです。
  
−  
−
8スレッドで動作させるコマンドは以下のようになります:
  
−
$ systester-cli -gausslg 64M -threads 8
  
   
  +
複数コアのチップは、どの物理/論理コアがエラーを吐いたのかに関する情報も提供します。これは、ユーザがコア単位で設定を最適化している場合に重要である場合があります。
−
=== Intel Processor Diagnostic Tool ===
  
   
  +
カーネルはストレステストアプリケーションの実行中に (計算が終わってエラーを報告する前に) これらのエラーを投げる可能性があるため、安定性を評価するための非常に高感度な手法を提供しています。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」から取得