【Love Affair】携帯からのアクセスに対する考察・次の一手 Part2
■ このスレッドは過去ログ倉庫に格納されています
日増しに増加する携帯からのアクセス。 かつて、羨ブラが生まれたように何かが生まれないと ならない気がする。 たぶん解決策は、時間を売って空間を買うだと思うけど いろいろ考察して、次の一手を決めようかと、 Love Affair 作戦。 Part2 大黒埠頭 前スレ 【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1 http://qb5.2ch.net/test/read.cgi/operate/1075887465/ 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あたりでつついてみるか。 >ディスクI/O負荷の増大なわけです という推測があった場合、 じゃ具体的に、定量的に BlackGoat でどういう数字がでているかを推測して かつ実際に計測して、どうなっているか、、 もし推測と実測値が極めて一致したならば 最初の命題「ディスクI/O負荷の増大なわけです」 という推測がかなりピンポンであるといえるかと、 もし他にもこの図式がなりたてば、ほぼ確実といえるかと、 >>740 資料が無いのでどうしても机上の空論だけになってしまいますよね(汗) って事でもうしばらく静観してます m(_ _)m >>739 そうですか。 現状では1台でなんとかなっていますし、 今のうちに問題点を洗っておいたほうが良いという >>736 の狐の内臓の人の意見には同意です。 とりあえず >バックエンドを2台(横並び)体制にするなら、何か考える必要があるすね。 >いずれはそうなることも視野に入れる必要がありそう。 みたいな認識で十分かと。 >>732 400Mって。 squid.confはちゃんとmemory_pools offになってますか? デフォルトはonなのですがメモリ管理はカーネルに任せた方がいいのでoffにしないと。 http://mumumu.mu/mrtg/mrtg-rrd.cgi/loveaffair/ >>746 いまこんなかんじすね。 PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 32057 squid -8 0 398M 395M biord 59:41 20.41% 20.41% squid memory_poolsはデフォルト(on)。 onとoff、どっちがいいのかな。 # blackgoatはmemory 1G積んでます。squid以外の仕事はしていない。 うすうすわかってはいたけど、深夜の時間(混む時間)は、 リクエスト数はあまり変わらないのに、キャッシュヒット率が下がる。 http://mumumu.mu/mrtg/mrtg-rrd.cgi/loveaffair/blackgoat-hits.html で、datをひんぱんに外に取りに行くので処理に時間がかかるし、 その分携帯とのコネクションも滞留する。 この原因は何だろう。 夜の時間は「いろんなところのスレが参照される」から、キャッシュにない場合が増える、 ということなのかな。 で、リクエスト数自体がその時間もあまり変わらないのは、 ひょっとすると携帯ネット=>インターネットの間で、何かのリミッターが入っているのかも、かも。 パケット落ちはないから、ネットワークまわりやスイッチ関係じゃなさそうだなぁ。 --- comic6.2ch.net ping statistics --- 201 packets transmitted, 200 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.948/10.371/116.189/14.277 ms う、激しく誤爆した。 OpenJaneを立ち上げなおそう。すまそ。 memory_pools はoffのほうが良いです。 BSD Magazineのシステムチューニングの回参照 こちらにも。 携帯→2ch運用情報スレッド10 http://qb5.2ch.net/test/read.cgi/operate/1089186698/639 639 名前:root ★[sage] 投稿日:04/07/29 11:46 ID:??? キャッシュ効果の観察のため、いったんblackgoatのキャッシュをゼロクリアしました。 その影響で数分間、c系が不安定になったかも。 今は正常に戻ったはず。 >>755 にすると、 2004/07/28 20:38:59| assertion failed: comm.c:751: "p != NULL" というエラーが出て、squidが死ぬ模様。 後で調べることにして、いったん退却(memory_pools onに戻しました)。 >>757 8. Key changes squid-2.5.STABLE5 to 2.5.STABLE6: * Several "Assertion error" bugs fixed これの関係かしらん? >>758 今のもの: 2004/07/28 20:41:01| Starting Squid Cache version 2.5.STABLE5 for i386-portbld-freebsd5.2.1... …つまり、STABLE6にしろと。 だめですね。やはり出ます。 2004/07/28 21:54:12| assertion failed: comm.c:751: "p != NULL" もとに戻しました。 >>759 http://www.squid-cache.org/bugs/show_bug.cgi?id=761 こちらを判らないながらも眺めてみたのですが、違う種のアサーションエラーみたいですね。 でもって、最新の ports が存在するのかな?(@まだ ports の仕組みが判ってなかったりもしますけれども(苦笑) ・・・と書いているうちに、、、 >>760 おつですおつですm(_ _)m この一時間のcomic6の様子ですが、、、 comic6.2ch.net サーバ .dat 呼び出し回数 = 59632 deny from 206.223.150.190 #(7465) 12.52% BlackGoat からこんなにたくさん。。。 これで正常なのか、異常なのか、 >>764 15:00(JST)台ですか。 アクセスログを確認してみます。 まだログを見ていませんが、今日の昼にやった >>756 の作業が影響しているのかもです。>>764 >>763 投げるべきでしょう。結果は期待できないですがね。 「やるべき事」と本質がずれてしまいますが(squid の bug 探し、潰し)… squid 本家に投げてみるというのも、手かもしれない。 bug track 見てる限りでは、comm.c での assertion faild は出てないみたいですね。 チト source 引っ張ってきて覗いてみたら、 1.何か(すんません、真剣に見てません)の handler 削除のために、 comm_remove_close_handler() call 2.削除対象探索 in comm_remove_close_handler(), comm.c が、探索のキモの部分が for(xxxx; p != NULL; xxxx) になってて、探索対象が 見つからなければ、for() を抜けて、assert(p != NULL); で落っこちる。 つうことで、多分 memory_pools off の時に、無用な comm_remove_close_handler call が起こってるんでしょうなぁ。 んーそこで落っこちるということはsquid.confで矛盾した設定をしているような気が。 【.htaccess】読みこみできない【規制作戦】 http://qb5.2ch.net/test/read.cgi/operate/1082968554/868 でポイントした、 http://pc5.2ch.net/test/read.cgi/linux/997328024/182-189 にあった、 > reload-into-imsはno-cacheとreloadの命令をIf-Modified-Sinceの > リクエストに変えてしまうもの。つまり無いのに、あるかのように装って差分だけ > 送れと言うわけなのれす。 を読んで、reload-into-ims も追加設定してみた。< blackgoat http://qb5.2ch.net/test/read.cgi/operate/1082968554/866-868 refresh_patternのminの値は最終更新日時があると参照されない >FRESH if lm-factor < percent, else STALE ここでSTALE(古い)と判断されたときoverride-lastmodが有効だと >FRESH if age < min >else STALE これがテストされる(minの値が参照される) ということか。 つまり、今まで120delayはまったく効いてなかったということだな。 DATをかっさらう悪用で.htaccessで携帯メニューをダウンさせる不届きものが…。 (パクリトロスの2ちゃんねるアーカイブとか言う香具師) 対策しないと、c.2chに円滑に移行出来た所で本末転倒では…。 ただいま帰宅しました。 とりあえず、i.i2ch.netの方は再開しました。 さてこのあとどうしましょうか? > ひろゆきさん、FOX★さん、root★さん (1) 現状のまま219.113.242.218から直接差分を取る。 (2) GlackGoatを通して差分を取る。 (3) GlackGoatを通して差分せずに取る。 (4) 私家版GlackGoatを作るって、そっちで(2)か(3) 他の私家板(domo2.netなど)にも、開放できるように(4)というのもありなんじゃないかと思ったりして、、、 >>776 たぶん ×GlackGoat ○BlackGoat BlackGoatが落ちたりしたら、私家版全てが使えなくなるってのモナー。 今回のはミラーでディレイ0秒になってたからでそ。 ディレイ60秒くらいにしてやれば、問題ないのでわ? 実況でディレイで新着が見られない ↓ 新着と同じレスしてしまう ↓ 重婚発生 ↓ 鯖資源の無駄 そもそもディレイなしでも携帯で実況すれば 重婚しまくると思われ ディレイ調節は、不便だけで、あまり絶対的な効果はないような??? >>785 間にBlackGoatのような 大規模キャッシュがあり、 同一スレについて複数 リクエストがあっても、 最低60秒は更新しない とかなら有効だと思います。 有効ではなく絶対的な効果があるのか?と聞いているのですが…。 単純な個人ユーザーにとって、2分間のディレイは大変な不便を感じています。 >>783 と同様の事になる。 あと、実況以外でも”からけよめ”と煽られる。 絶対的な効果ありまくりです(^_^;)2chの掲示板サーバの負荷が二桁くらい下がる システムが落ち着いたら、c系のディレイ60あたりにしません? 120は結構不便なような気がするのですが、、、 >>787 不満でしたらマシン代を寄付してやって下ちい >>root ★さん、 質問なのですが、 現在c.2ch.netにアクセスすると、各キャリアごとに振り分けられたサーバにリダイレクトされます。 DoCoMoなら、c-docomo。(http://c-docomo.2ch.net/z/-/1C/i ) auなら、c-au。(http://c-au.2ch.net/z/-/1C/i ) その他は、c-others。(http://c-others.2ch.net/z/-/1C/i ) 1) このドメイン部分をc.2ch.netで見せることは可能なのでしょうか? つまり、実際はc-docomo2やc-docomo3に振り分けられていても、 アドレス上はc-docomoであるのと同じように見せることは可能でしょうか? 2) 例えば他キャリアがそのアドレスにアクセスしたときに、 そのキャリア用のサーバにリダイレクトすることは可能でしょうか? つまり、auで(http://c-docomo.2ch.net/z/-/1C/i )にアクセスした場合、 (http://c-au.2ch.net/z/-/1C/i )にリダイレクトすることは可能でしょうか? 3) もし上記どちらかが可能な場合、それを行う上で何か不都合なことは発生しますでしょうか? 昨日の20時ころからHIT率が下がっているけど、何か設定変えましたか? 5分遅延すれば実況とかチャットとかは機能停止させられるような c-docomo2の負荷が突出してる(^_^;)なんだろう? >>796 c-docomo3 の 16:03 JST(00:03 PST+8PDT) の cron で、何かがすっころんでる悪寒ですね。 c-docomo3 の中には入れないのであくまでも悪寒ですけれども。 >>797 と思ったら直った。。。 何かがすっころんだのではなく、処理が重たかっただけなのかな? http://server.maido3.com/pie/graph/oyster246.gif を見る限りでは正常稼働していたようですので。 海外出張中につきレスポンス悪いです。 >>792 1)技術的にはもちろんできますが、そうすると全部1箇所で処理するようになりますからね。 ちょっと負荷的に。あと、cに何かあったときに全部落ちることにもなるので。 携帯だとブックマークに入れて処理する人が多いようなので、 最初の振り分けのところは、あえて名前を変えて飛ばすようにしていたりします。 2)これは簡単です。 3)2)は不都合ないしそれによる副作用も特にないので、入れてみてもOKです。 でも、意味あるのかな。 わざとアクセスしないと、auでc-docomoにアクセスすることはないような。 >>794 夜の時間とか昼休みの時間は、どうも多くの板の多くのスレにアクセスがいくようで、 ヒット率が下がる傾向にあります。 時間あたりのアクセス数が多くならないのは、ひょっとすると携帯キャリア側で 何か口を絞っているのかも。 >>796-799 例のdaily処理問題かも。ううむ。 >>800 > でも、意味あるのかな。 > わざとアクセスしないと、auでc-docomoにアクセスすることはないような。 そうでもないです。URLを貼る場合に、仕組みを知ってる人ならc.2ch.netに置き換えて貼るでしょうけど、 知らない人はそのまま貼るでしょうから。 >rootさん 海外出張お疲れ様です。 こまめに水分補給してくださいね。 なるほど、確かにアクセスが増加する昼時と夜は下がりますね。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる