【Love Affair】携帯からのアクセスに対する考察・次の一手 Part2
■ このスレッドは過去ログ倉庫に格納されています
日増しに増加する携帯からのアクセス。 かつて、羨ブラが生まれたように何かが生まれないと ならない気がする。 たぶん解決策は、時間を売って空間を買うだと思うけど いろいろ考察して、次の一手を決めようかと、 Love Affair 作戦。 Part2 大黒埠頭 前スレ 【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1 http://qb5.2ch.net/test/read.cgi/operate/1075887465/ 質問でーす 転送量で docomo2 : docomo3 = 2:1 くらいになっているのは どうしてなのだろぅ、平均化されないの? http://server.maido3.com/pie/ >>643 >>594 にあるように、ロードバランサのプログラム(pound)が それぞれの一番若い番号で動いてるからすね。 今、 携帯──c-docomo (代表) ├c-docomo2 (実処理1) └c-docomo3 (実処理2) となっています(実体はc-docomo=c-docomo2)。 で、 携帯─2─c-docomo (代表) ├1─c-docomo2 (実処理1) └1─c-docomo3 (実処理2) というふうに処理していますが、c-docomo⇔c-docomo2の処理は同一ホストなので(外に出ない)、 外から見える転送量としては、 携帯⇔c-docomoの部分の2 c-docomo⇔c-docomo3の部分の1 が見えるわけです。 なるほどですー も一つ、別件ですが 現在 c.2ch.net での bbspink の扱いはどうなっているのでしょうか? 上位レイヤーからの要請はたぶん c.2ch.net と bbspink の完全切り離し ですので、c.2ch.net では bbspink は扱わない方向での作業になると思います bbspink は当面、従来どおりの r.i p.i で、 >>645 中身は中の方々でないとなんともいえないですが、 たぶんbbspinkとかは入ってるですね。 うーむ。 今現在BBSPINKには携帯用トップページがないから 2chから切られたらかなりかわいそうかも。 >>645 んじゃ、bbspinkはc.2ch.netから消しときま〜す >>645 そのうち、c.bbspink.comを作る方向なのかな? >>650-651 大人の時間は一旦復活 このあたりの人にちょっと投げかけてみます。 【Project ama】PINKちゃんねる特化型サーバ構築作戦 Part2 http://qb5.2ch.net/test/read.cgi/operate/1082721809/ >>645 FOX ★さん、 上位レイヤーというのは、どんな方なのでしょう? もし完全に強制ではないようなら、 利便性なども考えると、残しておきたいですー 上位レイヤーというのはネットワークのレイヤーのことですな(^_^;) この場合第9層かな? 2ch外のサイトの閲覧に2chのリソースを使用することとかが問題になるのかな? >>654-655 なるほど。。。ありがとうございます。なんとなく分かったような、、、 と言うことは、強制、なのかな…? >第9層 ポリティクス層 ネット上の問題を政治的に整備 各国の法整備 ここか、、 うーん、 bbspinkで、携帯用鯖導入をしてもらえばよいのだが、、、 amaの方にも書いたけど。 私家メニューでの対応に問題がなければ、c→p.iのリンクで個人的には問題ないと。 でもこうなると、それこそi.bbspink.comが急務ですな、、 # まちBBSも対応打ち切りだろねぇ、 あ、この場合の9層って「ネットワークポリシー」とか「サイトポリシー」といったものだと思う、 つまり2chでいうと「ひ(ryの意思」かな、 # 公権力が絡んでたらそれこそガクブル(AAry >>658 過去ログサーバもこっそり兼任してもらえると ●のグレーゾーンが消えて嬉しいかも >>661 これかな?>ひ(ryの意思 709 名前:ひろゆき@どうやら管理人 ★[] 投稿日:04/02/01 12:03 ID:??? エロ系はその気になれば、それなりに回すことも出来るだろうけど、 おいらにやる気もないし、仕事人さんも望まないし、 Jimもそれを望んでない気がするのですね。 【PINKちゃんねる】 新サーバ獲得会議 http://qb3.2ch.net/test/read.cgi/operate/1069071468/709 桃色系は、ここ数ヶ月でかなり状況が動いている気がするのですよ。 トップページがきちんと整理されたり、広告掲載の仕組みができたり、 2ちゃんねるのインフラに依存してないヘッドラインができたり、etc. ということでたぶん、>>663 の状況も少しずつ変わりつつあるのではないかしら。 で、>>639 ですが、 なるほどシステム値をいじってやる必要があるのですね。 機を見てやってみるです。 delayがうまく機能してませんね。120min以下もあれば1時間更新されなかったり。 ラジオ実況カキコんだら1時間以上更新されてないや delayの動きの謎がちょいとわかったかも。 120delayは実行されてない悪寒。そのかわり前回カキコから今回カキコまでの 間隔分がまるまるdelayとして加算されてる感じがする。 こうだとすると2getや流れの早いスレで120delayが無視され、閑散スレで反映が遅いのも 納得がいく感じ。 なぜそうなるかはわからんけど 2ch→携帯スレにも書いたけど、23時頃からみれません エラーでます DoCoMoのFOMAのP2102浸かってます 2ちゃん見れないと激しく鬱です _| ̄|○ 22〜23時にかけて軒並み負荷上がってましたね。 何かトラブルでもあったのかな? http://server.maido3.com/pie/ を見ると docomo2,3 au1,2 others BlackGoat と全部転送量がへこんでますね、 なぜだろう、、、 全部って事は、 一番前か一番後ろが問題だったと 推測できるんだけど、、、不思議。 あとで、root★さんに調べてもらいましょう。 >>670 とかのエラーと何か関係があるのかな? あと、live8もほど同じ時刻に死んでいたみたいだけど、関係あるのかな? >>671-673 倒れている主人に口頭で伝えました。 「申し訳ないけど、明日以降で・・・」 と言っていました。 >>674 お体にはくれぐれもお気をつけくださいと お伝えください。。。 >>674 いつでもいいですよー ちょこっと見た感じでは、特にエラーは無かったです。 横からすんません。ちと教えていただきたいのですが Q.ネットワーク的に、携帯用の各鯖って comic6(banana388) と同じスイッチの下に ぶら下がったりしていますか? http://qb5.2ch.net/test/read.cgi/operate/1088767056/812 P.S. root ★さん、お体をお大事に… >>673 >>677-678 ふうむ、live8のダウンがおおいに影響していそうですね。 blackgoatが落ちたときはともかく、人気があるところが一つ死ぬとこうなるのは、、、。 >>679 >>572 にもあるように、アドレスが近いですね。同じスイッチなのかな。 昨日のcomic6の不調(live8が落ちてしばらく後にcomic6も不調になった)も、 何か関連しているのかも。 >>680 あ、どうもありがとうございます。元スレの方で、継続観測してみます。 今晩も起こるかどうか分かりませんがw なんかレスポンスが悪いような気がする。 トップとかはそこそこ軽いが、スレッドは重い。 BlackGoatの負荷が重くなってるのかな? 転送量規制にかかっているとか。。。 と携帯から妄想してみる >>685 例の、blackgoatが「あふれ出す」時間と一致してますね。 diskdいれてみるか。 まず、 cache_replacement_policy heap GDSF memory_replacement_policy heap LFUDA にしてみた。 diskdを入れるにはkern.ipc.msgmnbとかをいじる必要があって、 それはrebootしないとだめ(sysctlでは不可)みたい。 というわけで、アクセスの多い今の時間はとりあえず保留。 cache_mem を 80 MB に増やしてみた。 負荷が下がったみたい。 あと、cache_swap_lowとcache_swap_highはどうすればいいのかしら。 ちなみにキャッシュディレクトリ(ディスク)は十分おおきいです。 >>690 横からすんまそん。 cache_dir で指定したキャッシュの容量が大きければ、cache_swap_low _high の 差は数百Mbyteにもなるかもしれません。そのためこの2つの数値を近づけた方が いいかも… って記述しかありませんなぁ… とはいえ、_low、_high ってヒステリシスなしきい(←なぜか変換できない(素))値やから あまりシビアな設定にすると、酷い事になりそうやし。 とりあえず、デフォルトの 90、95 で様子を見て調整という、いつものパターンでしょうか? #IME2002のあふぉたれめ。閾が「しきい」で変換できんやんけ 「しきいち」でも「いきち」ちゃんと閾値ってでるぞ IME2000 >>691 実際に大きいので、近づけてみるか。 もうちょっとしたら、blackgoatの設定変更やります。 DDoS食らってる状態になるんだよ みんなリロードしまくるでしょ diskd化完了。 結局、以下をblackgoatのカーネルに入れて再構築&リブート。 # for squid cache options MSGMNB=16384 # max characters per message queue #options MSGMNI=40 # max number of message queue identifiers #options MSGSEG=2048 # max number of message segments in the system #options MSGSSZ=64 # size of a message segment (Must be 2^N) options MSGTQL=1024 # max amount of messages in the system ちょと確認させて頂きたいのですが、 メニューの中身があるサーバは、 c-au1.2ch.net c-au2.2ch.net (docomo1.2ch.netと同じ) c-docomo2.2ch.net c-docomo3.2ch.net c-others.2ch.net (c-others1.2ch.netと同じ) の5種類ということで良いでしょうか? >>697 c-othersのところは他同様、以下が正しいかと。 c-au1.2ch.net c-au2.2ch.net (docomo1.2ch.netと同じ) c-docomo2.2ch.net c-docomo3.2ch.net c-others1.2ch.net maximum_object_size_in_memory をデフォルト(8kbytes)から 1024kbytesにふやしてみた。 これで、datがうまくメモリに乗るようになる? # TAG: maximum_object_size_in_memory (bytes) # Objects greater than this size will not be attempted to kept in # the memory cache. This should be set high enough to keep objects # accessed frequently in memory to improve performance whilst low # enough to keep larger objects from hoarding cache_mem . # #Default: # maximum_object_size_in_memory 8 KB maximum_object_size_in_memory 1024 KB >>701 done. c-docomo[23]、調整中&済み。 c-au[12]、これから少し調整します。 LAそのものはそれほどでもなく、入り口で詰まっているようなので、 様子をみながらhttpdの数を増やしてみた。< 各c-xxxx 臨時にアクセラレータをはずしてみる。もたないか、もつのか。< c-docomo2 ん、アクセスが多いときは、苦しい模様。< c-docomo2 アクセラレータ(キャッシュ)を入れるとamd64ではやや不安定。 アクセラレータをはずすととてももたないのか。 c-docomo2、ほとんど瀕死かも。 c-docomo系が死んだら、c-au系やc-others系のhttpdが捌けるようになった。 blackgoatのI/O処理が滞っていたのか。 Zend-optimaizerの方にしてみるとか。。。 root ★さん、 参考までに、docomo2でのスクリプトの各ポイント毎の単純な処理時間です。 総処理 = 0.50580286979675 ├初期化 = 0.0017189979553223 ├スレッド表示 = 0.50293588638306 | ├ソケット接続〜切断 = 0.5008430480957 | └上記以外の処理 = 0.0020928382873535 └上記以外の処理 = 0.001147985458374 やはり、datを全て読み込んで処理するので、そこがネックになっているようですね。 どうも。 >>710 datをとってくるところが重いですか、、、。 c-docomo2、ログインもできないぐらいつらい状況。 しばらくだめだった場合、リブート依頼します。 BlackGoatへのソケット接続〜切断までの間では、 "レス番1と指定のレス10個分を配列に格納する"という以外の処理は行っていないのですが、 最新10スレッドなどの表示では最後まで読み切らないといけないので時間がかかりますね… これからリブート依頼します。< c-docomo2 >>712 そうですね。 blackgoatのディスクはストライピングにして、 かつnewfs -b 65536 -f 8192などとやってあるのですが、 そろそろI/O性能が苦しい状況なのかも。 今比較のために、一時的にaufsに戻してみた。 *感覚では*、diskdのほうが遅いような気がします。 統計的にも「漏れる」量が多いみたい。< blackgoat >>712 初期読み込みのデフォをレス番1〜11に変更してみては? それで統計取ってみて、最新を取る回数が多かったら戻すとか デフォルトで、1〜11が表示されたら、その後、最新レス10を実行するから、 余計負荷がかかってしまう。 cache_dir diskd /usr/local/squid/cache 100000 16 256 を、 cache_dir diskd /usr/local/squid/cache 100000 64 256 にして、squid -zの後にdiskdモードを復活させてみた。 >>715 さん、 以前i2chでの統計を取ったのですが、 全アクセス中1/3が最新スレッドへのアクセスでした。 ですので、やはり>>716 ◆BFzK/mtqM2さんの仰る通りになってしまうかもです… cobra2247にログインできました。リブートして、調整中。 cobra2247 = c-docomo/c-docomo2 設定更新&リブートかけました。正常にもどったはず。 こんどは、BlackGoatがおなかいっぱいか。 LAは低いけど(プロセスが多いわけではないので)、ディスクI/Oがかなり苦しめの予感。 Disks ad0 ad1 KB/t 25.34 22.48 tps 133 141 MB/s 3.29 3.09 % busy 75 82 %iostat -w 1 -c 10 tty ad0 ad1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 39 25.71 63 1.58 22.53 68 1.49 19 0 29 16 37 0 180 17.53 47 0.80 18.17 48 0.85 39 0 45 16 0 0 59 25.94 200 5.07 24.00 201 4.71 28 0 63 9 0 0 59 31.13 260 7.89 30.37 272 8.08 34 0 61 5 0 0 239 20.51 90 1.80 18.86 97 1.79 32 0 44 25 0 0 59 25.98 164 4.17 22.70 152 3.38 39 0 50 11 0 0 59 23.82 89 2.07 20.53 98 1.97 29 0 45 26 0 0 59 23.95 160 3.75 22.97 146 3.27 39 0 51 10 0 0 59 26.05 81 2.06 22.52 91 2.00 36 0 35 28 0 0 60 26.57 278 7.21 21.11 278 5.73 36 0 64 0 0 パフォーマンスが出ないため、>>717 を前の設定 (16 256) に戻した。 お疲れ様です。 BGへのタイムアウト、もう少し短くしてみますか? bbs.cgiで、逆順のdatも作るようにし、c.2ch.netやread.cgiの初期読み込みではそちらを 使うようにするとか。 キャッシュヒット率が下がって逆効果かな? >>724 今dat取得のタイムアウトは5秒でしたっけ。 タイムアウトを早めると、タイムアウトが頻発するのかな。 今ちょと新しいスクリプトをあげてテストしているのですが、 先程の重い時間帯で3秒設定だとまずタイムアウトです。 5秒でもほとんどタイムアウト状態でした。 タイムアウトで 「今BlackGoatが思いです。。。」とか表示すれば、 リロード抑制にもなるかもですね、、、 5秒超にはしたくない感じです。 大規模squidのボトルネックはHDD回りなので、できればcache_dir用にスライスを確保したほうがいいかも。 noatimeは当然として。 asyncでもいいかも。 容量があんまり小さいスライスだとoptimize TIME to SPACEを食らうので4倍以上で。 あと外周部分にあるとうれしいので/の次に確保してたり。 >>729 いまこんなかんじ。 ccd使って、2本のIDEディスクをストライピングで使用。 /dev/ccd0は、newfs -U -b 65536 -f 8192で初期化。 %pwd /home/squid_local/cache %df -k . Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ccd0 136319544 35531976 89882008 28% /home %mount | grep home /dev/ccd0 on /home (ufs, local, noatime, nosuid, soft-updates) %cat /etc/ccd.conf # ccd ileave flags component devices ccd0 64 none /dev/ad0s1f /dev/ad1s1d ひどいときには両ディスクとも% busyが80%ぐらいになるですね(>>722 )。 途中割り込みでスマソです。 >>730 IDEのストライピングだとつらそうですね。 かといってUltraSCSI320のそれにしようとすると余計な投資になるし・・・ blackgoat自体がキャッシュサーバですから RAMディスクで捌くってのは・・・すでにやっているんですかね。 >>731 メモリディスクか。 現時点では入れてないですね。 squidのプロセスが400Mを超えるようなので、メモリディスクはちょっとどきどき。 というか、入れるとしたらどこがいいのかな。 >>732 その400MBプロセスなsquidってどこのやつですか。 >>733 あ、blackgoatのでつねw wikiに書いてあるの忘れてたw ちょっと考察。 携帯からのある意味実況レベルに近い通信要求を バックエンドを1台で捌くというのはかなりきついと思います。 しかもblackgortが落ちたら携帯からのアクセスは不可能。 投資ができるなら、の話ですが、 もう1台バックエンドを用意して負荷分散させたほうがいいかもしれません。 どちらかのバックエンドが落ちたときにバックアップさせるという意味合いもあるし。 1) フロントエンドを充実させて需要に見合う供給をおこなった。 2) 当然、BlackGoatは大忙し、 3) この大忙しを解決する方法は当初の予定通り、BlackGoatの仕組みで行う というように順調に予定通り進んでいるということですなぁ。 せっかく作り出した重い状態。せっせとデータを取らなければ、、、 BlackGoat の各種データをとって、思考実験(机上演習)です。 帯域等は現在取っているので、アクセス数やそのへんも何とか データが取れないかな? とい段階かと、 BlackGoat を増設するのは考えないで行きます。 だってすぐ解決しちゃうもん。 >>735 負荷分散しても片方が墜ちると共倒れになる悪寒ですよね。。。@基本的に片肺でも生きていかないと・・ ちょっと考察。 最新 10 スレの取得方法案。 HEAD で DAT の Content-length を取得。 Content-length から 20480 引いた場所から末尾まで取得。( 1 レスは最大で2048Bytes でしたっけ?) Range: bytes=(Content-length-20480)-(Content-length-1) \n を区切りにして、末尾から 10 レス取得。 my @Part_Log = (reverse split /\n/,<DAT>)[0..9]; 演算が増えるけれどもその分、 DAT 採取のコストが幾分か下がるのではないかと。。。 もしかして、分割して取得するとキャッシングがうまく効くのかな? 例えば。。。 活きのいい DAT があっても、全取得となるとキャッシュが効かないはず。 でも、例えば先頭から 4KB は活きが良くても悪くても、内容はあぼーんが入らない限り変わらないはずなので、 この部分は ETag: を使って照合すれば、うまくキャッシングされているのではないだろうか?と。 ただし、ETag の管理をするために、また複雑な操作が必要になってくるかもかも。。。 (殊に呼び出し側の c-* 族の I/O 処理とかとか) >>736 そのとおりっすねぇ。 いろいろ試行錯誤してるわけですが、スキル不足のためなかなかはかどらず。 なかなかつらいすけど、いい経験させていただいているぐらいに思うのがいいのかも。 アクセス数は負荷を上げない方法でぜひとりたいですね。 例えばどの時間にどの板に要求が多いのかとか、とりたいことはいろいろ。 >>735 >>737 バックエンドを2台(横並び)体制にするなら、何か考える必要があるすね。 いずれはそうなることも視野に入れる必要がありそう。 そこで、BlackGoat に疑惑が集まっているのですが、 この辺が明らかになればいいなぁ。。。 1) 観測された c.2ch.net に起こった現象 (docomoが重いとか、) 2) 推測される原因 (BlackGoatの反応が遅すぎ) 3) BlackGoat に起っているであろう現象、具体的な症状の推測 (LA の増大とか) 4) 実際にその具体的な症状がせ起っているか、 5) 起っているなら、解決策は? ここで重要なのは、 3) -> 4) の関係です。 3) で推測して、実際に 4) で現象が起っているかどうかの確認。 確認手段が無い場合は、手段を作る。逆に、こうすれば解決するのでは? という作業は間違っても行ってはいけない。 >>740 > 逆に、こうすれば解決するのでは? > という作業は間違っても行ってはいけない。 きもにめいじます。 >>740 で、いまのところ起こっているのは、ディスクI/O負荷の増大なわけです。 あとは、苦しい時間(昼とか夜23:00ごろとか)に、キャッシュの効きが悪くなる。 いずれにせよ、観察・確認できる手段をなんとかする方向で動いてみます。 とりあえずsnmpあたりでつついてみるか。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる