こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回の第2回では、ストレージの基礎からLVM（PV/VG/LV）の構築、そして無停止でのオンライン拡張手法を学びました。
サーバーの土台となるストレージが整ったら、次はサーバーの「頭脳」と「心臓部」であるリソースを正常に保つための技術を学びます。第3回で取り上げるのは、「リソース監視とパフォーマンスチューニング（CPU・メモリ）」です。
「サーバーが何となく重い」「Webページの表示が遅延している」といった抽象的な障害が発生したとき、プロのインフラエンジニアは感覚ではなく、正確なメトリクス（数値）を元にボトルネックを特定します。今回は、AlmaLinux 9/10環境においてCPUとメモリの健康状態を深く見極め、トラブルを未然に防ぐための実践的な監視・チューニング手法を徹底解説します。
先生大変です！昨日から運用しているWebアプリサーバーのレスポンスが急に悪くなって、ユーザーからクレームが来てるんです……！でも、CPU使用率を見てもそこまで高くないし、原因がさっぱり分かりません。こういうときって、どうやって調べればいいんですか？
落ち着きなさい、コウ君。CPU使用率が低いからといって、システムが健康とは限らないのがインフラの奥深いところよ。
表面的な数字に惑わされず、ロードアベレージ、I/O待ち、メモリのページキャッシュ、そしてスワップの発生状況まで複合的に見て初めて真の原因が見えてくるの。今日の記事を読めば、その謎をロジカルに解き明かせるようになるわよ！
📚 本連載のカリキュラム（全8回）
目次
1. CPUボトルネックの真相：ロードアベレージとCPUステータスの詳細分析
サーバーのパフォーマンス低下を検知したとき、エンジニアが真っ先に確認すべき指標が「ロードアベレージ（Load Average）」です。前回の第1回でも触れましたが、今回はより深くその意味とトラブルシューティングへの応用を解説します。
$ uptime 14:20:15 up 15 days, 4:12, 2 users, load average: 3.85, 2.10, 1.05
ロードアベレージは「直近の1分、5分、15分における、CPUの処理を待っている（または処理中である）プロセスの平均数」を示します。
ここで重要なのは、「ロードアベレージの数値単体では高負荷かどうかを断定できない」という点です。評価基準となるのは、サーバーが搭載している「論理CPUコア数」です。
論理CPUコア数の確認方法
サーバーのCPUコア数は、以下のコマンドで一発で確認できます。
grep -c ^processor /proc/cpuinfo
もし論理コア数が「2」の環境でロードアベレージが「3.85」であれば、CPUの処理能力を超えたタスクが常に1.85個分あふれ返り、システム全体が深刻な遅延（キューイング遅延）に陥っていると判断できます。反対に、8コアの環境であれば「3.85」は十分に許容範囲内の数値です。
topコマンドによる詳細内訳の分解
ロードアベレージが高い原因がどこにあるのかを特定するため、top コマンドを実行し、CPUステータス行（%Cpu(s)）を細かく分解して観察します。
top - 14:25:00 up 15 days, 4:17, 2 users, load average: 4.10, 3.20, 2.50 Tasks: 140 total, 1 running, 139 sleeping, 0 stopped, 0 zombie %Cpu(s): 65.0 us, 15.0 sy, 0.0 ni, 10.0 id, 8.0 wa, 0.0 hi, 2.0 si, 0.0 st
- us (User): Apache、Nginx、PHP-FPM、データベースなどのユーザープロセスがCPUを消費している割合。プログラムのアルゴリズム最適化やクエリチューニングが必要なサインです。
- sy (System): OSのカーネル内部で処理されている割合。システムコールやコンテキストスイッチが異常に頻発している場合に高騰します。
- wa (I/O Wait): CPUが「ストレージ（ディスク）からのデータ読み書きの完了」を待たされている割合。この値が20%を超える場合、CPUではなくディスクが完全にボトルネックになっています。いくらCPUの性能を上げても解決しません。
- st (Steal): クラウドやVPS環境において、物理ホスト上の他の仮想マシンにCPUリソースを奪われた割合。これが常時高い場合はホスト側の過密化が疑われます。
2. vmstatコマンドを駆使したシステム全体の俯瞰とI/Oボトルネック
top コマンドはリアルタイムのプロセス監視に優れていますが、システム全体の傾向を時系列で把握するには vmstat（Virtual Memory Statistics）コマンドが極めて強力です。
# 2秒間隔で5回、システム統計を出力する vmstat 2 5
実行すると、以下のような形式でメモリ、スワップ、I/O、CPUの統計が1行ずつ出力されます。
procs -----------memory---------- ---swap-- -----io---- -system---- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 3 1 0 412500 12400 4521000 0 0 120 450 850 1200 55 12 23 10 0
vmstatの見るべき重要ポイント
- procsの「r」と「b」：
r（Run）：CPUの実行キューに並んでいるプロセスの数。これがCPUコア数を超えていると過負荷です。b（Block）：I/O待ちやディスク書き込み待ちでブロックされているプロセスの数。ここが常に1以上である場合、ストレージの性能限界に達しています。
- ioの「bi」と「bo」：
bi（Blocks In）：ディスクから読み込んだブロック数。bo（Blocks Out）：ディスクへ書き込んだブロック数。データベースの大量書き込みやログの暴走などが起きていないかを検知できます。
3. Linuxメモリ管理の基本哲学：空きメモリとページキャッシュの誤解
CPUの次は、メモリ管理の深層に迫ります。Linuxサーバーを運用するうえで、初心者が最も誤解しやすいのが「メモリ使用量」の見方です。free -h コマンドを実行した際に出力される各項目の意味を正確に理解する必要があります。
$ free -h
total used free shared buff/cache available
Mem: 7.6Gi 6.8Gi 350Mi 45Mi 6.1Gi 1.2Gi
Swap: 2.0Gi 0B 2.0Gi
⚠️ 「freeが少ない＝危険」ではない理由
上記の出力を見ると、free（完全な空きメモリ）はわずか 350MiB しかありません。「もうすぐメモリが枯渇する！」と焦ってしまいそうになりますが、これはLinuxでは完全に正常な状態です。
Linuxカーネルは「使われていないメモリは無駄である」という設計思想を持っており、ディスクから読み込んだファイルの中身を積極的にメモリ上に残しておき（これが buff/cache の 6.1GiB）、次回同じファイルにアクセスされたときにディスクを読まずに超高速で応答できるように最適化しています。
そのため、システムが健康かどうかを判断する基準は free ではなく、右端の available（利用可能メモリ） です。この値が十分に確保されていれば（この例では1.2GiB）、アプリケーションが新たにメモリを要求してもカーネルがキャッシュを即座に解放するため、メモリ不足には陥っていません。
 | 本気で学ぶ Linux実践入門 サーバ運用のための業務レベル管理術 [ 大竹龍史 ] 価格:3278円 |
