Linuxパフォーマンストラブルシューティング - 高負荷原因の特定と対処

Linuxサーバーの運用において、「急にレスポンスが遅くなった」「サービスが応答しなくなった」といったパフォーマンス問題は避けて通れません。このような問題に対処するためには、CPU、メモリ、ディスクI/O、ネットワークの各リソースについて、どこがボトルネックになっているのかを迅速に特定し、適切な対処を行う必要があります。

この記事では、Linuxパフォーマンストラブルシューティングの実践的な手法として、高負荷原因の特定から具体的な対処法まで、現場で使えるノウハウを体系的に解説します。

前提条件と動作確認環境

本記事の内容は以下の環境で動作確認しています。

必要なパッケージのインストール方法は以下のとおりです。

1
2
3
4
5

# Ubuntu/Debian系
sudo apt install sysstat iotop procps

# RHEL/AlmaLinux/Rocky系
sudo dnf install sysstat iotop procps-ng

iotopを使用するには、カーネルオプションCONFIG_TASK_DELAY_ACCTとCONFIG_TASK_IO_ACCOUNTINGが有効になっている必要があります。また、Linux 5.14以降ではkernel.task_delayacctを有効にする必要があります。

1
2

# カーネル5.14以降でiotopを使用する場合
sudo sysctl -w kernel.task_delayacct=1

パフォーマンス問題調査の全体像

Linuxパフォーマンストラブルシューティングでは、4つの主要リソース（CPU、メモリ、ディスクI/O、ネットワーク）を順序立てて調査します。問題の切り分けには、以下のフローが有効です。

flowchart TD
    A[パフォーマンス問題発生] --> B{ロードアベレージ確認}
    B -->|高い| C[CPU使用率確認]
    B -->|低い| D[I/O wait確認]
    
    C -->|CPU使用率高| E[top/pidstatで<br/>原因プロセス特定]
    C -->|CPU使用率低| D
    
    D -->|I/O wait高| F[iostat/iotopで<br/>ディスクI/O調査]
    D -->|I/O wait低| G[メモリ使用率確認]
    
    G -->|メモリ不足| H[OOMキラー確認<br/>メモリ使用プロセス特定]
    G -->|問題なし| I[ネットワーク調査]
    
    E --> J[対処実施]
    F --> J
    H --> J
    I --> J
    
    style A fill:#ffcdd2,stroke:#c62828
    style J fill:#c8e6c9,stroke:#388e3c

調査の基本は「まず全体を把握し、次に詳細を追う」ことです。いきなり細かい調査を始めるのではなく、まずuptimeやtopで全体像を把握してから、特定のリソースを深掘りしていきます。

初動で実行すべきコマンド

問題発生時の初動として、以下のコマンドを順番に実行して全体像を把握します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 1. ロードアベレージとシステム稼働時間を確認
uptime

# 2. CPU、メモリ、プロセス状況を一覧表示
top -bn1 | head -20

# 3. メモリ使用状況を確認
free -h

# 4. ディスク使用状況を確認
df -h

# 5. I/O状況を確認
iostat -x 1 3

これらのコマンドの出力から、どのリソースにボトルネックがあるかを判断します。

CPU高負荷の調査と対処

topコマンドによる調査

topコマンドは、CPU使用状況をリアルタイムで監視する最も基本的なツールです。

1

top

topの画面構成と重要な指標を理解しましょう。

top - 14:32:45 up 15 days,  3:24,  2 users,  load average: 4.52, 3.78, 2.65
Tasks: 256 total,   3 running, 253 sleeping,   0 stopped,   0 zombie
%Cpu(s): 78.5 us, 12.3 sy,  0.0 ni,  5.2 id,  3.5 wa,  0.0 hi,  0.5 si,  0.0 st
MiB Mem :  15890.4 total,   1234.5 free,   8765.4 used,   5890.5 buff/cache
MiB Swap:   2048.0 total,   1800.0 free,    248.0 used.   6543.2 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  12345 www-data  20   0 1234560 567890  12340 R  95.3   3.5  15:32.45 php-fpm
  12346 mysql     20   0 2345670 890120  34560 S  45.2   5.5  45:12.34 mysqld

