CPUが100%になっている

「概要」タブの CPU グラフに現れるプラトー（平坦な状態）は、それ自体では緊急事態ではありません。プロジェクトのビルドやアーカイブの作成は、すべてのコアを正直に使い切ってから解放します。警戒すべきなのは、プラトーが何時間も続き、マシンが応答しなくなる場合です。何が原因なのかを突き止めましょう。

ステップ 1. 何がリソースを消費しているかを確認する

全画面プログラムを扱うには、「画面」（VNC）タブが便利です：

btop
htop

シリアルコンソールはウィンドウサイズを渡さないため、常に 80×24 となり、インターフェースが途切れてしまいます。テキストコンソールには標準コマンドを使用してください：

top -b -n1 | head -20
ps aux --sort=-%cpu | head -10

計算を覚えておきましょう。%CPU はコアごとに計算されます。VDS-3 での 400% は 4 コアすべてを意味し、VDS-4 での 100% は 6 コアのうち 1 コアにすぎません。

ステップ 2. CPU とディスクを区別する

平均負荷（load average）は、計算だけでなく I/O 待ちによっても上昇します：

uptime
vmstat 1 5

vmstat の出力では、us（ユーザーコード）、sy（カーネル）、wa（ディスク待ち）、st（スチール時間）の各列に注目してください。wa が大きい場合は、CPU がディスクを待ってアイドル状態にあることを意味します。ボトルネックは計算ではなく書き込み速度です。当社の各ティアにおけるディスクのプラトーは、コアあたり書き込み 60 MB/s（60 MB/s を下回らず、400 MB/s を超えない）、読み込みはその 2 倍、プラトーの 3 倍までのバーストは 30 秒間続く、というルールで設定されています。タスクが継続的に書き込みを行うと、バーストは終了し、プラトーに達します。

ステップ 3. 特定のプロセスを調査する

pidstat -p <pid> 1 5
cat /proc/<pid>/status
journalctl -u <service> -n 100 --no-pager

よくある発見：

• Web アプリケーションが、失敗したリクエストの後で無限ループに陥っている；
• データベースがインデックスなしのクエリを実行している — データベース自身のスロークエリログを確認してください；
• cron ジョブが完了できる頻度よりも多く起動し、インスタンスが蓄積している：ps aux | grep <name> で十数個のコピーが表示されます；
• 脆弱な root パスワードを通じてマシンに侵入したマイナー。兆候は、無意味な名前のプロセスが標準外のユーザーで実行され、送信帯域幅が大きいことです。この場合は、「アクセス」タブからマシンを再インストールするほうが、クリーンアップするよりも簡単です。

ステップ 4. 強制終了ではなく制限する

プロセスが必要だが、他の処理を妨げるべきでない場合：

renice -n 15 -p <pid>
systemctl set-property myapp.service CPUQuota=200%

CPUQuota=200% は 2 コア分です。systemd の制限はサービスの再起動後も維持されますが、renice は維持されません。

kill -9 でプロセスを強制終了する前に、通常の systemctl stop を試してください。データベースを強制終了すると、ファイルが破損し、次回起動時に長時間の復旧が必要になります。

コードが原因でない場合

負荷が正当かつ一定であれば、Ryzen 9 7950X の CPU はその役割を果たしています — 単にタスクに対してコアが足りていないだけです。ティアは上位にのみ変更でき、支払済み期間の残り日数分を追加で支払います。詳しくは記事プランのアップグレードと差額のお支払いをご覧ください。下位へのダウングレードはできませんので、まず週と月のグラフでプラトーが一時的なものではないことを確認してください。