ストレステスト - 版の履歴

AshMyzk: /* rasdaemon を使う */ 修正

2025-06-29T07:05:50Z

rasdaemon を使う: 修正

← 古い版		2025年6月29日 (日) 16:05時点における版
239行目:		239行目:
	=== rasdaemon を使う ===		=== rasdaemon を使う ===

	あるいは、{{AUR\|rasdaemon}} をビルドして、同梱されているサービスを[[起動]]する方法もあります。Rasdaemon はエラー sqlite データベースを保持します。同梱されている {{ic\|ras-mc-ctl}} バイナリでデータベースはクエリできます。		あるいは、{{AUR\|rasdaemon}} をビルドして、同梱されているサービスを[[起動]]する方法もあります。Rasdaemon はエラーを sqlite データベースに保持します。同梱されている {{ic\|ras-mc-ctl}} バイナリでデータベースはクエリできます。

	例:		例:

AshMyzk: /* ストレステストのタスク */ 修正

2025-06-29T07:04:00Z

ストレステストのタスク: 修正

← 古い版		2025年6月29日 (日) 16:04時点における版
51行目:		51行目:

	* <sup>1</sup> 主なテスト対象。事実上、すべてのテストには CPU と RAM も含まれます。		* <sup>1</sup> 主なテスト対象。事実上、すべてのテストには CPU と RAM も含まれます。
	* <sup>2</sup> ~~Light~~ テストでは、(電力/熱が制限されるという点で) コンポーネントにあまり負荷をかけません。これらのテストは、特に低電圧なシステムでの低い電力レベル (P ステート) におけるハードウェアの挙動をテストするのに役立ちます。		* <sup>2</sup> 軽量なテストでは、(電力/熱が制限されるという点で) コンポーネントにあまり負荷をかけません。これらのテストは、特に低電圧なシステムでの低い電力レベル (P ステート) におけるハードウェアの挙動をテストするのに役立ちます。
	* <sup>3</sup> ~~Realistic~~ テストは、現実世界におけるワークロードに基づいています。		* <sup>3</sup> 現実的なテストは、現実世界におけるワークロードに基づいています。
	* <sup>4</sup> ~~Synthetic~~ テストは、ハードウェアに可能な限りに大きな負荷をかけるように明示的に設計されており、現実世界におけるワークロードを代表するようなものではない場合があります。		* <sup>4</sup> 人工的なテストは、ハードウェアに可能な限りに大きな負荷をかけるように明示的に設計されており、現実世界におけるワークロードを代表するようなものではない場合があります。

	{{Tip\|システムの安定性を確かなものにするために、様々な温度条件下でストレステストを長い時間 (数時間から数日) 実行することが推奨されます。例えば、室温が冬や夏で大きく異なる場合、これを考慮すべきです。}}		{{Tip\|システムの安定性を確かなものにするために、様々な温度条件下でストレステストを長い時間 (数時間から数日) 実行することが推奨されます。例えば、室温が冬や夏で大きく異なる場合、これを考慮すべきです。}}

AshMyzk: 同期

2025-06-29T07:00:59Z

同期

差分を表示

AshMyzk: 同期

2024-04-19T05:55:45Z

同期

← 古い版		2024年4月19日 (金) 14:55時点における版
78行目:		78行目:
	$ stress --cpu 4		$ stress --cpu 4

	=== ~~stress++~~ ===		=== s-tui ===

			{{Pkg\|s-tui}} は、ターミナルベースの CPU ストレステスト及び監視ユーティリティです。CPU の使用率と温度を監視でき、CPU に負荷をかけることもできます。ターミナルグラフィカルインターフェイスで、1つの画面で必要な情報をすべて確認できるスイスナイフのようなツールです。
	{{AUR\|stress++}} は CodeLog によって書かれた軽量のストレステストプログラムです。[[Wikipedia:ja:アッカーマン関数\|アッカーマン関数]]を計算してプロセッサに負荷を掛けます。

	=== MPrime ===		=== MPrime ===
