【Love Affair】携帯からのアクセスに対する考察・次の一手 Part4.1 - ボーリング場2
レス数が1000を超えています。これ以上書き込みはできません。
日増しに増加する携帯からのアクセス。
かつて、羨ブラが生まれたように何かが生まれないと
ならない気がする。
たぶん解決策は、時間を売って空間を買うだと思うけど
いろいろ考察して、次の一手を決めようかと、
Love Affair 作戦。
Part4 ボーリング場 (頑固じゃなきゃネ)
前スレ
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part4 - ボーリング場
http://qb5.2ch.net/test/read.cgi/operate/1201374777/
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part3 - シーガーディアン
http://qb5.2ch.net/test/read.cgi/operate/1095146311/
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part2 - 大黒埠頭
http://qb5.2ch.net/test/read.cgi/operate/1088657713/
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1 - マーリンルージュ
http://qb5.2ch.net/test/read.cgi/operate/1075887465/
Wikiページ http://info.2ch.net/wiki/index.php?Love%20Affair
>>921
フロントは落ちてはいませんね。
単に激重なだけです。
おそらく bg と c.2ch.net 間の通信で詰まっているか、 bg と 2ch 間で詰まっている感じです。
ログインした。
c20 も c-docomo5 も劇重。
どうしたんだろう。 確かにフロントじゃないっぽいですね。
全部同時におかしくなってる。
BG のほうか。 slotが待ち状態で埋め尽くされている感じですね。
c-docomo系はapache再起動で救えるかもしれません >>929
BG が復活しない限り、結局だめかなと。
BG の様子みてきます。 BG は特段変でもないですね、、、。
何が起きたのか。
c-docomo5、httpdリスタートしてみる。 c-docomo6 ログインできた。
こちらも同じ症状。 @ c20
$ uptime
9:20AM up 2 days, 14:52, 2 users, load averages: 512.43, 504.74, 418.01 c20
last pid: 32293; load averages: 511.58, 505.83, 424.32 up 2+14:53:34 09:21:38
556 processes: 499 running, 57 sleeping
CPU states: 99.2% user, 0.0% nice, 0.6% system, 0.2% interrupt, 0.0% idle
Mem: 972M Active, 1868M Inact, 240M Wired, 165M Cache, 112M Buf, 5396K Free
Swap: 8192M Total, 8192M Free yutori/c209 突然軽くなってログインできた。
しかし httpd がいない。 httpd 自動で上がりつつある模様。< yutori
(そういう仕掛けが入っているのかも) c-docomo5 / c-docomo6
httpd を落とし中。時間がかかっている。 http://c209.2ch.net/
こっちも正常のようだ。< yutori c-docomo5 / c-docomo6 httpd を再起動した。 推測するにこれは、
・BG (のうちのたぶん一つ)の処理が何らかの拍子に詰まる(httpd一時的におかしくなる等で)
・フロントが一斉に詰まる
というのが起きたんではないかなと。 新c.2ch.net の方はsudoさん居ないですよね。 >>945
おそらくそうですね。
http://pvbg.40.kg/
bg21 と bg23 の一部を bg22 に移した方がいいのかな？ >>946
通常の掲示板サーバ等と同じで、
root 権限は２ちゃんねるにはありません。
一般的なパターンでリブート依頼をすることになるかと。 BG が死んだ場合、
今フロントって即にはあきらめてくれないんでしたっけ。 >>951
timeout は 5秒にしています。
5秒間は待ちつづけますね。 c20
load averages: 512.36, 510.86, 470.53
c21
ログインできず、トライ中。
c22
load averages: 511.99, 510.81, 477.69
c24
load averages: 495.89, 493.21, 454.07 >>952
えっと、今って.so呼ぶんじゃなかったっけ。
というか httpd でいくんだから同じか。 >>954
.so じゃないですよ。
phpのままです。
通常時は処理は0.02〜3秒くらいだから、一回タイムアウト処理を行うと処理時間が200倍近くになる。 c20のtopコマンドの出力。
c2x はどれも同じ状態。
BG が詰まった途端に全部のフロントが死にましたね。
yutori は自力回復して、root権限持っているc-docomo5/c-docomo6は私が回復させた。
しかしT-banana32のc20, c21, c22, c24は全て爆死状態の模様。
last pid: 32340; load averages: 511.67, 511.26, 479.88 up 2+15:07:57 09:36:00
556 processes: 506 running, 50 sleeping
CPU states: 99.3% user, 0.0% nice, 0.4% system, 0.3% interrupt, 0.0% idle
Mem: 973M Active, 1870M Inact, 240M Wired, 162M Cache, 112M Buf, 5560K Free
Swap: 8192M Total, 8192M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
31813 www 1 100 0 49592K 12508K RUN 1 0:07 0.98% httpd
32155 www 1 99 0 49876K 12900K RUN 0 0:05 0.83% httpd
31650 www 1 100 0 49552K 12216K RUN 1 0:13 0.20% httpd
31918 www 1 100 0 49352K 8804K RUN 1 0:11 0.20% httpd
32030 www 1 100 0 49572K 9180K RUN 1 0:10 0.20% httpd
31665 www 1 100 0 49556K 12060K RUN 1 0:13 0.15% httpd
31796 www 1 100 0 49360K 11600K RUN 1 0:12 0.15% httpd
31675 www 1 100 0 49388K 12000K RUN 1 0:12 0.15% httpd
31748 www 1 100 0 49876K 12528K RUN 1 0:12 0.15% httpd
31996 www 1 100 0 49348K 8164K RUN 1 0:11 0.15% httpd
31821 www 1 100 0 49452K 12048K RUN 1 0:10 0.15% httpd
32186 www 1 100 0 49388K 11572K RUN 1 0:09 0.15% httpd
31603 www 1 100 0 49544K 12248K RUN 1 0:24 0.10% httpd
31649 www 1 100 0 49444K 11928K RUN 1 0:13 0.10% httpd
31720 www 1 100 0 49384K 11716K RUN 1 0:12 0.10% httpd
31765 www 1 100 0 49408K 11704K RUN 1 0:12 0.10% httpd >>955
いや、そうじゃなくて、
BG 呼ぶ時のURIの話。 c-docomo5 / c-docomo6 等に私が入れていた(いる)のと同じような、
c のユーザでも httpd の再起動だけはできるようにする仕掛けを
入れてもらったほうがいいのかもしれないですね。
たぶんきっと、明日以降の課題ということで。
やり方は私のほうできっとここに書けると思います。 >>959
なるほど。
でもそれって http で dat とるのと、基本同じですもんね。
フロントからみたら。
単に http で通信するだけだから。 >通常時は処理は0.02〜3秒くらいだから
それが分かってるならタイムアウトを1秒とか0.5秒とかにしてもいいんじゃない それしかないですね。
あとは yutori が持っているかもしれない、httpd の 自動リブート機能を入れてもらう。 >>963
きっと、どのサーバにも入っているんだと思うんです。
でもそれって、httpd が「いなくなった時」にしか働かないんだと思う。
推測ですが。
つまり、httpd が今回みたいに「プロセスとして存在はしているけど、立ち往生状態」
になったら、
もはやそれまでなんじゃないかなと。 で、状況は変化せず、
回復する見込みがないので、
もう少ししたら、c20/c21/c22/c24 のリブート要請を出します。 >>965
リブート要請しました。
4.2 ボーリング場の続きか、
あるいは 5 にして次スレか、、、。 c21 ようやくログインできた。
load averages: 493.51, 504.29, 495.17
同じ症状。 リブート要請受理されました。
たぶんこれで今日は回復するかと。
1) 仮にBGがこけてもフロントがそう簡単に死なないようにする
2) フロントの Apache を一般ユーザでも安全に再起動できる仕組みを入れる
2) は今既に c-docomo5 / c-docomo6 で動いている仕組みを入れればいけます。
sudo コマンドを使います。しくみとか設定方法は明日以降ここにでも。
1) はみんなで考えるということで、、、。 c20 リブート入り、回復した模様。
順次他のサーバもリブートかかるはず。 c21/c22/c24 回復しました。
これで全サーバ回復しました。
>>971
「・・・そういえば?」 yutori/c209 = tiger3501 も自力回復したんじゃなくて、
リブートが入っていた模様。
$ uptime
10:20AM up 1:07, 2 users, load averages: 0.72, 0.79, 1.06 あることを頼まれてたのを実装するのをすっかり忘れてたらしい(^_^;)呑むと色々思い出すとか 中の人からの作業完了報告を受け取りました。
迅速かつ確実な対応をいただき、大変助かりました。
今日はもう意識混濁しているので、
これにてしつれいいたします。おやすみなさい。
>>974
あること、ですか。 ｢だれかボーリング場３で次スレ立てて」(^_^;) 【Love Affair】携帯からのアクセスに対する考察・次の一手 Part4.2 - ボーリング場3
http://qb5.2ch.net/test/read.cgi/operate/1203100286/ うむ
明日頑張る
テストにはyutoriを人為的に落とすということで、 ＼170 名前：マァヴ ◆jxAYUMI09s ／
157 マァヴ ◆＼ ／
＼また失敗した(^_^;)＞p ／Update失敗したらa
／￣￣￣￣￣ ＼ ／://pc11.2ch.net/test/r
＜ おまいら次もいき＼∧∧∧∧∧／ァヴがpc11.2ch.netの鯖
＼＿＿＿＿＿＿＿＜ ＞tp://news23.2ch.net/t
＜ 予 ま ＞また、マァヴ◆jxAYUMI09
＜ た ＞p://news23.2ch.net/te
─────────＜ 感 失 ＞──────────
／￣￣￣￣￣￣￣ ＜ 敗 ＞616 名前：マァヴ ◆jxAY
＜ pc11のBIOSアップ＜ !!!! の ＞>607
＼＿＿＿＿＿＿＿ ＜ ＞ファイルの準備がいまいち
／∨∨∨∨∨＼
＼オーー／ ＼ オフレコ-------------
∧＿∧∧＿／74 名前：マァヴ ◆jxA＼たく言うと、更新用の
（ ） ／ ＼でオフレコ-------
／ BIOSアップデート失敗した(^_^;) ＼ 症状は・・・
1) yutoriがおちた
2) 引きずられて c.2ch.netフロントが全部パニック
3) bgは涼しい顔をしていた
4) Mirvは携帯でc.2ch.netをもてあそんでいた。
5) 私は現場に居ず。外で飲んでいた。
犯人は誰だ ! 今日昼の時間は外にいる予定。
私が見ていたところでは、フロントとBGとの間の通信が
一時的にうまくない状態になったような気がします。
スイッチのトラブルとか、設定変更のタイミングも疑った方がいいのかも。
いずれにせよ上にもあるように、
yutoriを落としてみて症状が再現するかが鍵ですか。 時刻表(^_^;)
c23,c25 18:00までに完成
c26,c27 20日(水)に完成(プレジデンツデーで休日が入った・・・・)
>>989
おー やっぱ再現実験ですよね
あとでやってみようー
「犯人は犯行現場に戻る」という話もありますからね
>>990
りょうかいー
ということはこれから夕方までは待機か・・・
これにかかりっきりだから少し本業もせねば
次スレ
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part4.2 - ボーリング場3
http://qb5.2ch.net/test/read.cgi/operate/1203100286/ bg の動作
[delay処理、差分取得処理は割愛]
（１）c.2ch.net からのリクエストを受け付ける。
（２）リクエストされたデータを 2ch に取りに行く。
（３）c.2ch.net にデータを渡す。
はこんな感じですよね。
そこでいくつか質問です。
質問１）
2chのサーバが落ちていた場合（ bg そのことをを知らない）
（２）は timeout になるまで待ちつづけるであっていますか？
また、そのときは（３）では、 どのようなデータを渡していますか？
質問２）
前回（２）で サーバーが落ちて timeout となったあと再び落ちているサーバにデータを取りに行きますか？
つまり、落ちている可能性が高いんだから暫くはデータを取りに行かないなどの処理をしていますか？
あ、なるほど、、、。
0)yutoriが落ちている状態で、
1)yutoriのdatがほしいフロントがBGにリクエストを出し、
2)BGは普通にネットワークタイムアウトを待ち、
3)その間フロントはBGからの応答をタイムアウトまで待ち、
4)その間もどんどんyutoriへのリクエストがフロントにたまってゆき、
5)最後にはフロントが溢れかえる → 破綻
こんなかんじだと。 そうそう そこですよね
まったく何もしていないのだ !
エレガントなbgにしなくちゃ、
あとは bgが落ちているときはどうすべか・・・
このへんはハーバービューでやる予定だったんだけど
やらねばならないっすね 今日の作業は
1) >>990 c23,c25の追加
2) yutori , bg が落ちたときの挙動の検証
この二つにして、あとは考察タイムにしよう。 このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。 レス数が1000を超えています。これ以上書き込みはできません。
