はじめに
Linuxサーバーを運用していると、「サービスが遅い」「レスポンスが不安定」といったパフォーマンス問題に直面することがあります。
こうした問題の多くは、サーバーのリソース不足やボトルネックが原因です。
本記事では、CPU・メモリ・ディスクI/O・ネットワークの観点から、Linuxサーバーのパフォーマンスを監視し、ボトルネックを解消する方法を解説します。
目次
- 監視の基本方針
- CPU負荷の監視と分析
- メモリ使用量の監視と最適化
- ディスクI/Oの監視と改善
- ネットワーク負荷の監視
- 継続的な監視と改善サイクル
1. 監視の基本方針
パフォーマンス改善の第一歩は「現状把握」です。
サーバーの負荷をリアルタイムで確認しつつ、履歴データを収集することが重要です。
・CLIツールでのリアルタイム監視
・監視ツールでの履歴分析（Prometheus, Grafana, Zabbixなど）
まずは簡単なコマンドでサーバーの状況を把握してみましょう。
2. CPU負荷の監視と分析
CPU負荷の監視と分析は、システム全体のパフォーマンスを把握し、ボトルネックとなる要因を特定するために重要です。
適切な監視コマンドを用いてCPUやプロセスの状態を継続的に確認することで、異常の早期発見や安定運用につなげることができます。
本項では、代表的な監視ツールの使い方と、負荷が高い場合の典型的な原因および改善策について解説します。
1）監視コマンド
top
|
1 2 3 4 5 6 7 8 9 10 11 |
$ top top - 12:30:01 up 10 days, 3:22, 3 users, load average: 0.75, 0.80, 0.85 Tasks: 150 total, 1 running, 149 sleeping, 0 stopped, 0 zombie %Cpu(s): 12.5 us, 3.2 sy, 0.0 ni, 84.0 id, 0.2 wa, 0.0 hi, 0.1 si, 0.0 st MiB Mem : 15974.0 total, 8243.0 free, 4321.0 used, 3410.0 buff/cache MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 9876.0 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2345 apache 20 0 123456 3456 1234 S 25.0 0.02 5:12.34 httpd 3456 mysql 20 0 654321 12345 4321 S 15.0 0.08 12:34.56 mysqld 4567 user1 20 0 234567 4567 2345 R 5.0 0.03 0:01.23 python |
→%CPU が高いプロセスがボトルネック候補 ※上記であれば一番高いプロセスはapachの25%
→R は実行中、S はスリープ中
→load average が CPU コア数以上なら要注意
load average: 0.75, 0.80, 0.85 ※CPUが4コアとかであれば、余裕があるという見方になります。
htop
|
1 2 3 4 |
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 2345 apache 20 0 123M 3.3M 1.2M S 25 0.02 5:12.34 httpd 3456 mysql 20 0 654M 12.0M 4.3M S 15 0.08 12:34.56 mysqld 4567 user1 20 0 234M 4.5M 2.3M R 5 0.03 0:01.23 python |
htop はtopコマンドよりも色分けで CPU、メモリ使用量が見えたりと視覚的に分かりやすく確認したいときに使うコマンドです
2）ボトルネック例
■特定プロセスがCPUを占有している
例）
Webサーバーで、画像処理や暗号化処理を行うプログラムが暴走
→topやhtopを見ると、1つのプロセスがCPU使用率90〜100%を維持
→他の処理（リクエスト処理やバッチ）が遅延
※原因
- 無限ループや非効率なアルゴリズム
- 並列化されていない重い処理
■ロードアベレージが高い（コア数超え）
例）
- 4コアのサーバーでロードアベレージが「8.5」
- リクエストが急増して、処理待ちプロセスが大量発生
- CPU使用率は100%近い or I/O待ちで詰まっている
※状況
- 実行待ちのプロセスが多すぎる
- CPUまたはディスクI/Oがボトルネック
3）改善策
■不要プロセスの停止
無駄にCPU・メモリを使っているプロセスを止めて、リソースを解放します。
▼よくあるケース
- 暴走したスクリプト（無限ループ）
- 使っていない常駐サービス
- デバッグ用プロセスの消し忘れ
■CPU増設（スケールアップ）
物理的にCPUリソースを増やして、処理能力の上限を引き上げる
▼具体例
- 2コア → 8コアのサーバーへ変更
- クラウドでインスタンスサイズを上げる
CPU負荷の監視は、システムの状態を把握し、問題を早く見つけるために重要です。
topや htopを使えば、CPU使用率や動いているプロセスを簡単に確認できます。
負荷が高い場合は、特定のプロセスの暴走や処理の集中が原因であることが多く、不要なプロセスの停止や処理の見直し、必要に応じたCPUの増強によって改善できます。
3. メモリ使用量の監視と最適化
メモリ使用量の監視は、システムの安定性とパフォーマンスを維持するうえで非常に重要です。
適切なコマンドを用いてメモリの使用状況やスワップの発生有無を把握することで、メモリ不足や無駄なリソース消費といった問題を早期に発見できます。
本章では、代表的な監視コマンドの見方と、メモリに関するボトルネックの原因およびその改善方法について解説します。
1）監視コマンド
free -h
free -hは、メモリ（RAM）とスワップの使用状況を確認するコマンドです。
|
1 2 3 4 |
$ free -h total used free shared buff/cache available Mem: 16Gi 4.1Gi 7.9Gi 240Mi 4.2Gi 11Gi Swap: 2.0Gi 0B 2.0Gi |
✔ 読み方
- used 4.1Gi … 実際にプロセスが使用しているメモリ
- buff/cache 4.2Gi … Linux のキャッシュ（空き扱いに近い）
- available 11Gi … 実質ここが「使えるメモリ量」
- Swap が 0B → スワップしてない
vmstat 2
vmstat 2 は、システムのリソース状況（CPU・メモリ・I/Oなど）を2秒ごとに表示するコマンドです。
|
1 2 3 4 5 6 |
$ vmstat 2 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 812345 56789 340000 0 0 2 3 120 230 5 2 92 1 0 2 0 0 798234 56790 341200 0 0 1 2 118 240 7 3 89 1 0 1 0 0 800111 56790 342000 0 0 1 1 122 235 6 2 91 1 0 |
✔ 読み方
| 項目 | 意味 | 状態 |
| r | 実行待ちプロセス数 | CPUコア数より多いと詰まり |
| si / so | スワップイン・アウト | 0以外が続く＝メモリ不足 |
| bi / bo | ディスク/IO | 過度に高いとI/Oボトルネック |
| us | ユーザーCPU | アプリが使っているCPU |
| sy | システムCPU | カーネル処理、過度に高いのは問題 |
| id | アイドル率 | 低い＝負荷高い |
| wa | I/O待ち | 高いと「ディスク遅い」 |
smem
プロセスごとのメモリ使用量を詳しく見るコマンドです
|
1 2 3 4 5 6 |
$ smem PID User Command Swap USS PSS RSS 2345 apache /usr/sbin/httpd 0 22000 25000 48000 3456 mysql /usr/libexec/mysqld 0 450000 470000 520000 4567 nginx nginx: worker process 0 18000 21000 40000 5678 user1 python app.py 0 90000 110000 150000 |
✔ smem で重要な指標
| 項目 | 重要度 | 意味 |
| USS | ★★★★★ | そのプロセス専用のメモリ。実メモリ使用量に最も近い |
| PSS | ★★★★☆ | 共有メモリを按分した実質使用量 |
| RSS | ★★☆☆☆ | 単純な割り当てメモリ量。高めに出ることが多い |
実際の「そのプロセスが使っているメモリ」を見るならUSSとPSSを信頼します。
上の例なら、MySQLが一番大きくなります（PSS ≒ 470MB）
2）ボトルネック例
■スワップが頻繁に発生するとパフォーマンスが低下
→スワップ多発 = メモリ不足 → ディスク待ち増加 → パフォーマンス低下
■メモリ不足でアプリが不安定になる
▼よくある現象まとめ
- アプリが突然落ちる
- レスポンスが不安定（速い→遅いの波）
- タイムアウト増加
- 接続エラー増える
▼監視で見るべきポイント
free -h→ available が少ないvmstat→ si / so が増える
3）改善策
■不要プロセスのメモリ解放
「不要プロセスのメモリ解放」は、
👉 使っていない（または異常な）プロセスを停止してメモリを空けることです。
▼具体例
🖥 状況
- メモリ：16GB
- ほぼ満杯
smem/topで確認すると
|
1 2 3 4 |
PID USER COMMAND メモリ 3456 user1 python app.py 1.5GB 4567 user1 python app.py 1.5GB 5678 user1 python app.py 1.5GB ← 放置された古いプロセス |
→同じアプリが複数起動していることが確認できます。
▼対処方
不要なプロセスを停止
|
1 |
$ kill 5678 |
※本当に消していいプロセスか判断は重要
※必要に応じてメモリ増設も検討する
4. ディスクI/Oの監視と改善
ディスクI/Oは、アプリケーションの応答速度やシステム全体のパフォーマンスに大きな影響を与える重要な要素です。
特にデータベースやログ書き込みが多い環境では、I/Oの遅延や負荷の集中がボトルネックとなりやすく、CPUやメモリに余裕があっても処理が滞る原因になります。
本章ではiostatやiotopなどのコマンドを用いたディスクI/Oの監視方法を理解し、ボトルネックの特定から具体的な改善策までを体系的に解説します。
1）監視コマンド
iotop（I/O負荷の高いプロセス確認）
|
1 2 3 4 5 6 7 |
$ iotop Total DISK READ : 12.35 M/s | Total DISK WRITE : 5.47 M/s Actual DISK READ: 11.98 M/s | Actual DISK WRITE: 5.12 M/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 2310 be/4 mysql 8.35 M/s 3.12 M/s 0.00 % 15.22 % mysqld --daemonize 1255 be/4 www-data 3.10 M/s 0.80 M/s 0.00 % 5.33 % php-fpm: pool www 2890 be/4 root 0.50 M/s 1.20 M/s 0.00 % 2.43 % journalctl --flush |
🔍 ポイント
▼mysqld が 8.35 M/s の READ と 3.12 M/s の WRITE
→ データベース（MySQL）がたくさんデータを読み書きしています
→ 他のプロセスよりもディスクを多く使っているため、主な負荷の原因になっている可能性が高いです
▼IO%（IO>）が 15%
→ CPUは常に動いているわけではなく、ディスクの読み書き待ちで止まる時間があります
→ この15%は「ディスク待ちで何もできずに待っている時間」の割合です
df -h（ディスク使用率確認）
|
1 2 3 4 5 6 |
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/nvme0n1p1 100G 68G 28G 72% / /dev/nvme1n1p1 200G 45G 141G 25% /var/lib/mysql tmpfs 32G 1.2G 31G 4% /run tmpfs 64G 0G 64G 0% /dev/shm |
🔍 ポイント
各項目の見方
- Size：ディスクの総容量
- Used：使っている容量
- Avail：空き容量
- Use%：使用率（どれくらい埋まっているか）
- Mounted on：どこで使われているか（フォルダ）
今回の状態
/（ルート領域） 72%
→ OSやアプリが入っている重要な場所
→ まだ余裕はあるが、80%を超えると注意レベル
/var/lib/mysql 25%
→ データベース用のディスク
→ かなり余裕あり（問題なし）
tmpfs
→ メモリ上に作られる一時領域（ディスクではない）
→ 使用率も低く正常
2）ボトルネック例
■高I/Oプロセスがボトルネック
→ 一部のプログラム（例：データベースやログ処理）が、たくさんディスクを使いすぎている状態です
→ ディスクの読み書きが集中すると、他の処理も待たされて全体が遅くなります
確認ポイント（iotop）
- DISK READ / WRITE が他より明らかに多い
- IO%（IO>）が高い
目安
- IO% が 10%以上 → 少し影響あり
- IO% が 20%以上 → 明らかに遅延の原因
- IO% が 30%以上 → かなり危険（要対応）
3）改善策
■SSDへの変更 / RAID構成の見直し
● SSDにする理由
HDDは「物理的に回転＋ヘッド移動」があるため、ランダムI/Oが非常に遅いです。
一方SSDは電気的アクセスなので、数十〜数百倍速いケースもあります。
- HDD：ランダムアクセス弱い（DB・ログ系で詰まりやすい）
- SSD：ランダムアクセス強い（I/O待ち激減）
👉 特に効果が大きいケース
- データベース（MySQL / PostgreSQL）
- ログ書き込みが多いシステム
- 小さいファイルを大量に扱う処理
● RAID構成の見直し
RAIDは「冗長性 or 速度」を調整する仕組み。
- RAID0：高速（ただし壊れやすい）
- RAID1：ミラーリング（安全だが書き込み遅め）
- RAID5/6：バランス型（書き込みにペナルティあり）
- RAID10：速度と耐障害性のバランスが良い（実務でよく使う）
👉 改善ポイント
- 書き込みが多い → RAID10にする
- 読み込み中心 → RAID5でもOK
- IOPS不足 → ディスク本数を増やす
■I/O負荷の分散
● ジョブスケジューリング
重い処理を「同時に実行しない」ことでI/O競合を防ぐ。
例：
- バッチ処理を深夜にずらす
- cronの実行時間を分散
👉 効果
- ディスク待ち（iowait）が減る
- スパイク負荷の回避
● パーティショニング
データを分割してI/Oを分散する。
- DB：テーブルパーティション（日時・ID単位）
- ファイル：ディレクトリ分割
👉 例
- ログを1ファイルにまとめない
/logs/2026/04/のように分割
👉 効果
- 同時アクセスの競合減少
- 検索・読み込みの高速化
■キャッシュ利用
● 目的
「毎回ディスクを読まない」ようにする
👉 ボトルネックの本質
ディスクI/Oが遅い → 「そもそも読まない」
● Redis
- メモリ上にデータを保持
- 超高速（マイクロ秒レベル）
👉 使いどころ
- DBクエリ結果のキャッシュ
- セッション管理
- 頻繁に読む設定値
5. ネットワーク負荷の監視
ネットワークはシステム全体のパフォーマンスに直結する重要な要素であり、帯域の逼迫や通信エラー、
過剰な接続数はレスポンス低下やサービス停止の原因となります。
本章では、ネットワーク負荷の状態を把握するための基本的な監視コマンドと、その結果の見方を解説し、
ボトルネックの特定および改善に向けたアプローチを紹介します。
1）監視コマンド
netstat -i（インターフェース統計）
|
1 2 3 4 5 6 |
$ netstat -i Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 9823456 0 2 0 11234567 0 0 0 BMRU eth1 1500 123456 0 0 0 234567 0 0 0 BMRU lo 65536 503210 0 0 0 503210 0 0 0 LRU |
🔍 ポイント
- estab 45 → 現在確立済み TCP 接続が 45（Web サーバなら普通）
- closed 1250 → TIME_WAIT/FIN_WAIT の履歴
- synrecv 3 → SYN flood の気配は無し（異常は100〜になる）
iftop（リアルタイム帯域）
|
1 2 3 4 5 6 7 8 |
10.0.1.25 => 52.219.52.10 2.50Mb 2.80Mb 3.10Mb 10.0.1.25 <= 52.219.52.10 1.20Mb 1.50Mb 1.80Mb 10.0.1.25 => 13.32.12.55 0.80Mb 1.00Mb 0.90Mb 10.0.1.25 <= 13.32.12.55 0.50Mb 0.60Mb 0.70Mb 10.0.1.25 => 10.0.1.10 0.10Mb 0.15Mb 0.12Mb 10.0.1.25 <= 10.0.1.10 0.20Mb 0.18Mb 0.22Mb ------------------------------------------------------------------------------------------------------------------ TX: 3.40Mb 4.20Mb 4.30Mb RX: 1.90Mb 2.30Mb 2.50Mb TOTAL: 5.30Mb 6.50Mb 6.80Mb |
🔍 ポイント
- 上り（TX）最大 4.3 Mb/s
- 下り（RX）最大 2.5 Mb/s
- TOTAL 6.8 Mb/s
→ 帯域に余裕がある（1Gbps 回線と仮定）
2）ボトルネック例
■帯域不足による通信遅延
ネットワークの「回線の太さ（帯域）」には上限があります。
この上限を超えて通信が流れると、データが渋滞して遅くなります。
具体例：
- 1Gbps回線なのに大量のファイル転送やバックアップが同時に実行される
- 動画配信や大容量ダウンロードが集中する
👉 結果
- Webページの表示が遅くなる
- APIのレスポンスが遅延する
- タイムアウトが発生する
■接続数過多でサーバが応答できない
サーバは同時に処理できる接続数に限界があります。
接続が増えすぎると、処理しきれずに応答が遅れたり失敗します。
具体例：
- アクセスが急増（セール・バズ・障害時のリトライ集中）
- 不要な接続が溜まり続ける（TIME_WAITが大量発生）
- 攻撃的なアクセス（簡易的なDDoS状態）
👉 結果
- サイトにアクセスできない
- 接続がタイムアウトする
- サーバのCPUやメモリも同時に逼迫する
3）改善策
■QoS設定で優先度制御
すべての通信を同じように扱うのではなく、「重要な通信を優先」する仕組みです。
具体例：
- 業務システムの通信 → 優先度 高
- バックアップやファイル転送 → 優先度 低
👉 効果
- 回線が混雑しても、重要な処理は遅くなりにくい
- 「遅れて困る通信」を守れる
■負荷分散（ロードバランサ導入）
1台のサーバに負荷が集中しないように、複数台に分散する仕組みです。
具体例：
- Webサーバを3台用意してアクセスを振り分ける
- AWSならALB（Application Load Balancer）を使う
👉 効果
- 1台あたりの負荷が減る
- アクセス増加にも耐えやすくなる
- 1台落ちてもサービス継続できる
■不要トラフィック遮断
無駄な通信をそもそも通さないようにする対策です。
具体例：
- 使っていないポート（例：3306など）を閉じる
- 海外からの不要アクセスを制限
- 不審なIPをブロック
👉 効果
- 回線の無駄遣いを防ぐ
- セキュリティ向上
- サーバ負荷の軽減
6. 継続的な監視と改善サイクル
サーバのパフォーマンス最適化は、単発のチューニングで終わるものではありません。
「監視 → 分析 → 改善」 のサイクルを継続的に繰り返すことで、安定性と性能を維持し続けることができます。
まず、定期的にログや各種メトリクスを収集し、CPU・メモリ・I/O・ネットワークの使用傾向を把握します。
異常値や瞬間的なスパイクだけでなく、1週間・1か月といった長期的な伸び方やクセを理解することで、ボトルネックの候補や将来的なリソース不足を予測しやすくなります。
次に、分析結果をもとに改善施策を実行します。
アプリケーション設定の最適化、SQLクエリの改善、カーネルパラメータ調整、キャッシュの導入、インスタンススペックの見直しなど、改善策にはさまざまな種類があります。
施策を実施した後は、その効果を必ず検証することが重要です。
CLI コマンド（top、iostat、ss など）に加えて、Grafana・Zabbix・CloudWatch といった監視ツールを活用し、メトリクスの変化を追うことで、改善が実際に効果を発揮しているかを確認できます。
この継続的なサイクルを繰り返すことで、サーバの安定稼働・性能向上・障害予防が可能となり、
結果として運用コストの削減やユーザー体験の向上につながります。
7. 継続的な監視と改善サイクル
Linuxサーバのパフォーマンス改善は以下の手順が基本です
- 監視ツールやコマンドで現状を把握
- CPU・メモリ・ディスクI/O・ネットワークのボトルネックを特定
- 改善策を実施して効果を確認
- 継続的に監視して負荷状況を把握
小さな改善でも積み重ねることでサーバ全体の安定性が大きく向上します。
これらの手順を習慣化することで、障害に強く、安定したサーバ運用が実現できます。
パフォーマンス改善は一度きりではなく、継続することでその効果が最大化されます。
ぜひ本記事で紹介した知識やコマンドを日々の運用に取り入れて、より快適で信頼性の高いインフラ環境を構築していってください。
