サーバやPCのボトルネック箇所の簡単な見分け方(Linux編)

　前回はWindowsでのサーバやPCのボトルネック箇所の簡単な見分け方をご紹介させていただきましたが、要望がありましたので今回はLinuxの場合をご紹介いたします。

4つの主要ボトルネック要素の復習です。

　サーバやPCには4つの主要ボトルネック要素があります。このいずれかがボトルネックとなった場合システム全体のレスポンスが低下します。

1. CPU使用率
2. メモリ使用量
3. ディスクI/O
4. TCPコネクション数

ボトルネック箇所の簡単な見分け方

　Linuxにおいてはボトルネック箇所を以下のように見分けることができます。

1. CPU使用率

　CPU使用率が常に100%に近い場合はCPUがボトルネックであることが判明します。CPU使用状況を簡単に調べるには3つの方法があります。「top」「w」「vmstat」コマンドを使う方法です。

--------------------------------------------------------------------------------- # top 151 processes: 150 sleeping, 1 running, 0 zombie, 0 stopped CPU0 states: 0.4% user, 0.5% system, 0.0% nice, 98.1% idle CPU1 states: 0.1% user, 0.5% system, 0.0% nice, 98.4% idle Mem: 513596K av, 442136K used, 71460K free, 0K shrd, 77992K buff Swap: 1044184K av, 14120K used, 1030064K free 208420K cached ---------------------------------------------------------------------------------

　この例の場合はCPU0とCPU1の2個のCPUが搭載されていますが、双方共idle値が98%以上(=CPU使用率が2%未満)なので正常です。

--------------------------------------------------------------------------------- # w 12:08pm up 171 days, 1:20, 1 user, load average: 1.22, 1.02, 1.97 ---------------------------------------------------------------------------------

　ロードアベレージは処理を待っているプロセスの平均数です。ロードアベレージ値の解釈は人それぞれですが、経験的には1以下であれば軽い状態。1～3くらいであればやや重い状態。それ以上だとCPUがボトルネックであると言えそうです。

2. メモリ使用量

　メモリ使用量が物理メモリ量を常に超えて空きメモリがなくなればメモリがボトルネックであることが判明します。 空きメモリ状況は以下のように調べることができます。

　まずtopコマンドを実行します。

--------------------------------------------------------------------------------- # top 151 processes: 150 sleeping, 1 running, 0 zombie, 0 stopped CPU0 states: 0.4% user, 0.5% system, 0.0% nice, 98.1% idle CPU1 states: 0.1% user, 0.5% system, 0.0% nice, 98.4% idle Mem: 513596K av, 442136K used, 71460K free, 0K shrd, 77992K buff Swap: 1044184K av, 14120K used, 1030064K free 208420K cached ---------------------------------------------------------------------------------

　これを見ると512MBのメモリを搭載しているマシンで、442M程度のメモリを使用していて70M程度のメモリしか空きがない、と読み取れますが、それは今回の目的からすれば解釈の間違いです。もっと見てみましょう。

--------------------------------------------------------------------------------- # free total used free shared buffers cached Mem: 513596 443556 70040 0 78340 209196 -/+ buffers/cache: 156020 357576 Swap: 1044184 14120 1030064 ---------------------------------------------------------------------------------

　Linuxでは空きメモリがあるとそれをすべてCacheにまわそうとします。それがtopに出てくる数字です。

　本当の意味で空きメモリ状況を把握するためにはCacheに回された分を差し引く必要があります。Cacheに回された分を差し引いた状況を調べるためにはfreeコマンドを実行します。この実行結果の2行目を見ると357MBくらい空いているのがわかります。よってこのマシンはメモリにかなり余裕があることがわかります。

3. ディスクI/O

　ディスクI/Oの場合はCPUやメモリのように搭載リソースの消費状況によってボトルネックを判定するわけではありません。要件や予算によってどの程度のレスポンスタイムが要求されるか基準値が異なってきます。ディスクI/O状況を簡単に調べるには「vmstat」コマンドを使います。

--------------------------------------------------------------------------------- # vmstat 1 5 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 3604 3580 23580 187696 0 1 0 1 1 1 0 0 1 0 0 0 3612 3580 23592 187636 0 8 148 96 1432 291 0 7 93 0 0 0 3612 3484 23624 187756 0 0 312 332 1376 321 0 10 90 0 0 0 3620 3456 23616 187772 0 8 164 80 1301 320 0 6 94 0 0 0 3620 3600 23636 187772 0 0 488 64 1340 318 0 8 91 ---------------------------------------------------------------------------------

　ここではbi/boの部分を見ます。既記したように要件によってここの適正値は異なります。実際に測定しながら最適値を探してみてください。

※bi: Blocks received from a block device (blocks/s)., bo: Blocks sent to a block device (blocks/s)。

4. TCPコネクション数

　アプリケーションの性質にもよりますがTCPコネクション数が数千以下であれば問題がないようです。それを超えると徐々にネットワークがボトルネックになる可能性があります。 TCPコネクション数を簡単に調べるために私は「netstat」コマンドを使うことが多いです。

--------------------------------------------------------------------------------- # netstat -an | wc -l 3050 ---------------------------------------------------------------------------------

　場合にもよりますが多くの場合この数字がTCPコネクション数とほぼ同等です(厳密にはESTABLISHED,TIME_WAIT,FIN_WAIT等の総数。余計な部分は許容誤差と考えてます)。今回の場合は3050ですから正常の範囲内です。

　TCPコネクションが張られるとポート番号が1つ消費されます。ポートは番号65535個しかありませんから、万が一数万個のTCPコネクションが張られるようなことがあった場合はサーバを分散化する等の対応が必要になります。

最後に

　今回ご紹介した方法はお医者さんで言えば問診に当たります。もし怪しいと思う箇所が見つかったら精密検査を行う必要が出るかもしれません。ボトルネック箇所を見分けられるようになるためには今回ご紹介した内容を知識として持つと共に常にサーバの稼動状況を観察してみることであると考えます。毎日サーバを見ていると何か異常が起こったときに直感的に問題箇所を特定できるようになります。