リソース監視（CPU・メモリ・負荷）
サーバが重いと感じたら、まずCPU・メモリ・負荷の3点を見ます。uptime や top でロードアベレージを確認し、CPUコア数を超えて高止まりしていれば処理が詰まっています。free でメモリと空き容量、スワップの使用量を見て、メモリ不足の兆候がないか確かめます。vmstat を数秒間隔で流すと、CPU待ち・I/O待ち・スワップの動きが時系列でつかめ、どこが詰まっているかの当たりが付きます。
「サーバが重い」「アプリの反応が遅い」――運用でいちばんよく出会うのが、この相談だ。
難しいのは、『重い』と一口に言っても中身がまるで違うことだ。計算が忙しいのか、メモリが足りないのか、ディスクの読み書き待ちなのか。原因がまったく異なれば、対処も変わる。
そこで重さを感じたら、まずはCPU・メモリ・負荷という3つの観点から全体像をつかみ、どこが詰まっているか（ボトルネック）の当たりを付ける。
いきなり個別のプロセスを疑う前に、この3点をざっと見ておく。そうすると、調査の方向を大きく外さずに済む。
📊 ロードアベレージが語る数字
最初の手がかりがロードアベレージ（負荷平均）だ。これは「実行したいのに待たされているタスクが平均で何個あったか」を表す数値で、システム全体の混み具合の目安になる。
uptime を打つと、行末に load average: 0.52, 0.48, 0.45 のように3つの数字が出る。これは左から順に、過去1分・5分・15分の平均値だ。
直近1分が大きく、15分が小さければ「今まさに混み始めた」、逆なら「混雑が収まりつつある」と、時間変化まで読める。top や htop の画面上部でも同じ値を確認できる。
だが、この数字だけを眺めても「高いのか低いのか」は判断できない。
ロードアベレージを読むときの勘どころは、CPUのコア数と比べることだ。値がコア数とほぼ同じなら「ちょうど使い切っている」状態、コア数を大きく超えて高止まりしていれば「処理しきれずタスクが渋滞している」状態だ。
コア数は nproc コマンドや、grep -c processor /proc/cpuinfo で確認できる。
たとえば4コアのサーバでロードアベレージが常時8や10なら、明らかに過負荷で、各タスクが順番待ちで待たされている状態だ。逆に8コアでロードアベレージが2程度なら、まだ十分に余裕があると判断できる。
ただしロードアベレージは、CPUの忙しさだけでなくディスクI/O待ちのタスクも数に含める。そのため「値は高いのにCPU使用率は低い」こともある。その場合はCPUではなくI/Oやスワップが原因と読み替える。
🖥 CPUとメモリの内訳を top で見る
全体の混み具合が分かったら、その中身を top で見る。top は画面を一定間隔で更新し続け、負荷の高いプロセスが上位に並ぶよう自動で並び替わる。
画面上部の %Cpu(s) の行には、CPU時間の内訳が us（ユーザプログラム）、sy（カーネル）、id（アイドル＝空き）、wa（I/O待ち）などのパーセンテージで表示される。
us と sy が高ければ計算そのものが重く、id が低くて wa が高ければ、CPUは暇なのにディスクの読み書き待ちで詰まっている、と読み分けられる。
より見やすく、色付きでコアごとの使用率も並ぶ htop が入っていれば、そちらを使うとさらに状況をつかみやすくなる。
🧠 free の数字は、少なくても慌てるな
メモリの状況は free で確認する。free -h と人間に読みやすい単位を付けて実行すると、total（総量）・used（使用中）・free（完全な空き）・available（実際に割り当て可能な量）が表形式で出る。
ここで初学者がつまずきやすいのが、free の値が小さくても慌てなくてよいという点だ。
Linuxは空きメモリをディスクキャッシュ（buff/cache）として有効活用する。そのため free が少なく見えるのは、正常な動作なのだ。
メモリに本当に余裕があるかは、free ではなく available の値で判断する。available が十分にあれば、まだ余裕がある。
本当に注意すべきはスワップだ。スワップとは、物理メモリが足りなくなったときに、その一部をディスク上の領域へ一時的に退避させる仕組みである。
free の Swap 行の used が増え続けていたら、メモリ不足の危険信号だ。
ディスクはメモリより桁違いに遅い。だからスワップが多発すると、メモリとディスクの間でデータの出し入れが頻発し、システム全体が極端に遅くなる（スラッシングと呼ばれる状態）。
「ロードアベレージは高いのにCPUは暇」「全体がもっさり遅い」というときは、このスワップの多発を真っ先に疑う。
🎞 「動き」を見たいときの vmstat
瞬間値だけでは分からない「動き」を見たいときは vmstat が便利だ。vmstat 1 のように秒数を引数で渡すと、1秒ごとに1行ずつ統計を出力し続ける。
注目する列は次のとおりだ。procs の r（実行待ちのプロセス数）と b（I/O待ちでブロックされた数）。swap の si/so（スワップの読み込み・書き出し量。ここが常に0でなくなったらスワップ多発のサイン）。io の bi/bo（ディスクの読み書き量）。cpu の us/sy/id/wa。
たとえば wa が高く bi/bo も大きければI/Oがボトルネック、si/so が増えていればメモリ不足、r が常にコア数を超えていればCPU不足、というように読む。複数の指標を時系列で突き合わせることで、詰まっている場所をかなり正確に絞り込める。
🧰 3つの道具を重ねる
実際の調査では、これらを順に重ねる。
まず uptime か top でロードアベレージを見て混み具合を把握する。そして、CPUが原因か（top の us/sy が高い）、メモリが原因か（free の available が枯渇・Swap が増加）、I/Oが原因か（top の wa が高い）を切り分ける。
確証が欲しいときは vmstat 1 を数十秒流して、どの指標が異常かを時系列で確認する。1行目は起動からの平均値なので、実際の今の動きは2行目以降を読むのがコツだ。
ここまでで「何が」ボトルネックかが見えたら、次のステップで「どのプロセスが」その資源を食っているのかを特定する、という流れに進む。
この全体俯瞰を最初に挟むかどうかで、その後の調査の速さと正確さが大きく変わる。