Q&A
重くなるのは動的なコンテンツだけでは無く、静的なコンテンツもでしょうか？
お世話になります
公開しているサーバー(Centos 自宅サーバー)がアクセスが困難なほどに重くなるタイミングがあって、ご質問させていただきます
自宅で公開しているサーバーは
ルーター → WEBサーバー → (Mysql, Redisクラスター, MongoDBのレプリカセットのDBサーバー)という構成です
(その他にDNSもあり)
重くなるタイミングは、ルーターからの接続WEBサーバーを別のWEBサーバー(構成管理ツールで作成した同じ機能のWEBサーバー)に切り替えるタイミングで、長くて10分ほどサイトが反応してないのでは？と思われるほどの重さになります
その後時間の経過で重さは解消されます
(再び元のWEBサーバーに戻すと、戻す際に10分ほどサイトが反応しない同様の反応がある)
上記の反応しない時間は、アクセスが多い時間帯のみ発生して(より長く)、アクセスが少ない時間には発生していません(又は重くなるほど発生していない)
時間の経過とともに重さが解消されるので実害はなさそうですが、WEBサーバーに対してロードバランサを使用していたのが上記の問題のために事実上使用不可能になっています(ロードバランサで切り替えるとサイトが継続して反応しないことに)(ロードバランサを使用しないで、ルーターから切り替えても上記の現象は発生)
アクセスが多いタイミングで発生するので長時間の再現をしづらいのも困っている点です(秒間2,3アクセスから)
Muninでチェックしたところ、デフォルトの監視項目では変化した点は特になさそうです
ログをチェックしたところ、Apacheのログ・PHPのエラーログとも通常通りでエラーは出力されていませんでした
ネットワークを切り替えたタイミング(例えばWEBサーバー192.168.0.100からWEBサーバー192.168.0.101)で発生しているのでネットワークの問題だと思っていますが、1週間ほど迷宮をさまよっています
解決方法をぜひお願い致しますm(__)m
静的なコンテンツ(500バイト)で試したところ、通常通りスムーズに表示されました。容量が軽めだったので、明日の早朝のタイミングで再度(100kb程度)の静的コンテンツで時間を比較してみるつもりです
jsも静的なコンテンツだと思うのですが、動的に生成しているのですか？
あ、確かにそうですね。jsは静的に作成しているので、静的コンテンツでも時間がかかっています。ご指摘ありがとうございます
切り替え後、ルーターを経由した場合と、ローカルネットワークから直接 Webサーバーにアクセスした場合で違いはありませんでしょうか。前者のみ遅いのであれば、ルーターの性能(コネクション数など)に原因があるのではないかと思います。
今朝試したところ、ルーター(wan)経由だと重くなりローカルネットワークから直接webサーバーにアクセスした場合は通常通りの軽さでした。確かにルーターが怪しいですね。ありがとうございます
そうですね。そうすると何故Apacheのログでも遅くなっていたのでしょうね。
ルーターは、市販のもので(NECのAterm WR9500N)munin監視対象から外れている一方、設定の変更等も触ってませんので(ポートマッピングのみ)一週間前から重くなった原因としては不思議でもあります
LVS(ロードバランサ)を使用していた際も、DSR(Direct Server Return)方式を利用していたので、データを返す際には個々のwebサーバーから直接ルーターに値を渡してクライアントに返していました。その点は、ルーターが原因との考え方に反さないかと思っています
ルーターもしくはネットワークの問題のように思います。
WebサーバーのIPアドレスが同じであれば、ARP まわりの問題も考えられますが、IPアドレスは別なのですね。
KVM の 192.168.200, 192.168.0 のネットワークはブリッジにしているのでしょうか？
WebサーバーのIPアドレスは異なるものにしています。またKVMのネットワークはブリッジにしています。よろしくお願いします
ここでやりとりすると後で参照しにくいので、TaichiYanagiyaさんが回答をつけてはいかがでしょうか？
回答3件
0
ベストアンサー
ネットワークを切り替えたタイミング(例えばWEBサーバー192.168.0.100からWEBサーバー192.168.0.101)で発生しているのでネットワークの問題だと思っています
Webサーバやその先のサーバで何らかの初期化処理が実行されている可能性も
あるのではないでしょうか。
(元のサーバからのredisへの接続が残っていてタイムアウトするまで新しいサーバから接続できないなど。)
Webサーバでの処理時間の情報はないでしょうか？
(Apacheであれば、ログフォーマットに%Dを指定すればアクセスログに出せるはずです。)
遅くなったときのポートのESTABLISHの数などはどうなっていますか？
それから、別の観点ですが、現象が発生しだした頃に、(一週間前でしょうか)
何らかの変更は行っていないですか？
投稿2016/01/04 09:19
総合スコア1546
ご回答ありがとうございます
今朝の重くなるタイミングで回答頂きました点を幾つか実行させて頂きました
> Webサーバでの処理時間の情報はないでしょうか？
さっそく処理時間の情報をログに保存。
10秒以上かかかっているファイルを調べたところ、その中のファイルの割合は
jsファイルの読み込み 40％
phpファイルの読み込み 60％
その他のファイルの読み込み 約0％
となっていました
サイトで扱っているjsファイルは40~130kb程度の比較的重たいファイルが多いですので、それでjsファイルに時間がかかっているのかなと考えています(その他のimgファイル等は殆ど1kb未満)
一方、phpファイルは軽いファイルも処理に時間がかかっている場合があって、サイズにあまり依存していない印象を受けました
比較対象として
正常時10秒以上かかっているファイルは
数は重い時の1％程度で、jsファイルとphpファイルの数の比は重い時と同じ割合です
> Webサーバやその先のサーバで何らかの初期化処理が実行されている可能性
Redisに関しては、今朝一度アクセスしないよう切り離してみました。
重くなる現象に変化がなかったので、また他のDBサーバーを切り離して改善されるかやってみる予定です
> 遅くなったときのポートのESTABLISHの数などはどうなっていますか？
ESTABLISHについては、正常時・重い時ともに約800です
(Apacheが300~450程度。残りの殆どがRedis)
> それから、別の観点ですが、現象が発生しだした頃に、(一週間前でしょうか)
> 何らかの変更は行っていないですか？
別のテスト用のサーバーを組み直しました。
(色んな機能を組み込んで設定等を仮に試したりするサーバーで、データベースやApache等が一つのサーバーに入っています。それの再インストールも実行)
この際にMACアドレスの重複をしてしまったので(KVMの仮想サーバーを利用しています)、今回もその関連かな・・・と思って重い現象でも最初チェックしていました
よろしくお願い致します
Webサーバかその先で遅くなっているようですね。
jsはWebサーバのローカルディスクからの読み込みですよね？
10秒以上かかるのはかかり過ぎな気がします。
別のテスト用のサーバーでKVMの仮想サーバーされているということですが、
遅くなっているWebサーバーもKVMの仮想サーバーですか？
物理的には何台のマシンにどのような構成で入っていますか？
一台の物理マシンに、仮想サーバーを入れすぎてオーバーコミット状態だったりは
しないですよね？
それと、muninで確認できた項目は具体的に何でしょうか？
例えばディスクI/Oも確認できているのでしょうか？
遅くなっているWEBサーバーはKVMの仮想サーバーです
同じ物理・仮想構成のサーバーが3台あって、
(物理の構成 CPU: E5-2420 v2 * 2 メモリー: 96GB: SSD: 1TB NIC: E1G42ETを追加
以下の構成にパーツを追加して作成 https://www.systemworks.co.jp/pms_s479x.php)
その上に仮想サーバーで
(WEBサーバーの構成 CPU: 5スレッド メモリ: 20~42GB ディスク: 100GB)
がはいっています
物理サーバーを数カ月前に思い切って大幅増強したので、それでメモリをコントロールして1つのWEBサーバーで処理できたのが不幸中の幸いでした
WEBサーバーは
192.168.200.100等の外部からのアクセス用のポートと
192.168.0.100等の内部アクセス用のポート
の2つのネットワークを使っています
また物理サーバーには
(MongoDBサーバー・Redisサーバー)
もそれぞれ1つづつ配置されてクラスタリングされています
現状では、物理はまだまだ余裕があります
> muninで確認できた項目は具体的に何でしょうか？
MuninではI/Oも確認できています
特に変化はなかったと思いますが、詳細な値については、再度ご報告できればと思います
ご回答ありがとうございます
何点か確認させてください。
muninで確認できるのは物理サーバーの状態ですか？
それとも仮想サーバーでしょうか？
物理はまだまだ余裕があるというのは、設定上のことですか？
それとも何らかの方法でリソースの使用状況を確認したということでしょうか。
それから、
同じ物理・仮想構成のサーバーが3台ということは、
物理サーバー1:(Webサーバー1・MongoDBサーバー1・Redisサーバー1)
物理サーバー2:(Webサーバー2・MongoDBサーバー2・Redisサーバー2)
物理サーバー3:(Webサーバー3・MongoDBサーバー3・Redisサーバー3)
となっていて、外からアクセスがあるとWebサーバー1からMongoDBサーバー1、
MongoDBサーバー2のクラスタとRedisサーバー1、Redisサーバー2のクラスタに
アクセスしている状態から、外からのアクセスをWebサーバー2に向けるということで良いでしょうか？
そうすると物理サーバー3に入っているものがテスト用のサーバーでしょうか？
> muninで確認できるのは物理サーバーの状態ですか？
muninで確認できるのは、物理サーバーと仮想サーバーになります
設定上は
メモリ: 物理の約70％
CPU: 物理の約25％
ディスク: 物理の約10％
を3台の仮想サーバーで使用しています
munin上のIOも物理・仮想ともに大きな変化はありません
> 同じ物理・仮想構成のサーバーが3台ということは、
サーバーの構成は、テスト用のサーバーを除いておっしゃられている通りです
物理サーバーは記述したの3台以外に、追加で6台あって
(mysqlのマスタースレーブで物理サーバー3台)
(情報用の物理サーバーで1台。中にはmunin, nagiosが仮想サーバーで入っています)
(DNS, ロードバランサ用の物理サーバーで1台。中にはDNSとLVSの仮想サーバーが入っています)
(予備用の物理サーバーが1台。中にはDNS/LVS/Redisのスレーブ・バックアップやクラスタの残りの仮想サーバーが入っています)
テスト用の仮想サーバーは上記の予備用の物理サーバーに入っています
mysql以外の3台の物理サーバーの性能は、PowerEdge T110をベースとしたあまり高くないものです。
静的なコンテンツについても、今朝一応試してみました。結果的にやはり重くなっていました(昨日のご指摘であきらかではありますが一応・・・)
1台余っているT110のサーバーがありますので、明日仮想のWEBサーバー1台をそちらに移転して一度試して見ようと思っています
お手数をお掛けいたします。よろしくお願いしますm(__)m
構成について、理解できました。
ありがとうございます。
静的コンテンツを返すだけなら、
ディスクからファイルを読み込むくらいかと思うのですが、
他に何をしているか、ちょっと確認してみます。
Apacheのバージョンも教えていただけますか？
> Apacheのバージョンも教えていただけますか？
Apacheのバージョンは、2.2.15です。お手数をお掛けいたします
Apacheのログは、送信しきった後に出力されるようなので、
送信キューが一杯の場合には時間がかかって表示されそうです。
netstat -anなどで送信キューが溢れていないかは確認できますか？
> netstat -anなどで送信キューが溢れていないかは確認できますか？
netstat -anでLocalアドレスがルーター側のIPアドレスの状態を抜き出したところ
(netstat -an | grep '0 192.168.200.211:' | awk '{print $6}' | sort | uniq -c | sort -n)
通常が
13 SYN_RECV
154 FIN_WAIT2
314 ESTABLISHED
1967 TIME_WAIT
重い時が(重い時はアクセスが増加する時間帯の前なので少し少なめです)
2 CLOSE_WAIT
15 SYN_RECV
161 FIN_WAIT2
207 ESTABLISHED
1193 TIME_WAIT
となって、比率的には殆ど同じようです
送信キューが溢れているとは上記のような確認で大丈夫でしょうか？
netstatには、Send-Qというような情報が出ると思うので、
それのつもりです。
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:smtp 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:36287 0.0.0.0:* LISTEN
のようになっているところの、「Send-Q」の値です。
ESTABLISHEDで通信中の行の情報を確認したいところです。
Send-Qの値ですね。ありがとうございます
調べてみたところ
通常の場合は Send-Q > 1 の行の Stateが
ESTABLISHED 5~20接続
のみでした
重い場合は Send-Q > 1 の行の Stateが
ESTABLISHED 170~220接続
FIN_WAIT1 110~180接続
LAST_ACK 50~70接続
CLOSING 50~70接続
CLOSE_WAIT 5~25接続
と大幅に増加して、
Send-Qにはこのような使い方があったと始めてしりました。勉強になります
ESTABLISHEDでも重くなっている一方。終了関係で手間取っている印象を受けました
Send-Qが増えている行のRecv-Qが増えていなければ、
TaichiYanagiyaさんの回答の(ケース4)が発生していると考えて良いかと思います。
(ケース1)、(ケース2)が同時に起きている可能性も残りますが。
ルーターですが、昨年11月(2015/11/4)にファームウェアが1.0.23に
アップデートされているようですが、更新はされているでしょうか？
> 一部のご利用環境での有線通信／Wi-Fi通信の安定性を向上しました。
http://www.aterm.jp/support/verup/wr9500n/fw.html
Recv-Qは殆ど0と1ですので、ケース4が発生しているみたいですね。
今まで漠然としていたnetstatの使い方が分かってきて目からウロコです
範囲が漠然として右往左往していた状態から、かなり場所が絞りこまれてきましたm(__)m
ルーターについては1.0.23に更新してみましたが変化は見られません
新しいルーターは、一昨日から早朝に切り替えては設定ミスで元のルータに戻すを繰り返していますので、明後日の早朝にはルータを変更後の値をご報告できればと思っています
お手数をお掛けいたします
ルーターの変更をしました
結論からいうとルータの変更によって重い状態は解消されませんでした
ルーターの値は
セッション数5000(最大値の20％使用)
NATテーブル(最大値の3％使用)・CPU(最大値の5％使用)・メモリ(最大値の15％使用)と大きく余った状態です
追加でpingについてもチェックしてみたところ
重い時はサイズの大きいパケットの外部へのpingのみロスしているみたいです
【重い時】
webサーバーとweb以外の全てのサーバーからルーターへのping
0% packet loss
0% packet loss(パケットサイズ3000)
webサーバーとweb以外のサーバーからルーター経由で外部サーバー(google.com等)へのping
0% packet loss
70~80% packet loss(パケットサイズ3000)
【通常時】
webサーバーとweb以外のサーバーからルーター経由で外部サーバー(google.com等)へのping
0% packet loss
0~5% packet loss(パケットサイズ3000)
よろしくお願いいたしますm(__)m
そうですか。改善せず残念です。
pingの結果は興味深いですね。
切り替え後のWebサーバだけでなく、切り替え前のWebサーバも含む全てのサーバからの
pingが遅いということは、実は切り替えは直接原因ではなく、切り替えると大きめのパケットを返そうとして遅くなっているなどでしょうか。
http://www.rtpro.yamaha.co.jp/RT/docs/Trouble/
によると、ルーターコンソールからもpingできるようですが、
ここから試すとどうでしょうか？
何らかの原因で一回ルーター経由で詰まり出すと(切り替え・ロードバランサを使う)、大きめのパケットを外部サーバーへ返す際に全体的に遅くなっているみたいです
遅くなる時間の幅は、今日の場合は1時間程度までなったりしました
(アクセスが多いほど時間が長い)
(ここまで伸びたのは新しいルーターの設定が影響してるのかも)
ルーターコンソールからpingは良さそうですね。ありがとうございます
ルーターから外部へのpingとルーターから内部へのpingの双方を試してみようと思います
(明日のテストの影響が少ない早朝の時間帯に所要がありますので、ご報告は明後日になるかと思います。お手数をお掛けいたします)
(横からコメント失礼します)
パケットサイズが大きくなるとロスするとのこと、Path MTU Discovery がうまくいっていないのかもしれません。ただ、Path MTU Discovery Black Hole の現象だと、ある一定以上のサイズで 100% ロスするので、これではなさそう。
パケットキャプチャをとって、ウィンドウサイズの大きさと関連がないかどうか。
また、効率は落ちますが、Webサーバー側でウィンドウスケーリングを無効(sysctl -w net.ipv4.tcp_window_scaling=0)にしてみるとか。
TaichiYanagiya様
コメントありがとうございます
Windowサイズを無効にしてみても(sysctl -w net.ipv4.tcp_window_scaling=0)、重さに変更ありませんでした
このような方法もあるのですね。参考になります
ルーターコンソールからpingをしてみました。
コンソールルーターから外部へのpingのみ遅くなっていました
【通常時】
ルーターから外部サーバーへのping
0% packet loss
0% packet loss(パケットサイズ3000)
ルーターから内部サーバーへのping
0% packet loss
0% packet loss(パケットサイズ3000
【重い時】
ルーターから外部サーバーへのping
0% packet loss
65~80% packet loss(パケットサイズ3000)
ルーターから内部サーバーへのping
0% packet loss
0% packet loss(パケットサイズ3000)
これってプロバイダに何らかの変更があったってことっぽいですよね
(ロードバランサが重くなった時には、ちょうど触ってなくて外出中でもありましたし・・・その前には触ってましたが)
内部サーバーの切り替えを契機に重くなる(サーバーの最大アクセス時間のアクセスの半分ぐらいのアクセスでも重い時間が発生。最大アクセスの際には発生しない)のが不思議でもありますが、確認のためにプロバイダに電話をしてご報告をしたいと思います
プロバイダ側で何かが起きているときに、内部サーバーの切り替えを行うと問題が顕在化するのかも知れませんね。
ルーターとプロバイダの間には回線終端装置があるかと思うのですが、
それの不調ということはありませんか？
プロバイダとの連絡で原因が判明しましたのでご報告いたします
① 現在プロバイダの帯域制限がかかっている
(30GB/1日以上をしばらく継続した場合帯域制限開始。帯域制限中の制限はより短時間で判定)
② 帯域制限は、遅い時が発生した日から開始
とありましたので、ほぼ帯域制限が原因確定で間違いないと考えています
もう少し早めに私の方で情報取得してご報告しなければならなかったと思っています
(不手際によりメールの設定等のミスがありました)
解決に力を注いで頂いて大変ありがとうございます
実際のデータとしては
webサーバー1台(ロードバランサなし)の場合
- 上り通信料: 15GB程度・下り通信料: 10GB程度
webサーバー3台(ロードバランサあり)の場合の
- 上り通信量: 30~35GB程度・下り通信料: 10GB程度
とロードバランサを使用していた場合には、webサーバーの台数の分だけ上り通信料が増加しており(これについての原因については更に調べる予定です)
これがロードバランサを使用した際に遅くなった原因になっていました
サーバーの切り替えの際にも、短時間で一度帯域制限を超えてしまって、それが遅くなった原因となったみたいです
(帯域制限が解除されたあとに要検証ですが、
LVSの設定を、
lvs_sched lblc(1つのwebサーバーに全ユーザーがアクセス。負荷が上昇したら別のwebサーバーにチェンジを繰り返す)
↓
lvs_sched rr(アクセス毎にwebサーバーをラウンドロビン)
に変更した時期を契機に上り通信量が増加しているようにも見えます)
原因判明して良かったです。
プロバイダの帯域制限ということは、
上りも遅かったのでしょうね。
netstatによる原因の切り分け等大変参考になりました
(自分だけでしたら、まだデータベース周りが原因でないか？webサーバーの設定は？等別の場所でさまよっていたと思います)
後から読む人のため、LVSの設定による変化のご報告をさせていただいたあとベストアンサーとさせていただきます(18日に帯域制限が解除)
ありがとうございましたm(__)m
上りの帯域制限だけかかるみたいです(下りは制限なし)
同じプロバイダの別契約回線で、下りを40~50GB/日程度使っても帯域制限がかからなかったのも油断した原因になりました
あ、「下りも遅かったのでしょうね」のつもりでしたが、
意図通り理解していただけたみたいですね。
上りの帯域制限のみですか。なるほど。
LVSの設定変更の結果は私も知りたいので、
よろしくお願いします。
LVSの設定とネットワーク量を調べてみました
ルーターのwan側ネットワークの上り通信量は
lvs_sched rr(ラウンドロビン)のほうがlvs_sched lblc(サーバーの負荷が上がったら別のサーバーに変更)よりも2~2.5倍ほどネットワーク量が増えていました
ひょっとしたらApacheの設定で変化するかもと思っています(未検証)
(keepaliveをoffにする・Timeout等)
おかげで原因を特定してロードバランサを再び使えるようになりました。
ありがとうございました
0
「構成管理ツールで作成した同じ機能のWEBサーバ」が設定により新・旧のサーバで仮想NICのMACアドレスが同じになっている、という可能性はないでしょうか？
約10分間というのがARPキャッシュ絡みな気がしてなりません。
投稿2016/01/08 04:50
編集2016/01/08 05:12
総合スコア1149
ご回答ありがとうございます
WEBサーバーのMACアドレスを確認してみたところ、それぞれ別の値になっていました
確認漏れを防止するため、WEBサーバーのMACアドレスを再度変更してみたところ重さ時の状態に変更はありませんでした
0
回答レベルのものは提示できないので申し訳ないのですが、
追加情報で、
ルーター(wan)経由だと重くなりローカルネットワークから直接webサーバーにアクセスした場合は通常通りの軽さでした。
とのことですので、ルーターもしくはネットワークの問題のように思います。
現場にいないとちょっと調べようがないのですが、もう少し範囲を絞り込みたいと思います。
(ケース1) ルーターで止まっていて、KVMホスト、仮想マシンに届かない
(ケース2) KVMホストには届くが、仮想マシンに届かない
(ケース3) 仮想マシンには届くが、応答パケットが出ない
(ケース4) 仮想マシンには届き応答するが、応答パケットがルーターで止まる
どのケースか切り分けるため、KVMホストと仮想マシンで tcpdump を取ってみるのはいかがでしょうか。
[root@KVMホスト]# tcpdump -nn -i (ルータ側ブリッジI/F) host (クライアントIP) [root@仮想マシン]# tcpdump -nn -i (ルータ側I/F) host (クライアントIP)
クライアントからアクセスしてどこまでリクエストパケット、応答パケットが出るか確認します。
(どのケースかわかったからといって、原因のアテはないのですが ...)
投稿2016/01/07 15:42
総合スコア12146
回答をしていただきありがとうございますm(__)m
KVMホストと仮想マシンでtcpdumpを実行したところ、KVMホストと仮想マシンはほぼおなじタイミングで出力・遅延されていました
遅延しているパケットの種類は、明日再度チェックするつもりです
(いちおう使用ルーターのNECのAtermで調べて、NATテーブルが溢れる場合があるとのことでしたのでNATテーブルタイマーを短くしたところ、重さに変化はなく効果があるようには見えませんでした
NECのAtermは一般家庭用で、サーバーとして公開するにはもっと別のルーターがいいと思いRTX1210を注文してみました。原因でないにしてももう少し分かりやすいルーターがいいと思いましたので・・・仮にこれで改善されたとしても根本的な原因は残るので解決したいですが・・・)
(ケース1) でしょうか。KVM には問題なさそうですね。
となるとルーター？ デバッグできればいいのですが。
ルーターは NAT やコネクショントラッキング用に内部テーブルを持っていると思われますが、クライアントと Webサーバー間の接続が正しい手順で切れていないために、内部テーブルに残ってしまっている可能性はないでしょうか(その TTL が 10分とか)。
切り替え前の仮想サーバーで FIN_WAIT2 などが残っていませんでしょうか。
もし、切り替え前の仮想サーバーで Webサーバーデーモンが稼働しているのであれば、デーモンを停止すると中途半端に残った接続を RST で終了してくれるかもしれません。
切り替え前のサーバーでApacheを停止してい見たところ、重くなる現象に変化はみられませんでした。
変更を予定しているルーターでは(明日明後日の早朝に変更するつもりです)、使用中のnatテーブル数等の一部パラメータも表示できるようですので、絞り込みに役立ちそうな値が分かり次第、追加で書き込ませていただきます
よろしくお願いします
あなたの回答
tips
プレビュー
