- TOP >
- コワーキングスペース
- サイトへのアクセスが時々重くなる件 その3
サイトへのアクセスが時々重くなる件 その3
負荷って言ったって、色々あるじゃない。
いつも名古屋バーチャルオフィス・コワーキングスペース・レンタルオフィス・会議室ご利用ありがとうございます。
技術担当のTです。
前回、サーバ負荷が通常時の100倍ってエグくない? でサーバへの負荷が大きくなった時間帯があったところまで突き止めました。
ただ、負荷と言っても色々あると思うんですが、例えばアクセスが集中してサーバが落ちるという表現がありますが、この場合可能性としては
- ネットワークの帯域を食い潰した
- CPUの処理が追いつかなくなった
- メモリを使い切った
- 3に関連しますが、メモリを使い切ってSWAPメモリを使い始めた(ディスクの速度が遅い)
- 上記の複合的、あるいは連動
- 上記でサーバのプロセスが落ちた
があると思います。今回から具体的にどこに負荷がかかっていたかを調べます。
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(書き込み)なので、該当時間の読み取りリクエストが跳ね上がっているのがわかります。
前回より、もうちょっと具体的な仮説はコレ
以上から、今回のアクセスができなくなった原因は、
何かのきっかけで、カーネルプロセスがメモリを食い始め、最終的にスワップファイルも食い尽くして使用できるメモリが無くなり、システム全体が不安定になったことが原因ではないかと推測できます。
今回は、長くなってしまいました。
で、「何か」に迫ってみたいと思います。