CPU行の各項目の意味

topの便利な操作

topはインタラクティブなコマンドです。以下のキー操作を覚えておくと便利です。

マルチコア環境では、1キーを押してCPUコアごとの負荷を確認することが重要です。特定のコアだけが高負荷の場合、シングルスレッドアプリケーションがボトルネックになっている可能性があります。

pidstatによるプロセス単位の詳細調査

pidstatは、特定のプロセスのCPU使用状況を継続的に監視するためのコマンドです。topよりも詳細な情報を取得でき、ログとして記録するのに適しています。

1
2

# 全プロセスのCPU使用状況を2秒間隔で5回表示
pidstat 2 5

実行結果の例：

Linux 6.5.0-44-generic (server01)     01/08/2026      _x86_64_        (4 CPU)

02:32:45 PM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
02:32:47 PM  1000     12345   85.50    8.50    0.00    2.00   94.00     0  php-fpm
02:32:47 PM   999     12346   35.50    9.50    0.00    1.00   45.00     1  mysqld
02:32:47 PM     0      1234    2.00    1.00    0.00    0.00    3.00     2  systemd

pidstatの主要オプション

特定のプロセスを詳しく調査する場合は、以下のオプションを活用します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 特定PIDのCPU使用状況を監視
pidstat -p 12345 1 10

# コマンド名でフィルタリング（正規表現対応）
pidstat -C "php|mysql" 2 5

# スレッドも表示
pidstat -t -p 12345 1 5

# CPU使用率をコア数で割った値を表示（マルチコア環境用）
pidstat -I 2 5

# ユーザー/システム/待機時間を詳細表示
pidstat -u 2 5

コンテキストスイッチの調査

コンテキストスイッチが多すぎると、CPU時間がスイッチのオーバーヘッドに費やされます。pidstat -wで確認できます。

1
2

# コンテキストスイッチを監視
pidstat -w 2 5

実行結果の例：

02:32:45 PM   UID       PID   cswch/s nvcswch/s  Command
02:32:47 PM  1000     12345    150.00   2500.00  php-fpm
02:32:47 PM   999     12346     80.00    300.00  mysqld

nvcswch/sが非常に高い場合は、CPUリソースの競合が発生しています。

CPU高負荷への対処法

CPU高負荷の原因を特定したら、以下の対処法を検討します。

暴走プロセスの対処

1
2
3
4
5
6
7
8
9

# プロセスの優先度を下げる（nice値を上げる）
sudo renice 10 -p 12345

# プロセスをCPU制限（cgroupsを使用）
sudo systemctl set-property --runtime user-12345.slice CPUQuota=50%

# 最終手段：プロセスを終了
sudo kill -15 12345  # 正常終了を試みる
sudo kill -9 12345   # 強制終了

アプリケーションレベルの対処

1
2
3
4
5

# PHPのワーカープロセス数を確認・調整
grep -E "^pm\." /etc/php/8.3/fpm/pool.d/www.conf

# MySQLのスレッド数を確認
mysql -e "SHOW GLOBAL STATUS LIKE 'Threads_%';"

メモリ不足とOOMキラーへの対処

メモリ使用状況の調査

メモリ不足は、システム全体のパフォーマンス低下やOOMキラーによるプロセス強制終了を引き起こします。

1
2

# メモリ使用状況を確認
free -h

実行結果の例：

               total        used        free      shared  buff/cache   available
Mem:            15Gi        12Gi       512Mi       312Mi       2.8Gi       2.5Gi
Swap:          2.0Gi       1.5Gi       512Mi

注目すべきポイントは以下のとおりです。

• availableが総メモリの10%を下回っている場合は危険水域
• Swapの使用量が増加している場合は物理メモリ不足
• Swapを継続的に使用している場合、パフォーマンスが大幅に低下

メモリ使用量の多いプロセスを特定

1
2
3
4
5

# メモリ使用量順にプロセスを表示
ps aux --sort=-%mem | head -15

# pidstatでメモリ使用状況を監視
pidstat -r 2 5

pidstat -rの出力例：

02:32:45 PM   UID       PID  minflt/s  majflt/s     VSZ     RSS   %MEM  Command
02:32:47 PM   999     12346    120.00      5.00 2345670  890120   5.50  mysqld
02:32:47 PM  1000     12345     85.00      2.00 1234560  567890   3.50  php-fpm

majflt/sが高い場合は、スワップが頻繁に発生しており、パフォーマンスが低下しています。

OOMキラーの確認と対処

OOMキラー（Out Of Memory Killer）は、メモリが枯渇したときにカーネルがプロセスを強制終了する仕組みです。

OOMキラーのログ確認

1
2
3
4
5
6
7
8

# dmesgでOOMキラーの発動を確認
sudo dmesg | grep -i "out of memory"

# journalctlで確認
sudo journalctl -k | grep -i "oom"

# 詳細なOOMログを確認
sudo journalctl -k --since "1 hour ago" | grep -A 20 "Out of memory"

OOMキラーが発動した場合のログ例：

[12345.678901] Out of memory: Killed process 12345 (mysqld) total-vm:2345670kB, anon-rss:890120kB, file-rss:12340kB

OOMスコアの確認と調整

各プロセスには「OOMスコア」があり、この値が高いプロセスが優先的に終了されます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 特定プロセスのOOMスコアを確認
cat /proc/12345/oom_score

# OOMスコア調整値を確認（-1000〜1000）
cat /proc/12345/oom_score_adj

# 重要なプロセスのOOMスコアを下げる（終了されにくくする）
echo -500 | sudo tee /proc/12345/oom_score_adj

# OOMキラーから完全に除外する（非推奨）
echo -1000 | sudo tee /proc/12345/oom_score_adj

systemdサービスの場合は、Unitファイルで設定できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# サービスのOOMスコア調整を確認
systemctl show mysqld | grep OOM

# 設定例（/etc/systemd/system/mysqld.service.d/oom.conf）
sudo mkdir -p /etc/systemd/system/mysqld.service.d/
cat << 'EOF' | sudo tee /etc/systemd/system/mysqld.service.d/oom.conf
[Service]
OOMScoreAdjust=-500
EOF
sudo systemctl daemon-reload

メモリリークの調査

メモリ使用量が時間とともに増加し続ける場合は、メモリリークの可能性があります。

1
2
3
4
5
6
7
8

# 特定プロセスのメモリ使用量を継続監視
pidstat -r -p 12345 60 1440  # 1分間隔で24時間監視

# より詳細なメモリマップを確認
sudo pmap -x 12345 | tail -20

# /proc経由でメモリ情報を取得
cat /proc/12345/status | grep -E "^(VmSize|VmRSS|VmSwap):"

ディスクI/Oボトルネックの特定

iostatによるディスクI/O監視

ディスクI/Oがボトルネックになっている場合、iostatで詳細を調査します。

1
2

# 拡張統計を2秒間隔で5回表示
iostat -x 2 5

実行結果の例：

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz     f/s f_await  aqu-sz  %util
sda            150.00   6000.00     5.00   3.23   12.50    40.00  200.00  10000.00    20.00   9.09   15.00    50.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00    0.00    4.50  85.00
nvme0n1         50.00   2000.00     2.00   3.85    0.50    40.00  100.00   5000.00    10.00   9.09    0.80    50.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00    0.00    0.10  12.00

重要な指標と判断基準

デバイス別の期待値

iotopによるプロセス別I/O監視

iotopは、どのプロセスがディスクI/Oを発生させているかを特定するためのツールです。

1
2
3
4
5
6
7
8

# インタラクティブモードで起動
sudo iotop

# 実際にI/Oを行っているプロセスのみ表示
sudo iotop -o

# バッチモードで記録（ログ取得用）
sudo iotop -b -o -n 10 -d 2

iotopの画面例：

Total DISK READ:       12.50 M/s | Total DISK WRITE:       25.00 M/s
Current DISK READ:     10.00 M/s | Current DISK WRITE:     20.00 M/s
    TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
  12346 be/4  mysql       8.00 M/s   15.00 M/s  0.00 %  45.00 %  mysqld
  12345 be/4  www-data    3.00 M/s    5.00 M/s  0.00 %  20.00 %  php-fpm

iotopの便利な操作

pidstatによるI/O監視

pidstatでもプロセス単位のI/Oを監視できます。

1
2

# I/O統計を表示
pidstat -d 2 5

実行結果の例：

02:32:45 PM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
02:32:47 PM   999     12346   8000.00  15000.00    500.00     150  mysqld
02:32:47 PM  1000     12345   3000.00   5000.00    100.00      50  php-fpm

ディスクI/Oボトルネックへの対処

I/O優先度の調整

1
2
3
4
5
6
7
8

# プロセスのI/O優先度を確認
ionice -p 12345

# I/O優先度を下げる（クラス2=Best Effort、レベル7=最低優先度）
sudo ionice -c 2 -n 7 -p 12345

# I/O優先度をIdleに設定（他にI/Oがないときだけ実行）
sudo ionice -c 3 -p 12345

根本的な対処

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# ディスク容量を確認（容量不足でパフォーマンス低下する場合あり）
df -h

# ファイルシステムの断片化を確認（ext4の場合）
sudo e4defrag -c /dev/sda1

# I/Oスケジューラを確認・変更
cat /sys/block/sda/queue/scheduler

# NVMe SSD向けに最適化されたスケジューラを設定
echo "none" | sudo tee /sys/block/nvme0n1/queue/scheduler

ネットワーク遅延の調査

ネットワーク状態の確認

ネットワークが原因でパフォーマンスが低下している場合は、以下のツールで調査します。

1
2
3
4
5
6
7
8

# ネットワークインターフェースの統計
ip -s link show

# より詳細な統計
cat /proc/net/dev

# netstatでネットワーク接続状況を確認
ss -tuanp | head -20

接続状態の分析

1
2

# TCP接続の状態別カウント
ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c | sort -rn

実行結果の例：

    500 ESTABLISHED
    150 TIME-WAIT
     50 CLOSE-WAIT
     20 SYN-SENT

ネットワーク遅延の測定

1
2
3
4
5
6
7
8

# 基本的な疎通確認と遅延測定
ping -c 10 target-server.example.com

# 経路上の各ホップの遅延を確認
traceroute target-server.example.com

# MTR（tracerouteの継続版）で詳細分析
mtr -n -c 20 target-server.example.com

帯域使用状況の確認

1
2
3
4
5
6
7
8

# iftopでリアルタイム帯域監視（要インストール）
sudo iftop -i eth0

# nicstatで帯域使用率を確認
nicstat 2 5

# nethogs でプロセス別帯域を確認（要インストール）
sudo nethogs eth0

ネットワーク関連のカーネルパラメータ確認

1
2
3
4
5
6
7

# TCP関連の設定を確認
sysctl -a | grep -E "^net\.(core|ipv4\.tcp)" | head -20

# 重要なパラメータを確認
sysctl net.core.somaxconn              # 接続キューの最大長
sysctl net.ipv4.tcp_max_syn_backlog    # SYNバックログ
sysctl net.core.netdev_max_backlog     # 受信キューの最大長

パフォーマンスチューニングの基本

sysctlによるカーネルパラメータ調整

パフォーマンス問題の根本対処として、カーネルパラメータを調整する場合があります。

メモリ関連のチューニング

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# スワップの使用頻度を調整（0〜100、低いほどスワップしにくい）
sysctl vm.swappiness
echo "vm.swappiness = 10" | sudo tee -a /etc/sysctl.d/99-performance.conf

# ダーティページの書き出しタイミング調整
sysctl vm.dirty_ratio            # 同期書き込みを開始する割合
sysctl vm.dirty_background_ratio # バックグラウンド書き込みを開始する割合

# 高I/O環境向けの設定例
cat << 'EOF' | sudo tee /etc/sysctl.d/99-performance.conf
vm.swappiness = 10
vm.dirty_ratio = 40
vm.dirty_background_ratio = 10
vm.vfs_cache_pressure = 50
EOF

ネットワーク関連のチューニング

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# 高トラフィック環境向けの設定例
cat << 'EOF' | sudo tee -a /etc/sysctl.d/99-performance.conf
# TCP接続関連
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.core.netdev_max_backlog = 65535

# TCPバッファサイズ
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# TIME-WAIT対策
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
EOF

# 設定を反映
sudo sysctl -p /etc/sysctl.d/99-performance.conf

limitsによるリソース制限の調整

1
2
3
4
5

# 現在のリソース制限を確認
ulimit -a

# 特定プロセスの制限を確認
cat /proc/12345/limits

高負荷環境では、以下の制限を緩和する必要がある場合があります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# /etc/security/limits.d/99-performance.conf
cat << 'EOF' | sudo tee /etc/security/limits.d/99-performance.conf
# ファイルディスクリプタ上限
* soft nofile 65535
* hard nofile 65535

# プロセス数上限
* soft nproc 65535
* hard nproc 65535
EOF

systemdサービスの場合は、Unitファイルで設定します。

1
2
3
4

# /etc/systemd/system/myapp.service.d/limits.conf
[Service]
LimitNOFILE=65535
LimitNPROC=65535

継続的な監視体制の構築

一時的な対処だけでなく、継続的な監視体制を構築することが重要です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# sarによる履歴データの収集を有効化
sudo systemctl enable sysstat
sudo systemctl start sysstat

# 過去のCPU使用状況を確認
sar -u -f /var/log/sysstat/sa08

# 過去のメモリ使用状況を確認
sar -r -f /var/log/sysstat/sa08

# 過去のディスクI/Oを確認
sar -d -f /var/log/sysstat/sa08

トラブルシューティングチェックリスト

パフォーマンス問題発生時に参照するチェックリストをまとめます。

CPU高負荷時

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 1. ロードアベレージ確認
uptime

# 2. CPU使用率の内訳確認
top -bn1 | head -10

# 3. 高CPU使用プロセスの特定
ps aux --sort=-%cpu | head -10

# 4. 詳細なCPU使用状況
pidstat 2 5

# 5. コンテキストスイッチ確認
pidstat -w 2 5

メモリ不足時

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 1. メモリ使用状況確認
free -h

# 2. スワップ使用状況
swapon --show

# 3. 高メモリ使用プロセスの特定
ps aux --sort=-%mem | head -10

# 4. OOMキラー発動履歴
sudo dmesg | grep -i "out of memory"

# 5. メモリ詳細
pidstat -r 2 5

ディスクI/Oボトルネック時

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 1. ディスク使用率確認
df -h

# 2. I/O統計
iostat -x 2 5

# 3. I/O発生プロセスの特定
sudo iotop -o -b -n 5

# 4. プロセス別I/O
pidstat -d 2 5

ネットワーク問題時

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 1. インターフェース統計
ip -s link show

# 2. 接続状態確認
ss -tuanp | head -20

# 3. 接続状態別カウント
ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c

# 4. 疎通確認
ping -c 5 target-server.example.com

まとめ

Linuxパフォーマンストラブルシューティングでは、CPU、メモリ、ディスクI/O、ネットワークの各リソースを体系的に調査し、ボトルネックを特定することが重要です。本記事で解説した内容を整理すると以下のようになります。

• 初動対応: uptime、top、free、iostatで全体像を把握
• CPU調査: top、pidstatでCPU使用率と原因プロセスを特定
• メモリ調査: free、pidstat -rでメモリ使用状況を確認し、OOMキラーのログを確認
• ディスクI/O調査: iostat、iotopでI/Oボトルネックとなるプロセスを特定
• ネットワーク調査: ss、ping、tracerouteで接続状態と遅延を確認
• チューニング: sysctlでカーネルパラメータを調整、ulimitでリソース制限を緩和

パフォーマンス問題は複合的な要因で発生することも多いため、一つの指標だけでなく、複数の観点から総合的に判断することが大切です。また、問題が発生してから対処するだけでなく、sarなどのツールで継続的に監視し、問題を予防することも重要です。

参考リンク

• pidstat(1) - Linux manual page
• iotop(8) - Linux manual page
• iostat(1) - Linux manual page
• sysstat - GitHub
• Linux Performance - Brendan Gregg
• Red Hat - Performance Tuning Guide