リソース監視（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不足、というように、複数の指標を時系列で突き合わせることで、詰まっている場所をかなり正確に絞り込めます。
実務での使いどころ
実際の調査では、これらを順に重ねます。まず uptime か top でロードアベレージを見て混み具合を把握し、CPUが原因か（top の us/sy が高い）、メモリが原因か（free の available が枯渇・Swap が増加）、I/Oが原因か（top の wa が高い）を切り分けます。確証が欲しいときは vmstat 1 を数十秒流して、どの指標が異常かを時系列で確認します。1行目は起動からの平均値なので、実際の今の動きは2行目以降を読むのがコツです。ここまでで「何が」ボトルネックかが見えたら、次のステップで「どのプロセスが」その資源を食っているのかを特定する、という流れに進みます。この全体俯瞰を最初に挟むかどうかで、その後の調査の速さと正確さが大きく変わります。