OS/インフラ層のチューニング
アプリケーションの土台となるOS/インフラ層の基本的な考え方を学びます。
┌─────────────────────────────────────────────────────────────┐
│ 「サーバー増やせばいいんじゃない？」 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 遅いと言われて、とりあえずサーバーを増やす。 │
│ でも、それで本当に解決する？ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ CPU使用率 20% なのにサーバー増やしても意味がない │ │
│ │ メモリ不足でスワップしてるなら、増やすのはメモリ │ │
│ │ ディスクI/Oが詰まってるなら、SSDに変える │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 「何がボトルネックか」を知らずにリソースを増やしても、 │
│ お金の無駄になる。 │
│ │
│ OS層を理解すると「何を増やすべきか」が分かる │
│ │
└─────────────────────────────────────────────────────────────┘
このレイヤーのキー要素
┌─────────────────────────────────────────────────────────────┐
│ OS/インフラ層で押さえるべきポイント │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ CPU │ │ メモリ │ │ディスクI/O│ │ネットワーク│ │
│ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │ │
│ ↓ ↓ ↓ ↓ │
│ 使用率と スワップを SSD/NVMeで 帯域と │
│ ロードアベレージ 発生させない 高速化 接続数 │
│ │
│ USEメソッド: Utilization, Saturation, Errors を確認 │
│ │
└─────────────────────────────────────────────────────────────┘
リソースの種類
| リソース | 役割 | 監視指標 | 枯渇時の症状 |
|---|---|---|---|
| CPU | 計算処理 | 使用率、ロードアベレージ | 処理が遅い、キューが詰まる |
| メモリ | 作業領域 | 使用量、スワップ発生 | スワップで大幅な性能低下 |
| ディスクI/O | ストレージ読み書き | IOPS、await、%util | I/O待ちで全体が遅延 |
| ネットワークI/O | 通信帯域 | 帯域使用率、エラー/ドロップ | 接続タイムアウト、パケットロス |
USEメソッド: 各リソースの Utilization（使用率）、Saturation（飽和度）、Errors（エラー）を確認する。
CPU
症状: 処理が遅い、レスポンスタイムが不安定
CPU使用率の見方
topコマンドの出力例:
%Cpu(s): 25.0 us, 5.0 sy, 0.0 ni, 65.0 id, 3.0 wa, 0.0 hi, 2.0 si, 0.0 st
| 指標 | 意味 | 高い場合 |
|---|---|---|
| us (user) | ユーザー空間でのCPU使用 | アプリケーションがCPUを使っている |
| sy (system) | カーネル空間でのCPU使用 | システムコールが多い（I/O多い？） |
| id (idle) | アイドル | 余裕あり |
| wa (iowait) | I/O待ち | ディスクI/Oがボトルネック |
| st (steal) | 仮想化オーバーヘッド | VM環境でリソース不足 |
ロードアベレージ
$ uptime
load average: 2.50, 3.00, 4.00
# 1分 5分 15分
実行待ちのプロセス数の平均（CPU待ち + I/O待ち を含む）。
4コアCPUの場合の目安:
| load average | 状態 |
|---|---|
| < 4 | 余裕あり |
| = 4 | ちょうど使い切り |
| > 4 | 待ちが発生している |
| = 8 | 2倍の処理が待っている |
注意: LinuxのロードアベレージはI/O待ちも含むため、CPU使用率と合わせて見る必要がある。
メモリ
症状: 急に全体が遅くなる、レスポンスが不安定
$ free -h
total used free shared buff/cache available
Mem: 16Gi 8.0Gi 1.0Gi 500Mi 7.0Gi 7.5Gi
Swap: 4.0Gi 100Mi 3.9Gi
重要な指標
| 指標 | 意味 | 目安 |
|---|---|---|
| available | 実際に使える量 | buff/cacheは解放可能 |
| swap used | スワップ使用量 | 0が理想 |
スワップの問題
- メモリ不足時、ディスクをメモリ代わりに使う
- ディスクはメモリより 100,000倍 遅い
- スワップが発生すると大幅な性能低下
$ vmstat 1
# si (swap in), so (swap out) が 0 以外なら要注意
ディスクI/O
症状: iowaitが高い、%utilが100%に張り付く
$ iostat -x 1
重要な指標
| 指標 | 意味 | 注意点 |
|---|---|---|
| %util | ディスク使用率 | 100%に近いと飽和 |
| await | I/O待ち時間（ms） | 高いと遅延発生 |
| r/s, w/s | IOPS | 1秒あたりの読み書き回数 |
| rkB/s, wkB/s | スループット | 転送量 |
ストレージ性能比較
| 種類 | IOPS | レイテンシ |
|---|---|---|
| HDD | 100-200 | 5-10ms |
| SSD | 10,000+ | 0.1-0.5ms |
| NVMe | 100,000+ | 0.02ms |
対策
| 対策 | 効果 |
|---|---|
| SSD/NVMeへアップグレード | 大（桁違いに速くなる） |
| I/O削減（キャッシュ、バッチ処理） | 中 |
| RAIDの検討 | 中（スループット向上） |
ファイルディスクリプタとポート
症状: "Too many open files" エラー、接続が確立できない
ファイルディスクリプタ上限
| 項目 | 内容 |
|---|---|
| 仕組み | 1接続 = 1ファイルディスクリプタ |
| デフォルト | 1024 程度（少なすぎる） |
| 確認方法 | ulimit -n |
| 変更方法 | /etc/security/limits.conf |
エフェメラルポート枯渇
| 項目 | 内容 |
|---|---|
| 仕組み | クライアントとして外部接続する際のポート |
| 範囲 | 32768-60999 程度（約28000個） |
| 問題 | TIME_WAIT状態のポートは再利用できない |
| 確認方法 | ss -s |
| 対策 | 接続の再利用、Keep-Alive |
カーネルパラメータ
症状: 接続キューが溢れる、TIME_WAITが大量に発生
ネットワーク関連
| パラメータ | 用途 | 推奨値 |
|---|---|---|
net.core.somaxconn | 接続キューの最大長 | 65535 |
net.ipv4.tcp_max_syn_backlog | SYNキューの最大長 | 65535 |
net.ipv4.tcp_tw_reuse | TIME_WAITソケットの再利用 | 1 |
メモリ関連
| パラメータ | 用途 | 推奨値 |
|---|---|---|
vm.swappiness | スワップ発生しやすさ | 10（デフォルト60） |
vm.overcommit_memory | メモリオーバーコミット | 0 |
注意点
- むやみに変更しない: デフォルトは多くの場合妥当
- 変更前後で計測: 効果を確認
- 本番適用前にテスト環境で検証
まとめ
よくあるボトルネック（優先度順）
| 優先度 | ボトルネック | 確認方法 |
|---|---|---|
| 1 | メモリ不足 → スワップ発生 | free -h, vmstat 1 |
| 2 | ディスクI/O | iostat -x 1 で %util, await |
| 3 | CPU | ロードアベレージ > コア数 |
| 4 | ファイルディスクリプタ枯渇 | ulimit -n, エラーログ |
心得
- USEメソッドで確認: 各リソースの Utilization, Saturation, Errors
- アプリより先にインフラを疑わない: 多くの場合、アプリケーション側に問題がある
- OS/インフラはアプリの問題を反映しているだけ: 根本原因はアプリにあることが多い
- カーネルパラメータ調整は最後の手段: まずアプリの改善を検討
次のステップ
- Linux パフォーマンス - Linux詳細
- コラム: 早すぎる最適化 - いつ最適化すべきか