インフラエンジニア必見！Linuxサーバーパフォーマンス改善の定番手法

こんにちは！

サーバーが重くて困ったことはありませんか？特に本番環境で「なんか遅いなぁ」と感じた時の焦りは、インフラエンジニアなら誰でも経験があるはず。

CPU使用率が高い、メモリ不足、ディスクI/Oがボトルネック、ネットワークが遅い…原因は山ほど考えられるけれど、どこから手をつけていいか分からない。そんな経験、ありませんか？

実は、Linuxサーバーのパフォーマンス問題には体系的なアプローチ方法があります。闇雲に調査するのではなく、定番の手法に沿って順序立てて分析していけば、効率的に原因を特定できるんです！

今回は、そんなパフォーマンス改善の定番手法について、実践的な観点から詳しく解説していきます。特に注目したいのが、この分野の第一人者であるBrendan Gregg氏による「詳解 システム・パフォーマンス 第2版」です。

この書籍は、Linuxシステムのパフォーマンス分析における最も体系的で実践的なガイドとして、世界中のエンジニアから支持されています。

それでは、サーバーパフォーマンス改善の定番手法を、一緒に学んでいきましょう！

パフォーマンス分析の基本的な考え方

なぜ体系的なアプローチが重要なのか

パフォーマンス問題が発生した時、多くのエンジニアがやってしまいがちなのが「思いつくままに調査する」ことです。

例えば：

• とりあえずtopコマンドでCPU使用率を確認
• メモリが足りなさそうだからfreeコマンドを実行
• ディスクの容量をdfで確認
• なんとなくiotopでディスクI/Oを見てみる

この方法だと、本当の原因を見落としてしまったり、無駄な時間を使ってしまったりすることが多いんです。

システムパフォーマンスの4つの主要領域

Linuxシステムのパフォーマンスは、主に以下の4つの領域に分けて考えることができます：

1. CPU（プロセッサ）

• プロセスの実行時間
• コンテキストスイッチ
• 割り込み処理
• CPU待機時間

2. メモリ（Memory）

• 物理メモリの使用状況
• スワップの発生
• ページフォルト
• キャッシュ効率

3. ストレージ（Disk I/O）

• ディスクの読み書き速度
• I/O待機時間
• ファイルシステムの効率
• ディスクキューの状況

4. ネットワーク（Network）

• ネットワーク帯域幅
• パケットロス
• レイテンシ
• 接続数

これらの領域を体系的に分析することで、パフォーマンス問題の真の原因を効率的に特定できるようになります。

USE方法論：プロに学ぶ分析手法

Brendan Gregg氏が提案する「USE方法論」は、システムパフォーマンス分析の定番アプローチです。

USE方法論とは：

• Utilization（使用率）：リソースがどの程度使われているか
• Saturation（飽和度）：リソースが限界に達していないか
• Errors（エラー）：エラーが発生していないか

この3つの観点から各リソースを分析することで、問題の本質を見抜くことができます。

例えば、CPU使用率が80%だったとしても：

• Utilization: 80%使用（高負荷）
• Saturation: 実行待ちプロセスが多数存在（飽和状態）
• Errors: プロセスがタイムアウトエラーを頻発

この場合、単なる「CPU使用率が高い」ではなく「CPUリソースが飽和している」と判断できます。

CPU パフォーマンスの分析と改善

CPU使用率の正しい見方

多くのエンジニアが誤解しているのが「CPU使用率が高い = 問題」という考え方です。実際には、CPU使用率だけでなく、その内訳を理解することが重要なんです。

CPU時間の種類：

• User Time: ユーザープロセスの実行時間
• System Time: カーネル（システム）処理の時間
• I/O Wait: ディスクI/O待機時間
• Idle Time: アイドル（何もしていない）時間

topコマンドやhtopコマンドを使うと、これらの詳細を確認できます：

# 詳細なCPU使用率を確認
htop

# プロセス別のCPU使用状況
ps aux --sort=-pcpu | head -10

# システム全体のCPU統計
vmstat 1 5

CPU ボトルネックの特定方法

1. Load Average（負荷平均）の確認

# 現在の負荷平均を確認
uptime
# 出力例: load average: 2.45, 1.98, 1.76

# 詳細な負荷情報
cat /proc/loadavg

Load Averageが CPU コア数を超えている場合、CPU がボトルネックになっている可能性があります。

2. プロセス別のCPU分析

# CPU使用率の高いプロセスを特定
pidstat -u 1 5

# 特定プロセスの詳細分析
strace -p [PID] -f -e trace=all

3. コンテキストスイッチの監視

# コンテキストスイッチ数を確認
vmstat 1 5
# csカラムが重要

# プロセス別のコンテキストスイッチ
pidstat -w 1 5

CPU パフォーマンス改善の具体的な方法

1. プロセス優先度の調整

# プロセスの優先度を下げる
renice +5 [PID]

# CPU集約的なタスクを低優先度で実行
nice -n 19 cpu_intensive_command

2. CPUアフィニティの設定

# 特定のCPUコアにプロセスを固定
taskset -c 0,1 command

# 既存プロセスのCPUアフィニティ変更
taskset -cp 0,1 [PID]

3. プロセス数の最適化

アプリケーションレベルでの改善も重要です：

• ワーカープロセス数の調整
• スレッドプールサイズの最適化
• 非同期処理の導入

メモリ管理とスワップ最適化

Linux メモリ管理の仕組み

Linuxのメモリ管理は非常に複雑ですが、パフォーマンス改善のためには基本的な仕組みを理解しておくことが大切です。

メモリの種類：

• 物理メモリ (RAM): 実際のハードウェアメモリ
• 仮想メモリ: プロセスから見えるメモリ空間
• スワップ: ディスク上の仮想メモリ領域
• ページキャッシュ: ファイルI/Oを高速化するキャッシュ

メモリ使用状況の詳細分析

1. 基本的なメモリ情報

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

# より詳細なメモリ情報
cat /proc/meminfo

# プロセス別メモリ使用量
ps aux --sort=-rss | head -10

2. ページキャッシュとバッファの理解

多くのエンジニアが混乱するのが「使用可能メモリ」の計算です：

# 実際に使用可能なメモリ量
awk '/MemAvailable/ {print $2 " KB"}' /proc/meminfo

Linuxでは、ページキャッシュとして使用されているメモリも「使用済み」に計上されますが、実際には必要に応じて解放可能です。

3. スワップ使用状況の監視

# スワップ使用状況
swapon -s

# スワップイン・スワップアウトの監視
vmstat 1 5
# siとsoカラムを確認

スワップが頻繁に発生している場合は、メモリ不足によるパフォーマンス低下が起こっている可能性があります。詳解 システム・パフォーマンス 第2版では、こうしたメモリ管理の深い部分まで、実践的なツールとともに解説されています。

メモリパフォーマンス改善の実践的手法

1. スワップ設定の最適化

# スワップの使用傾向を調整
echo 10 > /proc/sys/vm/swappiness
# デフォルトは60、低い値ほどスワップを避ける

# 永続化する場合
echo 'vm.swappiness = 10' >> /etc/sysctl.conf

2. メモリリークの検出

# プロセス別メモリ使用量の推移を監視
while true; do
    ps aux --sort=-rss | head -5
    sleep 60
done

# より詳細なメモリ分析
pmap -d [PID]

3. ページキャッシュの制御

# ページキャッシュをクリア（注意して実行）
sync && echo 3 > /proc/sys/vm/drop_caches

# 特定ファイルのキャッシュをクリア
dd if=/dev/zero of=/path/to/file conv=notrunc oflag=nocache count=0

メモリ関連の設定ファイル調整

1. カーネルパラメータの最適化

# /etc/sysctl.conf での設定例
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5
vm.vfs_cache_pressure = 50

2. プロセス別メモリ制限

# ulimitでプロセスのメモリ使用量制限
ulimit -v 1000000  # 仮想メモリを1GBに制限

# systemdでのメモリ制限
# /etc/systemd/system/service.service
[Service]
MemoryLimit=1G

ディスクI/O パフォーマンスの監視と改善

ディスクI/O が重要な理由

ディスクI/Oは、多くの場合システム全体のボトルネックになりがちです。CPUやメモリと比べて速度が圧倒的に遅いため、ディスクアクセスが頻発するとシステム全体のレスポンスが悪化します。

ディスクI/O 監視の基本ツール

1. iostat による I/O 統計

# ディスクI/O統計を1秒間隔で5回表示
iostat -x 1 5

# 主要な指標：
# %util: ディスクの使用率
# await: 平均待機時間
# svctm: 平均サービス時間

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

# リアルタイムでI/O使用量を表示
iotop

# プロセス別の累積I/O統計
iotop -a

3. ディスク容量とinode使用状況

# ディスク使用量
df -h

# inode使用状況
df -i

# 大きなファイルの検索
find / -size +100M -type f 2>/dev/null | head -10

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

1. I/O 待機時間の分析

# プロセスのI/O待機状況
pidstat -d 1 5

# システム全体のI/O待機
vmstat 1 5
# waカラムがI/O待機時間の割合

2. ディスクアクセスパターンの分析

# リアルタイムでディスクアクセスを監視
iotrace
# または
blktrace /dev/sda

3. ファイルシステム別の分析

# ファイルシステム別のI/O統計
cat /proc/diskstats

# マウントポイント別の使用状況
lsof +D /var/log | wc -l

ディスクI/O パフォーマンス改善の実践

1. ファイルシステムの最適化

# ファイルシステムのマウントオプション最適化
# /etc/fstab での設定例
/dev/sda1 /var ext4 defaults,noatime,data=writeback 0 0

2. I/O スケジューラの調整

# 現在のI/Oスケジューラ確認
cat /sys/block/sda/queue/scheduler

# I/Oスケジューラの変更
echo noop > /sys/block/sda/queue/scheduler
# または deadline, cfq

3. ディスクキャッシュの活用

# ディスクライトキャッシュの有効化
hdparm -W 1 /dev/sda

# 先読みサイズの調整
blockdev --setra 8192 /dev/sda

SSD 固有の最適化

SSDを使用している場合は、追加の最適化が可能です：

1. TRIM の有効化

# TRIMサポートの確認
lsblk -D

# 定期的なTRIM実行のスケジュール
systemctl enable fstrim.timer

2. SSD 向けマウントオプション

# /etc/fstab での SSD 最適化設定
/dev/sda1 / ext4 defaults,noatime,discard 0 1

このような詳細なディスクI/O最適化については、「詳解 システム・パフォーマンス 第2版」の第9章「ディスクとファイルシステム」で体系的に学ぶことができます。特に、各種ツールの使い分けや解釈方法が実践的に解説されており、現場ですぐに活用できる知識が得られます。

ネットワークパフォーマンスの分析

ネットワークパフォーマンスの重要性

現代のシステムでは、マイクロサービス化やクラウド化により、ネットワーク通信がパフォーマンスに与える影響が非常に大きくなっています。Webアプリケーション、データベース通信、API呼び出しなど、あらゆる場面でネットワークがボトルネックになる可能性があります。

ネットワーク監視の基本ツール

1. 接続状況の確認

# アクティブな接続の確認
netstat -tupln

# より詳細な接続情報
ss -tupln

# 接続数の統計
ss -s

2. ネットワーク統計の取得

# ネットワークインターフェース統計
cat /proc/net/dev

# より見やすい形式で
ip -s link show

# パケット統計の詳細
netstat -i

3. 帯域幅とレイテンシの測定

# 内部ネットワークの帯域幅測定
iperf3 -s  # サーバー側
iperf3 -c server_ip  # クライアント側

# ping によるレイテンシ測定
ping -c 10 target_host

# より詳細なネットワーク診断
mtr target_host

ネットワークボトルネックの特定

1. パケットロスの検出

# パケットドロップの確認
cat /proc/net/snmp | grep -i tcp

# インターフェース別のエラー統計
ethtool -S eth0 | grep -i error

2. TCP接続の分析

# TCP接続状態の分布
ss -tan state time-wait | wc -l
ss -tan state established | wc -l

# TCP再送信統計
nstat -az | grep -i retrans

3. ファイアウォールとルーティング

# ファイアウォールルールの確認
iptables -L -n -v

# ルーティングテーブル
ip route show

# DNS解決時間の測定
dig @8.8.8.8 example.com | grep "Query time"

ネットワークパフォーマンス改善の手法

1. TCP 設定の最適化

# TCP バッファサイズの調整
echo 'net.core.rmem_max = 134217728' >> /etc/sysctl.conf
echo 'net.core.wmem_max = 134217728' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_rmem = 4096 87380 134217728' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_wmem = 4096 65536 134217728' >> /etc/sysctl.conf

# 設定の適用
sysctl -p

2. 接続数制限の調整

# ファイルディスクリプタ制限の拡大
echo 'fs.file-max = 1000000' >> /etc/sysctl.conf

# ユーザー別制限の調整
echo '* soft nofile 65535' >> /etc/security/limits.conf
echo '* hard nofile 65535' >> /etc/security/limits.conf

3. ネットワークインターフェースの最適化

# ネットワークカードの設定確認
ethtool eth0

# 受信バッファの調整
ethtool -G eth0 rx 4096

# オフロード機能の設定
ethtool -K eth0 gso on
ethtool -K eth0 tso on

システム監視の自動化と継続的改善

監視システムの構築

パフォーマンス改善は一度やって終わりではありません。継続的に監視し、問題の兆候を早期に発見することが重要です。

1. 基本的な監視スクリプト

#!/bin/bash
# performance_monitor.sh

LOG_FILE="/var/log/performance.log"
DATE=$(date '+%Y-%m-%d %H:%M:%S')

# CPU使用率
CPU_USAGE=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1)

# メモリ使用率
MEM_USAGE=$(free | grep Mem | awk '{printf "%.1f", $3/$2 * 100.0}')

# ディスク使用率
DISK_USAGE=$(df -h / | awk 'NR==2 {print $5}' | cut -d'%' -f1)

# ログ出力
echo "$DATE,CPU:$CPU_USAGE%,MEM:$MEM_USAGE%,DISK:$DISK_USAGE%" >> $LOG_FILE

# 閾値チェック
if [ $(echo "$CPU_USAGE > 80" | bc) -eq 1 ]; then
    echo "HIGH CPU USAGE: $CPU_USAGE%" | mail -s "Server Alert" admin@example.com
fi

2. cron での定期実行

# crontab -e
# 5分間隔で監視実行
*/5 * * * * /path/to/performance_monitor.sh

アラート設定の最適化

1. 適切な閾値の設定

• CPU使用率: 継続的に80%以上
• メモリ使用率: 90%以上
• ディスク使用率: 85%以上
• Load Average: CPUコア数の2倍以上

2. アラート疲れの防止

# アラート送信間隔制御の例
LAST_ALERT_FILE="/tmp/last_cpu_alert"
CURRENT_TIME=$(date +%s)

if [ -f $LAST_ALERT_FILE ]; then
    LAST_ALERT=$(cat $LAST_ALERT_FILE)
    TIME_DIFF=$((CURRENT_TIME - LAST_ALERT))

    # 30分以内は再送信しない
    if [ $TIME_DIFF -lt 1800 ]; then
        exit 0
    fi
fi

# アラート送信
echo "High CPU usage detected" | mail -s "Alert" admin@example.com
echo $CURRENT_TIME > $LAST_ALERT_FILE

パフォーマンスデータの可視化

1. Grafana + Prometheus 構成

監視データを可視化することで、傾向を把握しやすくなります：

# Prometheus Node Exporter のインストール例
wget https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-amd64.tar.gz
tar xvfz node_exporter-1.3.1.linux-amd64.tar.gz
sudo cp node_exporter-1.3.1.linux-amd64/node_exporter /usr/local/bin/

2. ログ分析の自動化

# パフォーマンスログの傾向分析
awk -F',' '
{
    cpu = $2; gsub(/[^0-9.]/, "", cpu)
    if (cpu > max_cpu) max_cpu = cpu
    sum_cpu += cpu; count++
}
END {
    print "Average CPU:", sum_cpu/count "%"
    print "Peak CPU:", max_cpu "%"
}' /var/log/performance.log

まとめ：体系的なパフォーマンス改善への道

今回は、Linuxサーバーのパフォーマンス改善における定番手法について詳しく解説してきました。

重要なポイントをもう一度整理すると：

1. 体系的なアプローチの重要性

• USE方法論（Utilization、Saturation、Errors）による分析
• CPU、メモリ、ディスクI/O、ネットワークの4つの観点からの評価
• 闇雲な調査ではなく、順序立てた分析手法の採用

2. 各リソースの具体的な分析手法

• CPU: Load Average、プロセス別分析、コンテキストスイッチの監視
• メモリ: 物理メモリ、スワップ、ページキャッシュの理解
• ディスクI/O: iostat、iotop による詳細分析とファイルシステム最適化
• ネットワーク: 接続状況、帯域幅、TCP設定の最適化

3. 継続的な改善のための仕組み

• 監視スクリプトの自動化
• 適切な閾値設定とアラート機能
• パフォーマンスデータの可視化と傾向分析

これらの手法を身につけることで、パフォーマンス問題に遭遇した時も、慌てることなく効率的に原因を特定し、適切な対策を実施できるようになります。

特に、今回紹介した内容をより深く学びたい方には、Brendan Gregg氏の「詳解 システム・パフォーマンス 第2版」を強くおすすめします。

この書籍では、今回触れた内容がさらに詳細に、そして実践的な観点から解説されています。特に：

• 各種監視ツールの詳細な使用方法
• カーネルレベルでのパフォーマンス分析手法
• 実際のトラブルシューティング事例
• 最新のLinuxカーネル機能を活用した最適化手法

などが豊富な図表とともに説明されており、現場での問題解決に直結する知識を得ることができます。

インフラエンジニアとして更なるスキルアップを目指すなら、ぜひ手に取ってみてください。きっと、日々の業務でのパフォーマンス改善作業が、より効率的で確実なものになるはずです！

今回の記事が、皆さんのサーバーパフォーマンス改善の一助となれば幸いです。良いエンジニアライフを！