サイトへのアクセスが時々重くなる件 その3

負荷って言ったって、色々あるじゃない。

いつも名古屋バーチャルオフィスコワーキングスペースレンタルオフィス会議室ご利用ありがとうございます。

技術担当のTです。

前回、サーバ負荷が通常時の100倍ってエグくない? でサーバへの負荷が大きくなった時間帯があったところまで突き止めました。

ただ、負荷と言っても色々あると思うんですが、例えばアクセスが集中してサーバが落ちるという表現がありますが、この場合可能性としては

  1. ネットワークの帯域を食い潰した
  2. CPUの処理が追いつかなくなった
  3. メモリを使い切った
  4. 3に関連しますが、メモリを使い切ってSWAPメモリを使い始めた(ディスクの速度が遅い)
  5. 上記の複合的、あるいは連動
  6. 上記でサーバのプロセスが落ちた

があると思います。今回から具体的にどこに負荷がかかっていたかを調べます。

1、ネットワークの帯域を食い潰した

前回同様sarコマンドを使っていきます。

sar -f /var/log/sa/saxx -n DEV

            IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
15時10分27秒 eth1       5.40      4.61      1.03      3.21      0.00      0.00      0.00
15時20分48秒 eth1       2.43      1.67      0.18      0.37      0.00      0.00      0.00
15時31分38秒 eth1       2.25      1.40      0.15      0.24      0.00      0.00      0.00
15時40分16秒 eth1       2.56      1.69      0.19      0.60      0.00      0.00      0.00
15時50分01秒 eth1      14.14     15.96      2.18     25.30      0.00      0.00      0.00

見るべき項目は、rxkB/s(受信データ/秒)とtxkB/s(送信データ/秒)の2項目。どちらも単位はKB(キロバイト)
上記を見ると、スッカスカなことがわかります。15:50に送信が25KBになっていますが、大した容量ではないので無視してもいいレベルです。

2、CPUの処理が追いつかなくなった

次はCPUの負荷です。

sar -f /var/log/sa/saxx -P 0 もしくはALL

            CPU %user %nice %system %iowait %steal %idle
15時00分02秒   0 25.82  0.05   51.49    0.35   0.02 22.28
15時10分27秒   0 21.38  0.04   35.79    0.37   0.03 42.39
15時20分48秒   0 19.52  0.00   80.39    0.08   0.00  0.00
15時31分38秒   0 23.36  0.00   76.54    0.09   0.00  0.00
15時40分16秒   0 22.57  0.00   77.26    0.17   0.00  0.00
15時50分01秒   0 11.40  0.06   18.47    2.42   0.07 67.58

CPUの場合は、複数搭載している場合があるので、オプションでALLをつけることが多いです。(今回はCPU1本なので、0(ゼロ)を指定しています。

見るべき項目は、%user(ユーザプロセスが使用しているCPU)%system(カーネルが使用しているCPU) %iowait(I/Oの負荷)%idle(空き)ざっくり、4つを足して100になる感じで、idleが多ければCPUに負荷はかかっていないと推測できます。

該当の時間は、idleは0ですねぇ。%userは大きく変わらず、%systemがちょうどidle分増えてます。ということは、カーネルが使用しているプロセスが影響していると言えそうです。

3、メモリを使い切った

次は、メモリがどれくらい使われていたかをみてみます。

sar -f /var/log/sa/saxx -r

            kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit
15時00分02秒    189060    826928     81.39      9900    122692    940572     30.22
15時10分27秒      8172   1007816     99.20       524     13276   3830296    123.06
15時20分48秒      9092   1006896     99.11       840     19748   3938680    126.55
15時31分38秒      8044   1007944     99.21       612     10564   4223244    135.69
15時40分16秒      8416   1007572     99.17       448     10368   3463072    111.27
15時50分01秒     97444    918544     90.41      3808    101232   1007420     32.37

メモリの使用率は、kbmemused – ( kbbuffers + kbcached ) で計算できます。メモリの使用量から、バッファとキャッシュの容量を引く感じです。(単位はKBです)

該当の時間帯を見てみると、バッファとキャッシュの使用量が減っていて、1GBのメモリを使い切っています。ということは、スワップメモリを使っている可能性がありそうです。
*スワップメモリとは、メモリが足りない時にストレージ(今回の場合HDD)をメモリがわりに使う仕組みです)

sar -f /var/log/sa/saxx -S

            kbswpfree kbswpused  %swpused  kbswpcad   %swpcad
15時00分02秒   1835084    261360     12.47     73048     27.95
15時10分27秒      1728   2094716     99.92    108052      5.16
15時20分48秒      9560   2086884     99.54    116444      5.58
15時31分38秒     18668   2077776     99.11     89284      4.30
15時40分16秒    223004   1873440     89.36    118148      6.31
15時50分01秒   1962904    133540      6.37     57044     42.72

うん。もう説明いらないくらいですね。
一応説明すると、kbswpfree(スワップの空き領域)kbswpused(スワップの利用量)
該当の時間帯に100%近くメモリを使ってます。つまり、メモリがない状態ですね。ということは、プロセスはメモリ不足で終了するし、そもそもサーバ自体の動作も不安定になります。

この関連で、ディスクへ負荷も参考にみてみます。

sar -f /var/log/sa/saxx -b

                 tps    rtps     wtps   bread/s  bwrtn/s
14時40分02秒    27.18    22.01    5.17    731.01    71.28
14時50分01秒    20.52    15.42    5.10    517.39    72.29
15時00分02秒  9345.19  6607.40 2737.79 221402.26 32920.48
15時10分27秒  4457.57  3318.46 1139.10 116368.87 18679.02
15時20分48秒 17272.33 13035.73 4236.60 522474.98 34948.75
15時31分38秒 15376.64 11928.99 3447.65 468951.40 28255.95
15時40分16秒 16300.92 12394.30 3906.62 481072.71 32114.74
15時50分01秒  3213.60  2393.66  819.93  67597.27  8451.74

予想通りですね。tps(リクエスト数合計)=rtps(読み取り)+wtps(書き込み)なので、該当時間の読み取りリクエストが跳ね上がっているのがわかります。

前回より、もうちょっと具体的な仮説はコレ

以上から、今回のアクセスができなくなった原因は、
何かのきっかけで、カーネルプロセスがメモリを食い始め、最終的にスワップファイルも食い尽くして使用できるメモリが無くなり、システム全体が不安定になったことが原因ではないかと推測できます。

今回は、長くなってしまいました。

次回、何かのきっかけの何かって何なのさ!

で、「何か」に迫ってみたいと思います。

技術担当T の紹介

名古屋栄のビジネスリンクス名古屋で、バーチャルオフィス、コワーキングスペース、レンタルオフィス、会議室に関わる技術的なことを担当しています。また、SEO対策やWebサイト制作・運営、サーバメンテナンス等インターネット上の技術的な部分も担当しています。

Twitter:blinks_nagoya
Youtube:businesslinksnagoya
Facebook:b.links.nagoya

PAGE TOP