Edited at

システムの負荷の原因を切り分ける方法

More than 5 years have passed since last update.


サーバのボトルネックを探る

サーバが重い時、主に以下の4つがボトルネックとなる。


  1. CPU使用率

  2. メモリ使用量

  3. ディスクI/O

  4. TCPコネクション数

この記事では、これらのうちどれがボトルネックとなっているかを突き止める方法について書く。


ロードアベレージを見る

まずはロードアベレージを見ることで、おおまかに問題を切り分ける。

ロードアベレージの確認方法はload averageを見てシステムの負荷を確認するに書いた。


ロードアベレージが高い場合

現在のホストの「1. CPU使用率」, 「2. メモリ使用率」, 「3. ディスクI/O」を疑う。

ロードアベレージが1以下であれば軽く、1〜3くらいだとやや重く、それ以上だとこれらがボトルネックの可能性が高い。


ロードアベレージが低い場合

「4. TCPコネクション数」か、リモートホストがボトルネックになっていないか疑う。


特定のホストの問題を解決する

ネットワークがボトルネックでなく、どのホストがボトルネックになっているかが特定できたら、そのホストのボトルネックを以下の手順で探る。


CPU使用率を見る

top, sar, vmstatなどを使ってCPU使用率を見る。


CPU使用率が高い場合

CPU使用率が100%に近い場合は「1. CPU使用率」がボトルネックになっていると言える。

その場合、



  • ps でどのプロセスが原因になっているかを調査する。

  • 原因のプロセスがわかったら、straceoprofileでなぜそのプロセスがボトルネックなのか特定し、解決する。


CPU使用率が低い場合

idleの割合が高ければ、「2. メモリ使用量」「3. ディスクI/O」を疑う。


スワップの発生状況を見る

sar, vmstatfreeなどでスワップが発生しているか確認する。


スワップが発生している場合

「2. メモリ使用量」を疑う。

その場合、



  • psで特定のプロセスが極端にメモリを消費していないか確認する。

  • プログラムの不具合でメモリを使いすぎている場合は改善する。

  • そうでなければ、メモリ増設か分散を検討する。


スワップが発生していない場合

「3. ディスクI/O」を疑う。

その場合、


  • プログラムの改善でI/O頻度を軽減する

  • データの分散やキャッシュサーバの導入

  • メモリ増設でキャッシュ領域を拡大させられる場合はメモリを増設する

などで対処する。


TCPコネクション数を確認

ロードアベレージが低いがサーバが重いとき、ネットワークがボトルネックになっている可能性がある。

そのような場合、netstat -an | wc -lなどでTCPコネクション数を調べてみる。


TCPコネクションが多い場合

「4. TCPコネクション」がボトルネックの場合。

ポートは番号65535個しかないので、数万個のTCPコネクションが貼られている場合は分散のような対応をとる必要がある。


そうでもない場合

ロードアベレージが低く、ネットワークも問題でないような場合は他のホストがボトルネックになっていないか確認する。


まとめ

以上をまとめると、以下のような構造になる。


  • ロードアベレージが高い


    • CPU使用率がほぼ100%


      • 「1. CPU使用率」



    • スワップが発生している


      • 「2. メモリ使用量」



    • スワップが発生していない


      • 「3. ディスクI/O」





  • ロードアベレージが低い


    • TCPコネクション数が多い


      • 「4. TCPコネクション」



    • TCPコネクション数が少ない


      • 他のホストを疑う