推測はやめよう：Linuxサーバーのベンチマーク実践ガイド

課題：「体感」は指標にならない

先月、私はクライアントのAPIを新しいVPSプロバイダーに移行しました。マーケティング資料には「超高速NVMeストレージ」や「専用CPUスレッド」といった言葉が並んでいました。スペック上は以前のホストと全く同じでしたが、切り替え直後、APIの平均レイテンシが140msから200ms近くまで跳ね上がりました。主観的にはターミナルの動作が重く感じられましたが、サポートチケットに「体感」を書いて送っても、返金は期待できません。

広告スペックと実際のパフォーマンスの乖離は、往々にして巨大です。仮想化環境では、topコマンドには表示されないCPUスティールタイム（CPU steal time）やI/O制限が発生することがよくあります。真実を知るには客観的なデータが必要です。私はマーケティングの誇大広告を見抜くために、2つの業界標準ツールを活用しています。システム全体のベースラインを素早く把握するためのUnixBenchと、特定のワークロードに対して詳細な負荷テストを行うためのPhoronix Test Suiteです。

10分で終わるベースライン測定：UnixBench

UnixBenchは、ベンチマークツールの古参です。ファイルコピー、パイプスループット、シェルスクリプトの実行といった基本操作をテストし、最終的に単一のインデックススコアを算出します。この数値はシステムの健康状態を示す簡潔な指標となり、月額5ドルのエントリーモデルとハイエンドな専用サーバーを数分で比較できます。

1. 環境の準備

クリーンなDebianまたはUbuntuシステムでは、ベンチマークのソースコードをコンパイルするためにbuild-essentialとPerlが必要になります。

sudo apt update
sudo apt install build-essential libx11-dev libgl1-mesa-dev libxext-dev perl -y

2. テストの実行

UnixBenchは、1990年代のオリジナルコードよりもマルチコアプロセッサを適切に処理できる、最新のGitHubフォーク版を使用することをお勧めします。

git clone https://github.com/krakjoe/byte-unixbench.git
cd byte-unixbench/UnixBench
./Run

テストは通常15分ほどで完了します。最後に表示されるSystem Benchmarks Index Scoreを確認してください。目安として、控えめなシングルコアのVPSで通常900〜1,100程度です。現代的なシステムでスコアが600を下回る場合、プロバイダーがハードウェアをオーバーセル（過剰販売）している可能性があります。

詳細な分析：Phoronix Test Suite (PTS)

UnixBenchは全体像を把握するのに役立ちますが、MySQLデータベースや7-Zip圧縮をサーバーがどう処理するかまでは教えてくれません。そこで活躍するのがPhoronix Test Suite（PTS）です。これは、数千もの異なるテストプロファイルを個別に実行できる、自動化されたオープンソースのフレームワークです。

PTSのインストール

Ubuntu 22.04または24.04では、最新の.debパッケージを取得できます。PTSは特定のテストに必要な複雑な依存関係を自動的に管理してくれるため、手動インストールよりもこの方法がスマートです。

wget https://phoronix-test-suite.com/releases/repo/pts.debian/files/phoronix-test-suite_10.8.4_all.deb
sudo apt install ./phoronix-test-suite_10.8.4_all.deb

特定のテストを実行する

PTSはベンチマークを「テストスイート」として整理しています。例えば、自動バックアップで一般的なタスクである「CPUが高負荷の圧縮処理をどう扱うか」を測定したい場合は、以下のコマンドを実行します。

phoronix-test-suite run pts/compress-7zip

スイートの実行が終わると、結果を保存するか尋ねられます。必ず「yes」と答え、「AWS-t3-medium-baseline」のように分かりやすい名前を付けてください。これにより、半年後に同じテストを実行して、パフォーマンスが経年劣化していないかを確認できます。

比較の力

ベンチマークは単体では意味をなしません。真の価値は、2つの異なる構成を比較したときに現れます。例えば、IntelベースのVPSとAMD EPYCのインスタンスで迷っているなら、両方でapacheテストを実行し、どちらが高い同時接続ウェブトラフィックをより適切に処理できるかを確認しましょう。

# 両方のサーバーでテストを実行し、結果をマージする
phoronix-test-suite compare-results-to-self [your-saved-result-name]

安定性のための負荷テスト

パフォーマンスとは速度だけではなく、負荷がかかった状態での信頼性も重要です。私はstress-ngスイートを使用して、CPUとメモリを長時間100%の負荷に追い込みます。これにより、ベアメタルサーバーのサーマルスロットリング問題や、クラウドインスタンスの過度なリソース制限を特定できます。

phoronix-test-suite run pts/stress-ng

正確なデータを得るためのプロのコツ

サーバー環境を無視したために、極めて不正確な結果を出してしまっているエンジニアを何度も見てきました。クリーンなデータを得るために、以下のルールを守ってください。

• バックグラウンドのノイズを排除する： 開始前にCronジョブ、Webサーバー、データベースエンジンを停止します。ベンチマークがハードウェアを独占的に使用できるようにしてください。
• 「うるさい隣人（Noisy Neighbors）」に注意する： VPSでは、topを実行して%st（スティールタイム）列を確認してください。テスト中にこの数値が2%を超えた場合、同じ物理ホスト上の他のユーザーがCPUを占有しています。その場合、結果は無効となります。
• 3回実行する： PTSは通常、テストを3回実行して標準偏差を算出します。偏差が5%を超える場合、その環境は信頼できるベンチマークを測定するには不安定すぎます。
• 温度を監視する： 専用サーバー（ベアメタル）では、sensorsコマンドで温度に注意してください。CPUが95℃に達してパフォーマンスが急落した場合、それはソフトウェアのボトルネックではなく、冷却の問題です。

UnixBenchによる簡易チェックとPTSによる詳細分析を組み合わせることで、私はクライアントの新しいストレージアレイに巨大なレイテンシのボトルネックがあることを証明しました。プロバイダーはインスタンスを別のハードウェアノードに移動させ、APIのレスポンスタイムは60ms短縮されました。客観的なデータは、常に勘に勝るのです。