4. スワップ領域の恐怖とOOM Killerが発動するメカニズム
前述の available メモリすらも完全に枯渇し、アプリケーションの要求を物理メモリだけで処理しきれなくなったとき、Linuxカーネルは補助的な記憶領域である「スワップ（Swap）」領域を使い始めます。
スワップが発生すると何が起きるか？
スワップ領域は、ハードディスクやSSDの一部を擬似的なメモリとして使う仕組みです。しかし、RAM（物理メモリ）と比べるとストレージの読み書き速度は圧倒的に遅いため、メモリとスワップの間で頻繁にデータの入れ替え（スワップイン／スワップアウト）が発生すると、システム全体の処理速度が急激に低下する「スラッシング（Thrashing）」という致命的なパフォーマンス劣化を引き起こします。
最終防衛ライン：OOM Killerの強制介入
スワップ領域すらも満杯になり、物理・仮想ともにメモリの空きが完全にゼロになった瞬間、Linuxカーネルはシステムの完全なクラッシュ（カーネルパニック）を防ぐための最終手段を発動させます。それが OOM Killer（Out Of Memory Killer） です。
カーネルは内部のスコアリングアルゴリズム（oom_score）に基づき、最もメモリを大量消費しているプロセスを特定し、容赦なく強制終了（SIGKILL）信号を送ってプロセスを葬り去ります。Webアプリケーション環境において、運悪くMySQLやPHP-FPMのマスタープロセスがターゲットに選ばれてしまうと、サービスが突然停止する重大インシデントに発展します。
5. プロのための実践パフォーマンスチューニング手法
リソースの枯渇やボトルネックを検知した際、プロのインフラエンジニアが実行する具体的なチューニング手法をいくつか紹介します。
① swappinessの調整（不必要なスワップの抑制）
Linuxカーネルはデフォルトで、メモリにまだ余裕がある段階でも積極的にスワップを使おうとする傾向があります（swappiness=60）。これを調整し、限界まで物理メモリを使い切るように設定変更します。
# 現在の設定値を確認 cat /proc/sys/vm/swappiness # 一時的にスワップの積極性を下げる（例: 値を10にする） sudo sysctl vm.swappiness=10 # 恒久化する場合は /etc/sysctl.conf に追記する echo "vm.swappiness=10" | sudo tee -a /etc/sysctl.conf
② ページキャッシュの解放（緊急時の手動フラッシュ）
メモリ不足が疑われる緊急時、不要なキャッシュを手動で解放し、一時的に available を回復させることができます（本番環境での常用は避けてください）。
# ページキャッシュ、dentry、inodeを解放する sync && echo 3 | sudo tee /proc/sys/vm/drop_caches
③ プロセスごとのメモリ消費量ランキングの把握
どのプロセスがメモリを食い潰しているかを正確に把握するには、以下の ps コマンドが非常に役立ちます。
# メモリ使用率が高い順に上位10プロセスを表示する ps aux --sort=-%mem | head -n 11
総まとめ：メトリクスの相関関係を読み解く力
第3回の解説、お疲れ様でした。
今回は、AlmaLinux 9/10環境におけるCPUのロードアベレージ・I/O待ち、メモリのページキャッシュの概念、スワップとOOM Killerの恐怖、そして実務で使えるパフォーマンスチューニング手法を網羅しました。
インフラ運用において、単一の数字だけで判断を下すことは禁物です。CPU、メモリ、ディスクの各メトリクスがどのように連動しているかを多角的に読み解く力こそが、プロのエンジニアの証です。
次回、【第4回】ログ管理とjournalctlを駆使したトラブルシューティング では、システムやアプリケーションの挙動を完全に把握し、障害発生時に素早く原因を特定するためのログ運用の極意を深く掘り下げていきます。
お楽しみに！LINUX工房の「リナックス先生」でした。
▼ 【高負荷に耐える安定インフラ環境を構築しよう】 ▼
CPU・メモリリソースに余裕のある
「高コスパおすすめVPS」
パフォーマンスチューニングを武器に
「ITエンジニア専門転職」
コメント