258行目:		258行目:
	{{Note\|ナンバリングは CPU のモデルやベンダごとに異なっていますが、一般に、コアと CPU の番号は 1 ではなく 0 から始まります。}}		{{Note\|ナンバリングは CPU のモデルやベンダごとに異なっていますが、一般に、コアと CPU の番号は 1 ではなく 0 から始まります。}}

	{{TranslationStatus\|Stress testing\|2024-01-11\|~~796010~~}}		{{TranslationStatus\|Stress testing\|2024-04-19\|806147}}

AshMyzk: 同期

2024-01-11T07:29:10Z

同期

@@ 160行目: / 160行目: @@
  $ systester-cli -gausslg 64M -threads 8
 === MemTest86+ ===
@@ 276行目: / 258行目: @@
 {{Note|ナンバリングは CPU のモデルやベンダごとに異なっていますが、一般に、コアと CPU の番号は 1 ではなく 0 から始まります。}}
-{{TranslationStatus|Stress testing|2024-01-02|795795}}
+{{TranslationStatus|Stress testing|2024-01-11|796010}}

AshMyzk: 同期

2024-01-01T22:46:10Z

同期

← 古い版		2024年1月2日 (火) 07:46時点における版
1行目:		1行目:
	[[Category:CPU]]		[[Category:CPU]]
	[[en:Stress testing]]		[[en:Stress testing]]
			[[pl:Stress testing]]
	{{Related articles start}}		{{Related articles start}}
	{{Related\|ベンチマーク}}		{{Related\|ベンチマーク}}
