サーバーがダウンしてから慌てて原因を探すのはもうやめよう
内部テストではスムーズに動いていたサーバーが、ピーク時になるとトラフィックが20〜30%増えただけで急に重くなったり、最悪の場合504エラーを連発したりした経験はありませんか?私は以前、CentOS 7で稼働していた古いサーバー群を引き継いだ際に、苦い経験をしました。
CPUやRAMのスペックは一見十分に見えましたが、運用開始からわずか1週間でシステムがダウンしてしまいました。原因は、アイドル状態では気づかなかったメモリリークで、負荷が80%を超えた時に初めて表面化したのです。
それ以来、私の鉄則は「本番環境にサービスを投入する前に、stress-ngでハードウェアを徹底的に『痛めつける』こと」です。このツールを使えば、最も過酷な負荷シナリオをシミュレートできます。CPUの過熱、RAMの不具合、あるいはディスクI/Oの速度不足など、システムのボトルネックがどこにあるのかを正確に把握できるようになります。
なぜstress-ngが最適なのか?
従来のstressコマンドが基本的なものだとすれば、stress-ngはまさに「モンスター」です。これはLinuxのサブシステムを限界まで追い込むために設計された、強力なオープンソースプロジェクトです。200種類以上のテスト項目(stressors)を備えており、浮動小数点演算から仮想メモリ、Linuxカーネルのシグナル処理に至るまで、あらゆる箇所に深く介入できます。
大きな違いは、単にCPUに負荷をかけるだけでなく、特殊な命令セットや複雑なメモリ割り当てパターンもテストできる点にあります。これらは、一般的なツールでは見落とされがちな要素です。
30秒で完了するインストール
主要なLinuxディストリビューションの公式リポジトリには、ほとんどの場合stress-ngが含まれています。
UbuntuまたはDebianの場合:
sudo apt update && sudo apt install stress-ng -y
AlmaLinux、Fedora、またはCentOSの場合:
sudo dnf install stress-ng -y
実践的な負荷テスト(Stress Test)シナリオ
1. CPU負荷テスト(温度とクロック周波数の検証)
このテストでは、冷却システムが安定しているかを確認できます。負荷100%時にサーマルスロットリング(熱による性能抑制)が発生すると、スペック上の数値は足りていてもサーバーの動作が目に見えて遅くなります。
stress-ng --cpu 4 --timeout 60s --metrics-brief
--cpu 4: 4つのワーカーを同時に実行(通常、CPUのコア数に合わせます)。--timeout 60s: フリーズを防ぐため、1分後に自動停止。--metrics-brief: 終了後に簡潔なパフォーマンスレポートを表示。
より高負荷をかけたい場合は、行列演算アルゴリズムを試してみてください:
stress-ng --cpu 2 --cpu-method matrix --timeout 30s
2. RAMの限界テスト
メモリ関連のエラーは、システムクラッシュの主な原因です。stress-ngはRAMの確保と解放を繰り返し、メモリセルの不良やスワップの問題をあぶり出します。
stress-ng --vm 2 --vm-bytes 1G --timeout 60s
上記のコマンドは2つのワーカーを起動し、それぞれ1GBのRAMを消費します。注意点として、テストする合計容量は実メモリの90%を超えないようにしてください。さもないと、LinuxのOOM Killerの忍耐力を試すことになってしまいます。
3. ディスク読み書き(I/O)速度の検証
安価なVPSではI/Oリソースが共有されていることが多く、ボトルネックになりがちです。ストレージが宣伝通りの速度を出せているか確認しましょう。
stress-ng --io 4 --io-ops 1000 --timeout 60s
OSのキャッシュを通さずに実速度を測定するには、directオプションを使用します:
stress-ng --hdd 1 --hdd-opts direct,sync --timeout 60s
実践的な経験:フルロードシナリオ
現実の運用では、特定のコンポーネントだけが過負荷になることは稀です。アクセスが集中したウェブアプリは、ロジック処理でCPUを、キャッシュ保持でRAMを、ログ記録でディスクを同時に消費します。私は新しいVPSを借りた際、スペック通りか確認するために以下のコマンドをよく使います:
stress-ng --cpu 2 --io 1 --vm 1 --vm-bytes 512M --timeout 5m --metrics
このコマンドを実行しながら、別のターミナルでhtopを開いてみてください。ロードアベレージ(Load Average)に注目しましょう。2コアのサーバーで5.0など高い数値を示していても、SSHの操作が快適であれば、そのサーバーは非常に信頼できると言えます。
重要な警告: 稼働中のサーバー(本番環境)でstress-ngを実行してはいけません。リソースが占有され、ユーザーが即座にサービスにアクセスできなくなります。必ずステージング環境で実施してください。
まとめ
stress-ngは単なる負荷ツールではなく、管理者の自信を測る「物差し」です。システムがダウンしないよう祈るのではなく、事前にサーバーの限界を知ることで、状況を常にコントロールできるようになります。サーバーが不自然に重いと感じたら、stress-ngを使ってCPU、RAM、ディスクのどこに問題があるか切り分けてみましょう。

