初めに
1.1. ベンチマークとは?
「特定のハードウェア(CPU, GPU, SSD など)の性能を定量的に測る」ことです。
CPUや GPUには「計算能力」、SSDには「読み書き速度」、メモリには「帯域や遅延」など、測る対象が異なります。
1.2. 各OSでおすすめのソフトウェアおよびコマンド、ツールを紹介
1.2.1. Windows
項目 | 測定対象 | おすすめツール | 備考 |
---|---|---|---|
CPU | 処理能力 | Cinebench R23 | 定番 マルチ/シングルスレッド両対応 |
GPU | グラフィック性能 | Unigine Heaven、3DMark | ゲーム系ベンチマークも多数 |
SSD/HDD | 読み書き速度 | CrystalDiskMark | 超定番 簡単に読み書き速度が分かる |
全体のスコア | 総合 | UserBenchmark、PassMark | 色んなパーツを一括で比較可 |
筆者は、これまでベンチマーク計測なんて実施したことなかったの(我ながら良いゲーミングPCを持っている(ゲームしない)のに)ですが、これらの知見が必要になったので色々と調べました。
なので、まずは、CrystalDiskMark
や Cinebench
あたりを入れてみると、ベンチマークの雰囲気がつかめると思うので是非、やってみてください!
1.2.2. Ubuntu
項目 | コマンド/ツール | 備考 |
---|---|---|
CPU | sysbench | マルチスレッドの演算などを測定可能 |
GPU | tegrastats , jetson-utils , nvpmodel , jetson_benchmarks など | CUDAや NVIDIA独自ツールが必要 |
メモリ | stress-ng --metrics-brief | SSDや eMMCの読み書き速度測定 |
ストレージ | fio , dd , hdparm | 色んなパーツを一括で比較可 |
全体的に | phoronix-test-suite | 総合ベンチ GUIなしでも使える |
eMMCとは?
eMMC(embedded MultiMediaCard)は、スマホや組み込み機器などに使われる「内蔵型フラッシュストレージ」の規格のひとつです。
🔎eMMC の特徴
- 内蔵型(Embedded)
- 基板に直接はんだ付けされたチップ形状で提供される
- SSDのように取り外しできない、マザーボード直付けタイプ
- MMC インターフェース
- SDカードと同じ MMC(MultiMediaCard)規格をベースにしている
- データ転送は MMCのピンを通じて行う
- コントローラ一体型
- NAND フラッシュメモリチップの制御回路(ウェアレベリング、エラー訂正など)が内蔵されている
- 上位レイヤー(OS)からは「ブロックデバイス」として扱うだけでよく、細かいメモリ管理を意識しなくてよい
- 小型・省コスト
- サイズが小さく、部品点数も少ないので、組み込み機器に向く
- SSDに比べコストが抑えられる
- 性能
- 読み書き速度は数十~数百 MB/s程度(製品により異なる)
- 高速な SSD(NVMe PCIe 数百~数千 MB/s)には劣るが、組み込み用途では十分な性能
1.2.3. Jetson専用ツール
ツール | 備考 |
---|---|
tegrastats | CPU/GPU/メモリ使用率、温度などをリアルタイム表示 |
jetson_clocks | Jetsonの最大性能モードを有効にする |
nvpmodel | 電力プロファイルを変更してベンチマーク条件を統一 |
| htop風の GUI pip install jetson-statsで導入可能 |
Jetson向けおすすめ CPUベンチコマンド例
# sysbench インストール
sudo apt update && sudo apt install sysbench
# CPU演算ベンチマーク(例:整数の素因数分解)
sysbench cpu --threads=6 --time=10 run
ベンチマークの取得は何のために使うのか?
システム開発やマイグレーションにおいて、「ちゃんと動いた」や「問題なさそう」という曖昧な評価だけでは、本当に安心して運用できるとは言えません。
特に、CPUや GPU、メモリ、ストレージといったリソースに対して、『どのくらいの性能が出ているのか?』や『依然と比べて性能が向上しているのか?』と数値で示すことが、プロジェクトのの信頼性や品質保証に直結します。
そこで活用されるのがベンチマークです。
これらで測られた数値を基に、「処理性能」や「応答性」、「安全性」などを定量的に評価することができます。
例えば、以下のような場面で使用されます。
- マイグレーション後のパフォーマンス検証(Jetson Xavier → Orin)
- 開発時の電力効率やサーマルスロットリング確認
- 高負荷環境でも動作が安定しているかの確認
- ストレージの I/O性能やボトルネックの調査
- 他機種との比較用データ取得
次に、これらのシステム評価指標である RASISがとても参考になるので説明します。
システム評価指標である RASISとは?
ベンチマークは「数値的な証拠(証明・定量評価)」であって、RASISそのものではありません。
ですが、RASISの「信頼性(R)」や「可用性(A)」を確認するために非常に重要な材料となります。
2.1. 各RASIS要素とベンチマークの関連性
RASIS要素 | 意味 | ベンチマークとの関連性 |
---|---|---|
R: Reliability(信頼性) | 故障が起きにくく、期待通りに動作すること | 単体では難しいが、長時間負荷試験などで兆候を見ることができる |
A: Availability(可用性) | 利用したいときに稼働していること | ダウンタイムなしの性能(e.g. 高負荷時も応答可能か)にベンチマークが役に立つ |
S: Serviceability(保守性) | 故障時の検知や復旧のしやすさ | 関連は薄いが、ログやモニタリングツールがあると可視化しやすい |
I: Integrity(保全性) | データや処理結果が正しく保持されること | ストレージ I/Oエラー率や ECCログの監視が参考になる |
S: Security(安全性) | 不正アクセス・破壊からの防御 | 関連は薄いが、性能低下なしでのセキュリティ稼働が評価対象になることも |
ベンチマーク取得コマンド(RASIS)
3.1. Reliability(信頼性)
コマンドの実行結果は、全て「~/benchmarks/reliability
」へ出力する処理としています。
3.1.1. CPU耐久ベンチ(長時間負荷)
コマンド例
# 10分間、6スレッドで CPU演算
$ sysbench cpu --threads=6 --time=600 run \
| tee ~/benchmarks/reliability/sysbench_cpu_$(hostname).log
見るポイント
- 「events per second」や「total time」を比較
- Xavierと Orinで実行結果を並べ、向上率(Orin/Xavier)を算出
sysbench
役割:CPU/メモリ/ディスク/スレッドなどのベンチマークを行う汎用ツール。
今回は、CPUの負荷テストに利用
オプション | 意味 |
---|---|
cpu | CPUテストモードを指定(ほかに memory , threads , fileio など) |
--threads=<N> | 同時に動かすワーカースレッド数 |
--time=<秒> | ベンチ実行時間(秒) |
--max-requests=<数> | 総リクエスト数の上限指定 |
--cpu-max-prime=<数> | CPUテストで計算する素数の上限(デフォルト20,000) |
run | ベンチ実行コマンド |
<以下、その他 便利なオプション> | ==================== |
--rate=<n/sec> | 秒間あたりのリクエスト数制限 |
--validate={on|off} | 結果の検証機能の有効化 |
--report-interval=<s> | 中間レポートの出力間隔(秒) |
3.1.2. GPU長時間ストレス
コマンド例
# NVIDIAサンプル cudaBandwithTest(CUDA toolkitインストール済み前提)
$ cudaBandwithTest \
| tee ~/benchmarks/reliability/gpu_bandwidth_$(hostname).log
# または簡易に 30分間 tegrastatsを監視しつつ負荷
$ nohup sh -c 'for i in $(seq 1 60); do \
./my_cuda_workload; sleep 30; done' &
$ tegrastats --interval 1000 > ~/benchmarks/reliability/tegrastats_$(hostname).log
見るポイント
- メモリ帯域(GB/s)や演算性能(GFLOPS)
- 長時間で温度スロットリングが発生していないか
cudaBandwidthTest
役割:CUDAデバイスのメモリコピー帯域(Host ⇔ Device、Device ⇔ Device)を計測する NVIDIA提供のサンプルプログラム
※ Jetson専用コマンド(JetPack SDK が提供するツール群で、Jetson ボード上でのみ利用可能)
オプション | 意味 |
---|---|
--memory=pinned | ピン留めメモリ(ページロックメモリ)を使用 |
--memory=pageable | 通常メモリ(ページ可能メモリ)を使用 |
--device=<ID> | テスト対象の GPU デバイス番号を指定(省略可) |
<以下、その他 便利なオプション> | ==================== |
--num=<回数> | 各テストの繰り返し回数(デフォルト10) |
--size=<bytes> | 転送バッファサイズ(デフォルト 256MB) |
tegrastats
役割:Jetsonボード上で CPU、GPU、メモリ、電力、温度などのリアルタイム統計を表示
※ Jetson専用コマンド(JetPack SDK が提供するツール群で、Jetson ボード上でのみ利用可能)
オプション | 意味 |
---|---|
--interval=<ms> | 表示更新間隔(ミリ秒) |
--gpu-encode=<on|off> | GPUエンコード情報の表示有無 |
3.2. Availability(可用性)
コマンドの実行結果は、全て「~/benchmarks/availability
」へ出力する処理としています。
3.2.1. 再起動・起動時間測定
コマンド例
# systemd-analyze で計測
$ sudo systemd-analyze > ~/benchmarks/availability/boot_time_$(hostname).log
見るポイント
- 「Startup finished in …」の合計時間を比較
- Xavierと Orinの起動時間短縮率を確認
systemd-analyze
役割:systemd管理下の起動プロセスの時間計測・分析
オプション | 意味 |
---|---|
systemd-analyze | 起動全体に要した時間を表示 |
systemd-analyze blame | 起動処理ごとの時間ランキング(遅い順)を表示 |
systemd-analyze plot | 起動シーケンスを SVG で出力(> boot.svg のようにファイル化) |
3.2.2. サービス復旧テスト
コマンド例
# SSHセッション中に再起動し、自動ログイン可否を確認
$ ssh <username>@<hostname> "sudo reboot" & sleep 60 \
ssh <username>@<hostname> "echo OK" | tee ~/benchmarks/availability/reconnect_$(hostname).log
見るポイント
- 再起動から SSH再接続までの時間
- 自動起動する systemdサービスの有無
3.3. Serviceability(保守性)
コマンドの実行結果は、全て「~/benchmarks/serviceability
」へ出力する処理としています。
3.3.1. ログ出力・可読性チェック
コマンド例
# 起動直後の全ログを取得
$ journalctl -b > ~/benchmarks/serviceability/journal_$(hostname).log
# dmesg も取得
$ dmesg > ~/benchmarks/serviceability/dmesg_$(hostname).log
見るポイント
- エラーや Warningの数・内容
- キーワード検索(例:
$ grep -i error journal_*.log
)
journalctl
役割:systemdジャーナル(ログ)を閲覧・抽出
オプション | 意味 |
---|---|
-b | 現在のブート以降のログのみ表示 |
-u <サービス名> | 指定サービスのログのみ抽出 |
-f | リアルタイム追記表示(tail -f 相当) |
--since "YYYY-MM-DD" | 指定日時以降のログを表示 |
--priority=<0-7 or name> | ログレベルでフィルタ(例:err または 3 )を指定 |
dmesg
役割:カーネルリングバッファ(起動時やデバイスドライバのログ)を表示
オプション | 意味 |
---|---|
-T | タイムスタンプを人間可読形式に変換 |
-C | バッファクリア |
--level=<レベル> | 指定レベル(err , warn など)のメッセージのみ表示 |
3.3.2. リモートデバッグ確認
コマンド例
# SSHでのコアダンプ取得テスト
$ ulimit -c unlimited
$ ./faulty_app || echo $? > ~/benchmarks/serviceability/exitcode_$(hostname).txt
見るポイント
- core dump が生成されるか(デフォルト
/home/ubuntu/core.*
) - exit code の再現性
3.4. Integrity(保全性)
コマンドの実行結果は、全て「~/benchmarks/mmcblk0p1
」へ出力する処理としています。
3.4.1. ファイルシステム整合性チェック
コマンド例
$ sudo umount /dev/mmcblk0p1
$ sudo fsck.ext4 -n /dev/mmcblk0p1 \
| tee ~/benchmarks/integrity/fsck_$(hostname).log
見るポイント
- エラーや修復提案がないか
fsck.ext4
役割:ext4ファイルシステムの整合性チェック・修復ツール
オプション | 意味 |
---|---|
-n | 修復を行わず、ドライランでレポートのみ |
-y | すべての修復操作に自動的に「yes」で応答 |
-C | 進捗インジケーターを表示 |
3.4.2. データ読み書き検証
コマンド例
# 1GBファイルを作成しMD5チェック
$ dd if=/dev/urandom of=~/benchmarks/integrity/testfile bs=1M count=1024
$ md5sum ~/benchmarks/integrity/testfile \
| tee ~/benchmarks/integrity/md5_$(hostname).log
見るポイント
- Xavierと Orinで同一 MD5になるか
- 書き込み・読み込みでデータ劣化がないか
dd
役割:ext4ファイルシステムの整合性チェック・修復ツール
オプション | 意味 |
---|---|
if=<入力ファイル> | 読み込み元ファイル or デバイス |
of=<出力ファイル> | 書き込み先ファイル or デバイス |
bs=<サイズ> | ブロックサイズ(例 1M , 4k など) |
count=<数> | コピーするブロック数 |
status=<level> | 進捗表示レベル(none , noxfer , progress ) |
3.5. Integrity(保全性)
コマンドの実行結果は、全て「~/benchmarks/security
」へ出力する処理としています。
3.5.1. 開放ポート・サービス確認
コマンド例
$ sudo netstat -tulpn \
| tee ~/benchmarks/security/ports_$(hostname).log
見るポイント
- 不要なポートやサービスが起動していないか
netstat
役割:TCP/UDPポート使用状況やプロセスリスニング状況を表示
オプション | 意味 |
---|---|
-t | TCP接続を表示 |
-u | UDP接続を表示 |
-l | リッスン中のソケットのみ表示 |
-p | 対応するプロセス名・PID を表示 |
-n | アドレスとポートを数値で表示(名前解決を行わない) |
3.5.2. SSH・ユーザー権限チェック
コマンド例
$ cat /etc/ssh/sshd_config \
| tee ~/benchmarks/security/sshd_config_$(hostname).log
$ getent group sudo \
| tee ~/benchmarks/security/sudoers_$(hostname).log
見るポイント
- PermitRootLogin, PasswordAuthenticationの設定
- sudoグループに登録されているユーザー一覧
ファイル/コマンド | 用途 |
---|---|
/etc/ssh/sshd_config | SSHサーバの設定ファイルPermitRootLogin や PasswordAuthentication などを制御 |
getent group sudo | sudo グループのメンバー一覧を表示 |
usermod -aG <group> <user> | ユーザーをグループに追加(例: usermod -aG sudo ubuntu ) |
最後に
本記事では、システムの信頼性や性能を多角的に評価するためのベンチマークコマンドを、RASISの観点に沿って紹介しました。
各指標ごとに適したコマンドを使い分けることで、単なる数値比較に留まらず、実運用を見据えた有用な検証が可能となります。
特に、CPU・GPU性能だけでなく、起動時間やログ整合性、セキュリティ設定など、総合的に確認することが重要です。
Linuxを利用したあらゆるシステム開発において、RASISの視点は信頼性の高いシステム構築に役立ちます。
日々の運用管理やトラブル対応を想定したベンチマーク設計を意識し、より強固なシステムの実現を目指していきましょう。
comment 📝