162行目:		163行目:
	=== Intel Processor Diagnostic Tool ===		=== Intel Processor Diagnostic Tool ===

	[https://downloadcenter.intel.com/download/19792/Intel-Processor-Diagnostic-Tool-64-bit- Intel Processor Diagnostic Tool] は CPU の耐久試験を行って Intel のマイクロプロセッサの機能を確認するツールです。~~Fedora~~ Linux ~~の LiveUSB ISO~~ イメージが[https://web.archive.org/web/~~20181005045417~~/http://www.tcsscreening.com/files/users/IPDT_LiveUSB/~~LiveUSB~~/index.html 存在しています]。LiveUSB イメージを使うことでメインのオペレーティングシステムを使わずに耐久テストを行うことができます。このような方法は、コールドリブート/クラッシュに対処する際に特に役立つかもしれません。		[https://downloadcenter.intel.com/download/19792/Intel-Processor-Diagnostic-Tool-64-bit- Intel Processor Diagnostic Tool] は CPU の耐久試験を行って Intel のマイクロプロセッサの機能を確認するツールです。このツールの Linux 版は現在メンテナンスされていませんが、Linux 版インストーラーのアーカイブコピーがまだ[https://web.archive.org/web/20181005051939/http://www.tcsscreening.com/files/users/IPDT_LiveUSB/installer/index.html 利用可能]です。このツールは非 Intel CPU に対して使用するようにはライセンスされていません。Intel は、[https://spins.fedoraproject.org/xfce/download/ Fedora 25 LiveUSB] からこのツールを実行することを推奨していますが、Arch Linux 上でも動作します。この LiveUSB イメージを使うことでメインのオペレーティングシステムを使わずに耐久テストを行うことができます。このような方法は、コールドリブート/クラッシュに対処する際に特に役立つかもしれません。

	[[dd]] ~~や Gnome Disks を使っ~~て USB スティックにイメージを書き込んで起動して~~くださ~~い。起動したら、ターミナルを開いて以下のコマンドを実行~~することで64ビットマシン用の Intel Processor Diagnostic Tool~~ をインストールします:		お望みならば、[[USB インストールメディア]]の記事に書かれてある方法で USB スティックに先の Fedora のイメージを書き込み、その USB から起動しても良いです。起動したら、64 ビット機用の Intel Processor Diagnostic Tool を[https://web.archive.org/web/20170718012736if_/http://www.tcsscreening.com/files/users/IPDT_LiveUSB/installer/install64 ダウンロード]し (ブラウザが {{ic\|.txt}} 拡張子を追加してしまう場合は、取り除いてください)、ターミナルを開き、以下のコマンドを実行してツールをインストールしてください:

	$ install64		# ./install64

			インストールが終わると、インストーラはツールを起動するか尋ねてきます。出てきたウィンドウは閉じてください。このツールには、最近のバージョンの {{ic\|libGL}} とは互換性のない古いライブラリが同梱されており、GPU のテストが失敗してしまうからです。システムのライブラリを使用するために、これらのライブラリを削除してください:
	インストールしたら、デスクトップ上に表示された IPDT アイアイコンをクリックすることで診断ツールを起動できます。

			# rm -f /ipdt64/lib/libstdc++* /ipdt64/lib/libxcb*

			これで、{{ic\|/ipdt64/ipdt64}} スクリプトを root として実行することで、ツールを起動することができます。しかし、設定が変更できないため、利便性は制限されています。問題は、デフォルトを変更できないため、1度でもテストに失敗する (最近の CPU では確実に発生します) と、テストが止まってしまうことです。例えば、2017 年以降に製造された CPU では、"BrandString" テストで即座に失敗します。

			この問題は、個々のサブテストを手動で実行することで、回避できます。例えば、以下のコマンドは CPU 5 で {{ic\|Math_PrimeNum}} テストを実行します:

			$ LD_LIBRARY_PATH=`pwd`/lib taskset --cpu-list 5 ./Math_PrimeNum

	=== MemTest86+ ===		=== MemTest86+ ===
227行目:		236行目:
	GCC (または他のコンパイラ) を使った並列コンパイルは、CPU とメモリに大きな負荷をかけます。I/O のボトルネックを回避するために、SSD 上または [[tmpfs]] 内でコンパイルしてください。		GCC (または他のコンパイラ) を使った並列コンパイルは、CPU とメモリに大きな負荷をかけます。I/O のボトルネックを回避するために、SSD 上または [[tmpfs]] 内でコンパイルしてください。

			カーネルをコンパイルするのが良い例でしょう (詳細な手順は [[カーネル/Arch build system]] の記事を読んでください)。この場合、[[カーネル/Arch build system#コンパイル]] 章の部分で {{ic\|1=makepkg -sf MAKEFLAGS="-j$(nproc)"}} を実行してください。
	以下の例では、Linux カーネルをコンパイルします。

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

	=== 動画エンコード ===		=== 動画エンコード ===
272行目:		276行目:
	{{Note\|ナンバリングは CPU のモデルやベンダごとに異なっていますが、一般に、コアと CPU の番号は 1 ではなく 0 から始まります。}}		{{Note\|ナンバリングは CPU のモデルやベンダごとに異なっていますが、一般に、コアと CPU の番号は 1 ではなく 0 から始まります。}}

	{{TranslationStatus\|Stress testing\|~~2023-06~~-01\|~~775678~~}}		{{TranslationStatus\|Stress testing\|2024-01-02\|795795}}

AshMyzk: TranslationStatus

2023-06-01T00:17:38Z

TranslationStatus

← 古い版		2023年6月1日 (木) 09:17時点における版
271行目:		271行目:

	{{Note\|ナンバリングは CPU のモデルやベンダごとに異なっていますが、一般に、コアと CPU の番号は 1 ではなく 0 から始まります。}}		{{Note\|ナンバリングは CPU のモデルやベンダごとに異なっていますが、一般に、コアと CPU の番号は 1 ではなく 0 から始まります。}}

			{{TranslationStatus\|Stress testing\|2023-06-01\|775678}}

AshMyzk: /* イメージファイルへの書き込み */ 翻訳

2023-06-01T00:16:57Z

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

← 古い版		2023年6月1日 (木) 09:16時点における版
187行目:		187行目:
	=== イメージファイルへの書き込み ===		=== イメージファイルへの書き込み ===

			低負荷ワークロードでの安定性テストとしては、{{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))

AshMyzk: /* GCC */ 翻訳

2023-06-01T00:07:33Z

GCC: 翻訳

← 古い版		2023年6月1日 (木) 09:07時点における版
225行目:		225行目:
	=== 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]].

			以下の例では、Linux カーネルをコンパイルします。
	The example below will compile the Linux kernel.

	pacman -Syu asp		pacman -Syu asp

AshMyzk: /* 動画エンコード */ 翻訳

2023-05-31T23:54:19Z

動画エンコード: 翻訳

← 古い版		2023年6月1日 (木) 08:54時点における版
236行目:		236行目:
	=== 動画エンコード ===		=== 動画エンコード ===

			ほとんどの動画エンコーダは非常に良く並列化されており、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