ホーム / SRE / 第3部 コンピュータとネットワークの基礎
第3部 コンピュータとネットワークの基礎・第4章
ほぼ必ず出る領域。コマンドを並べるより「仮説を立てて、証拠で絞り込む」思考過程を声に出して話すことが評価される。
Linux ラボを読み込んでいます…
スコープ確認：いつから？全台か一部か？直前の変更（デプロイ、設定変更）は？
観測：全体像を見る（uptime、top、vmstat、ダッシュボード）
絞り込み：CPU・メモリ・ディスク・ネットワークのどれがボトルネックか切り分ける
緩和：原因究明より先に影響を止める（ロールバック、トラフィック切り替え、再起動）
検証と再発防止：メトリクスが戻ったことを確認し、根本原因を調べる
「重い」と言われたら、CPU・メモリ・ディスク・ネットワークのどれが詰まっているかを証拠で切り分けてから緩和に進む。
NetflixのBrendan Greggが紹介した「最初の60秒の調査」が定番。面接で「サーバーが重いと言われたらまず何をする？」と聞かれたら、この順番で答えるとよい。
| 順番 | コマンド | わかること |
|---|---|---|
| 1 | uptime | load average の推移（1分・5分・15分）。上昇中か下降中か |
| 2 | dmesg -T | tail | OOM Killer、ディスクエラー、ネットワークの異常 |
| 3 | vmstat 1 | 実行待ち（r）、I/O待ち（b）、スワップ（si / so）、CPU内訳 |
| 4 | mpstat -P ALL 1 | CPUコアごとの偏り（1コアだけ100%ならシングルスレッドのボトルネック） |
| 5 | pidstat 1 | プロセスごとのCPU使用率 |
| 6 | iostat -xz 1 | ディスクごとの await（待ち時間）、%util（使用率） |
| 7 | free -m | メモリ、available、スワップ |
| 8 | sar -n DEV 1 | ネットワークの送受信量（帯域の上限に達していないか） |
| 9 | sar -n TCP,ETCP 1 | TCP接続の確立数、再送 |
| 10 | top | 全体の確認 |
| 項目 | 意味 | 高いときに疑うこと |
|---|---|---|
| us（user） | アプリケーションの処理 | 重い計算、無限ループ、GC |
| sy（system） | カーネルの処理 | システムコールの多発、コンテキストスイッチ過多 |
| wa（iowait） | I/O完了待ち | ディスクが遅い、スワップ |
| st（steal） | 仮想化基盤に奪われた時間 | ホストの混雑、T系インスタンスのCPUクレジット枯渇 |
| si / hi | 割り込み処理 | 大量のネットワークパケット |
Linux ラボを読み込んでいます…
| 状態 | 意味 | 補足 |
|---|---|---|
| R | 実行中・実行待ち | load average に含まれる |
| S | 割り込み可能なスリープ | 通常の待機状態 |
| D | 割り込み不可能なスリープ | 主にI/O待ち。kill でも止まらない。load average に含まれる |
| Z | ゾンビ | 終了済みだが親が回収していない |
| T | 停止 | SIGSTOP やデバッガで停止中 |
D状態が多いとCPUが空いていてもload averageが上がる。I/O待ちを疑う。
Linux ラボを読み込んでいます…
| テーマ | 要点 |
|---|---|
| load average | 実行中＋実行待ち（＋I/O待ちのD状態）のプロセス数の平均。CPUコア数と比べて判断 |
| free の見方 | used が多くてもページキャッシュは必要時に解放される。available が実質の空き |
| OOM Killer | メモリ枯渇時にカーネルが oom_score の高いプロセスを殺す。dmesg に記録 |
| ゾンビプロセス | 終了したが親が wait していないプロセス。親を直すか親を終了させる |
| シグナル | SIGTERM（終了要求、ハンドル可）と SIGKILL（強制、ハンドル不可）の違い。グレースフルシャットダウンに関わる |
| inode | ファイルのメタデータ。小さいファイルが大量にあると容量があっても書けなくなる |
| ファイルディスクリプタ | 開いているファイル・ソケットの番号。ulimit -n の上限に注意 |
| /proc | カーネル情報を見る仮想ファイルシステム。プロセスの状態や設定値を確認できる |
ページキャッシュは必要なときに解放されるので、usedの大きさだけで判断しない。
| シナリオ | まず見るもの | よくある原因 |
|---|---|---|
| CPU使用率が100% | top / htop でプロセス特定、us / sy / wa / st の内訳、perf | 無限ループ、GC多発、正規表現の暴走、st高ならホスト側の競合 |
| CPU は低いのに遅い | load average、iowait、vmstat の b 列 | ディスクI/O待ち、ロック待ち、外部API待ち |
| メモリ使用率95% | free -m（available を見る）、ps の RSS、dmesg | 実はページキャッシュで問題なし／メモリリーク／OOM Killer |
| ディスク容量フル | df -h、du -sh、df -i（inode） | ログ肥大、削除済みだが開かれたままのファイル（lsof +L1） |
| ディスクI/Oが遅い | iostat -x（await、%util）、iotop | 大量書き込み、EBSのIOPS / バースト枯渇 |
| リモートから接続できない | ss -tlnp（LISTEN先が127.0.0.1か）、curl、iptables / SG、DNS | bind先の誤り、FW / セキュリティグループ、ポート誤り |
| 接続が時々タイムアウト | ss -s、TIME_WAIT数、conntrack、ulimit -n | エフェメラルポート枯渇、fd上限、conntrackテーブル溢れ |
| プロセスが固まっている | strace -p、/proc/PID/stack、スレッドダンプ | デッドロック、ネットワーク待ち、D状態（I/O待ち） |
| 手順 | 確認すること | 判断 |
|---|---|---|
| 1 | 直前のデプロイ・設定変更の有無 | あればロールバックを最優先で検討 |
| 2 | 全エンドポイントか特定のものか | 特定なら該当処理やクエリを疑う |
| 3 | APMのトレースで時間がかかっている区間 | アプリ内、DB、外部APIのどこか |
| 4 | DBのスロークエリ、接続数、ロック待ち | DBが原因なら該当クエリを特定 |
| 5 | サーバーのリソース（CPU、メモリ、GC） | 飽和していればスケールアウトで緩和 |
| 6 | 外部APIのレイテンシ | タイムアウトやサーキットブレーカーで切り離す |
| 手順 | コマンド | ポイント |
|---|---|---|
| 1 | df -h | どのファイルシステムが満杯か |
| 2 | df -i | inode 枯渇ではないか（容量があっても書けない） |
| 3 | du -sh /var/* | sort -h | 大きいディレクトリを特定 |
| 4 | lsof +L1 | 削除済みなのにプロセスが開き続けているファイル（容量が解放されない） |
| 5 | 緩和 | 古いログ削除、ログローテーション、プロセス再起動、ボリューム拡張 |
| 6 | 再発防止 | logrotate 設定、ディスク使用率アラート、ログの外部転送 |
| 手順 | 確認すること | ポイント |
|---|---|---|
| 1 | dmesg で OOM Killer の記録 | どのプロセスが殺されたか |
| 2 | free -m の available | 本当に足りないのか、キャッシュなのか |
| 3 | プロセスの RSS の推移 | 右肩上がりならメモリリーク |
| 4 | コンテナなら cgroup の上限 | K8s の limits 超過で OOMKilled |
| 5 | 緩和 | 再起動、メモリ増強、並列度を下げる |
| 6 | 根本対応 | ヒープダンプでリーク箇所の特定 |
| 層 | 確認方法 | よくある原因 |
|---|---|---|
| 名前解決 | dig、nslookup | DNSレコードの誤り、TTLによる古い値 |
| 経路 | ping、traceroute、mtr | ルーティング、セキュリティグループ、NACL |
| ポート | nc -zv host port、telnet | プロセスが LISTEN していない、FW |
| LISTEN先 | ss -tlnp | 127.0.0.1 にしか bind していない |
| TLS | openssl s_client -connect | 証明書の期限切れ、SNIの誤り、中間証明書不足 |
| アプリ | curl -v、ログ | アプリ側のエラー、認証 |
| 目的 | コマンド |
|---|---|
| プロセス | ps aux、top、htop、pidstat、pstree |
| メモリ | free、vmstat、/proc/meminfo、smem |
| ディスク | df、du、iostat、iotop、lsblk |
| ネットワーク | ss、netstat、ip、dig、curl、tcpdump、mtr |
| ファイル・fd | lsof、ulimit |
| トレース | strace、ltrace、perf、bpftrace |
| ログ | journalctl、dmesg、tail -f、grep、awk |
| 性能履歴 | sar（過去の記録を見られる） |
実際に壊れたサーバーを直す練習ができる SadServers が有効。自分の過去の障害対応を、この5ステップで説明し直してみるのもよい。
まず答えを見ずに声に出して答え、そのあと開いて比べる。
模範回答
まず、いつから、全台か一部か、直前に変更があったかを確認します。次に uptime で load average の推移、vmstat で実行待ちとI/O待ち、top でプロセスを見て全体像をつかみます。そこからCPU・メモリ・ディスク・ネットワークのどれが詰まっているかを、mpstat、free、iostat、ss などで切り分けます。原因が分かる前でも、影響が大きければロールバックやスケールアウトで先に緩和します。
深掘りされたら
見られているポイント仮説と証拠で絞り込む順序
模範回答
実行中と実行待ちのプロセス数に、Linuxでは割り込み不可のI/O待ち（D状態）も加えた平均です。CPU使用率はCPUがどれだけ忙しいか、load average はどれだけ順番待ちがあるかを表します。コア数と比べて判断し、CPUが低いのに load が高ければディスクI/Oなどの待ちを疑います。
深掘りされたら
見られているポイントD状態が含まれる点まで言えるか
模範回答
削除されたファイルをプロセスが開いたままにしていると、ディレクトリからは見えなくても容量は解放されません。lsof +L1 で該当ファイルとプロセスを特定し、プロセスを再起動するかファイルを切り詰めて解放します。ログローテーション後にアプリがファイルを開き直していない場合によく起きます。
深掘りされたら
見られているポイント実務でよくある落とし穴を知っているか
模範回答
それだけでは問題とは限りません。Linuxは空きメモリをページキャッシュに使い、必要になれば解放します。見るべきは available の値で、これが減り続ける、スワップが増える、dmesg にOOM Killerの記録がある、といった兆候があれば本当に不足しています。
深掘りされたら
見られているポイントavailable と cgroup の上限
模範回答
SIGTERM は終了要求で、アプリが受け取って後片付けできます。SIGKILL は強制終了で、受け取れません。デプロイやスケールインでは、SIGTERM を受けたら新しいリクエストの受付を止め、処理中のものを終えてから終了するグレースフルシャットダウンを実装しておかないと、処理中のリクエストがエラーになります。
深掘りされたら
見られているポイントアプリの作りと運用のつながり