【Love Affair】携帯からのアクセスに対する考察・次の一手 Part2

**FOX ★** · 04/07/01 13:55

日増しに増加する携帯からのアクセス。
かつて、羨ブラが生まれたように何かが生まれないと
ならない気がする。

たぶん解決策は、時間を売って空間を買うだと思うけど
いろいろ考察して、次の一手を決めようかと、

Love Affair 作戦。
Part2 大黒埠頭

前スレ
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1
http://qb5.2ch.net/test/read.cgi/operate/1075887465/

[―{}@{}@{}-] m01vtr021.comp.dion.ne.jp · 04/07/23 19:10

将来的に/i/index.htmlは消すのかな？そうだと>>622は無意味か。

[―{}@{}@{}-] m01vtr021.comp.dion.ne.jp · 04/07/23 19:12

リロードし忘れ。
>>623
そうですね。しばらくtopにリンクで安定してきたらoperate/i/を削除のほうが。

**動け動けウゴウゴ２ちゃんねる** · 04/07/23 21:45

>>612の質問は徹底的に無視ですか、、、

**動け動けウゴウゴ２ちゃんねる** · 04/07/23 21:58

まさにその話をしているような？

**動け動けウゴウゴ２ちゃんねる** · 04/07/23 22:03

大変失礼しました

**動け動けウゴウゴ２ちゃんねる** · 04/07/23 22:05

既にr.i再開してますよ、この板。

**動け動けウゴウゴ２ちゃんねる** · 04/07/23 22:54

c-docomo不思議な挙動しますね。120delayがうまく機能してないような。

・立ったばかりのスレで2get等のカキコはdelay無視で即反映
・カキコが少ないスレは120以上のdelayがある。

subject.txtの不釣り合いはどうしようもないところか。

**root ★** · 04/07/24 00:11

squidのキャッシュヒット率が下がってるみたい。
設定の問題か。ちょっとblackgoatの様子をみてこよう。

**root ★** · 04/07/24 00:21

ディスクキャッシュを少し増やしてみた。

**動け動けウゴウゴ２ちゃんねる** · 04/07/24 00:29

そういえばリバースプロクシのsquid.confの設定ってどうなってます？
自分は
cache_replacement_policy heap GDSF
memory_replacement_policy heap LFUDA
cache_dir null /tmp
とかにしてる。

**root ★** · 04/07/24 00:31

squidの設定はあんまりまじめに詰めてないです。見てみるか。

**root ★** · 04/07/24 00:38

blackgoatのsquidはリバースじゃなくて普通のだから、cachr_dir nullはちょっと。
cache_replacement_policy と memory_replacement_policy はデフォルトです。

squidのリバースプロキシ機能は今のところ使ってないすね。

ロードバランシングはpoundを使用。
担当を3つに分けてからはそれなりにうまくいってるみたい。

**root ★** · 04/07/24 00:47

あんまりかわんないなぁ。

1090597580.673 10385 192.168.0.101 TCP_SWAPFAIL_MISS/200 72252 GET http://hobby5.2ch.net/drama/dat/1083775457.dat - DIRECT/206.223.150.10 text/plain
1090597580.673 10082 192.168.0.101 TCP_SWAPFAIL_MISS/200 66239 GET http://game7.2ch.net/ogame/dat/1090506363.dat - DIRECT/206.223.151.135 text/plain

がたくさん出てる。

**動け動けウゴウゴ２ちゃんねる** · 04/07/24 02:47

だったらcache_dir diskdのほうがヨサゲ。
Squidの開発者のベンチマークでもdiskdが桁外れに速いので推奨している感じ。
memory_replacement_policyについてはちょっと前のBSD Magazineでheap LFUDAを推奨してた。

**root ★** · 04/07/24 02:56

>>637
diskdは最初試してみたのです。
で、なんかうまくいかなかった。(>>142)
また再挑戦してみるか。

memory_replacement_policyは、機を見て別途。

**動け動けウゴウゴ２ちゃんねる** · 04/07/24 03:04

高負荷時にGENERICでdiskdが死ぬのは
http://www.squid-cache.org/Doc/FAQ/FAQ-22.html#ss22.6
あたりを参照してみてください。でもちょっと数値は古いのでチューニングする余地有り。
あと
ttp://www.fkimura.com/squid0.html
とか。
http://pc5.2ch.net/test/read.cgi/unix/1034236482/228
とか。

**動け動けウゴウゴ２ちゃんねる** · 04/07/24 14:02

いまのところc-docomo安定してますね。ただ、まもなく16時。トラブル頻発の時間帯。

04/07/24 14:23

ワクワク！大曲刻！１６：００

04/07/24 14:30

http://ch2.ath.cx/load/images/cedf97d7.png
c-docomo2
http://ch2.ath.cx/load/images/cedf97d2.png
c-docomo3
http://ch2.ath.cx/load/images/cedf9691.png
c-others1

**FOX ★** · 04/07/24 15:14

質問でーす

転送量で docomo2 : docomo3 = 2:1 くらいになっているのは
どうしてなのだろぅ、平均化されないの?
http://server.maido3.com/pie/

**root ★** · 04/07/24 15:31

>>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

が見えるわけです。

**FOX ★** · 04/07/24 15:38

なるほどですー

も一つ、別件ですが
現在 c.2ch.net での bbspink の扱いはどうなっているのでしょうか?
上位レイヤーからの要請はたぶん c.2ch.net と bbspink の完全切り離し
ですので、c.2ch.net では bbspink は扱わない方向での作業になると思います

bbspink は当面、従来どおりの r.i p.i で、

04/07/24 15:48

なぬっ

**root ★** · 04/07/24 15:49

>>645
中身は中の方々でないとなんともいえないですが、
たぶんbbspinkとかは入ってるですね。

**動け動けウゴウゴ２ちゃんねる** · 04/07/24 16:14

>>645
なんと。

**動け動けウゴウゴ２ちゃんねる** · 04/07/24 16:23

うーむ。
今現在BBSPINKには携帯用トップページがないから
2chから切られたらかなりかわいそうかも。

◆BFzK/mtqM2 · 04/07/24 17:54

>>645
んじゃ、bbspinkはc.2ch.netから消しときま～す

◆BFzK/mtqM2 · 04/07/24 18:05

>>645
そのうち、c.bbspink.comを作る方向なのかな？

◆BFzK/mtqM2 · 04/07/24 18:47

>>650-651

大人の時間は一旦復活

このあたりの人にちょっと投げかけてみます。
【Project ama】PINKちゃんねる特化型ｻｰﾊﾞ構築作戦 Part2
http://qb5.2ch.net/test/read.cgi/operate/1082721809/

◆EA.clAssIc · 04/07/24 18:50

>>645 FOX ★さん、
上位ﾚｲﾔｰというのは、どんな方なのでしょう?
もし完全に強制ではないようなら、
利便性なども考えると、残しておきたいですー

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/24 18:52

上位レイヤーというのはネットワークのレイヤーのことですな(^_^;)
この場合第９層かな？

**動け動けウゴウゴ２ちゃんねる** · 04/07/24 18:54

2ch外のサイトの閲覧に2chのリソースを使用することとかが問題になるのかな？

◆EA.clAssIc · 04/07/24 18:58

>>654-655
なるほど。。。ありがとうございます。なんとなく分かったような、、、
と言うことは、強制、なのかな…?

**動け動けウゴウゴ２ちゃんねる** · 04/07/24 19:04

＞第9層　ポリティクス層　ネット上の問題を政治的に整備　各国の法整備
ここか、、

◆BFzK/mtqM2 · 04/07/24 19:07

うーん、

bbspinkで、携帯用鯖導入をしてもらえばよいのだが、、、

**動け動けウゴウゴ２ちゃんねる** · 04/07/24 19:26

そういえばまちBBSの扱いはどうなのかな。

◆g4HrV7ViKA · 04/07/24 20:48

amaの方にも書いたけど。
私家メニューでの対応に問題がなければ、c→p.iのリンクで個人的には問題ないと。
でもこうなると、それこそi.bbspink.comが急務ですな、、
# まちＢＢＳも対応打ち切りだろねぇ、

◆g4HrV7ViKA · 04/07/24 21:02

あ、この場合の９層って「ネットワークポリシー」とか「サイトポリシー」といったものだと思う、
つまり２ｃｈでいうと「ひ(ryの意思」かな、
# 公権力が絡んでたらそれこそガクブル(AAry

**動け動けウゴウゴ２ちゃんねる** · 04/07/24 21:04

>>658
過去ログサーバもこっそり兼任してもらえると
●のグレーゾーンが消えて嬉しいかも

**動け動けウゴウゴ２ちゃんねる** · 04/07/24 22:27

>>661
これかな？＞ひ(ryの意思

709 名前：ひろゆき＠どうやら管理人 ★[] 投稿日：04/02/01 12:03 ID:???
エロ系はその気になれば、それなりに回すことも出来るだろうけど、
おいらにやる気もないし、仕事人さんも望まないし、
Jimもそれを望んでない気がするのですね。

【PINKちゃんねる】新サーバ獲得会議
http://qb3.2ch.net/test/read.cgi/operate/1069071468/709

◆MUMUMUhnYI **＠むむむ ★** · 04/07/25 02:28

桃色系は、ここ数ヶ月でかなり状況が動いている気がするのですよ。
トップページがきちんと整理されたり、広告掲載の仕組みができたり、
２ちゃんねるのインフラに依存してないヘッドラインができたり、etc.

ということでたぶん、>>663 の状況も少しずつ変わりつつあるのではないかしら。

**root ★** · 04/07/25 02:29

で、>>639 ですが、
なるほどシステム値をいじってやる必要があるのですね。
機を見てやってみるです。

proxy109.docomo.ne.jp · 04/07/25 10:02

delayがうまく機能してませんね。120min以下もあれば1時間更新されなかったり。
ラジオ実況カキコんだら1時間以上更新されてないや

[―{}@{}@{}-] **お助け侍** ◆G9KmnX7GLM · 04/07/25 10:42

>>665
rootさん
auが
携帯→2ch運用情報スレッド10
http://qb5.2ch.net/test/read.cgi/operate/1089186698/

**動け動けウゴウゴ２ちゃんねる** · 04/07/25 11:21

delayの動きの謎がちょいとわかったかも。

120delayは実行されてない悪寒。そのかわり前回カキコから今回カキコまでの
間隔分がまるまるdelayとして加算されてる感じがする。
こうだとすると2getや流れの早いスレで120delayが無視され、閑散スレで反映が遅いのも
納得がいく感じ。

なぜそうなるかはわからんけど

**root ★** · 04/07/25 11:25

>>668
ありうるかも。ううむ。

**動け動けウゴウゴ２ちゃんねる** · 04/07/25 23:29

2ch→携帯ｽﾚにも書いたけど、23時頃からみれません
エラーでます
ＤｏＣｏＭｏのFOMAのP2102浸かってます
2ちゃん見れないと激しく鬱です
_|￣|○

◆BFzK/mtqM2 · 04/07/26 01:07

22～23時にかけて軒並み負荷上がってましたね。
何かトラブルでもあったのかな？

**FOX ★** · 04/07/26 01:10

http://server.maido3.com/pie/　を見ると
docomo2,3 au1,2 others BlackGoat と全部転送量がへこんでますね、

なぜだろう、、、

全部って事は、一番前か一番後ろが問題だったと
推測できるんだけど、、、不思議。

◆BFzK/mtqM2 · 04/07/26 01:26

あとで、root★さんに調べてもらいましょう。
>>670とかのエラーと何か関係があるのかな？
あと、live8もほど同じ時刻に死んでいたみたいだけど、関係あるのかな？

**よよよ** ◆EX/mumumu2 · 04/07/26 03:24

>>671-673
倒れている主人に口頭で伝えました。
「申し訳ないけど、明日以降で・・・」
と言っていました。

**動け動けウゴウゴ２ちゃんねる** · 04/07/26 03:25

>>674
お体にはくれぐれもお気をつけくださいと
お伝えください。。。

◆BFzK/mtqM2 · 04/07/26 03:31

>>674
いつでもいいですよー
ちょこっと見た感じでは、特にエラーは無かったです。

**動け動けウゴウゴ２ちゃんねる** · 04/07/26 06:10

>>672
転送量は下がってるけど、負荷は上がってる。
http://ch2.ath.cx/load/c-docomo2.html
http://ch2.ath.cx/load/c-au1.html

で、live8が落ちてた時間と一致しているので、datを取りに行こうとして
timeoutするまで処理が止まってしまうためでは？
http://ch2.ath.cx/load/live8.html

**FOX ★** · 04/07/26 11:46

>>677
おっ　たしかに、
それですね、

**動け動けウゴウゴ２ちゃんねる** · 04/07/26 12:55

横からすんません。ちと教えていただきたいのですが

Ｑ．ネットワーク的に、携帯用の各鯖って comic6(banana388) と同じスイッチの下に
　ぶら下がったりしていますか？

http://qb5.2ch.net/test/read.cgi/operate/1088767056/812

P.S.
root ★さん、お体をお大事に…

**root ★** · 04/07/26 14:16

>>673 >>677-678
ふうむ、live8のダウンがおおいに影響していそうですね。
blackgoatが落ちたときはともかく、人気があるところが一つ死ぬとこうなるのは、、、。

>>679
>>572 にもあるように、アドレスが近いですね。同じスイッチなのかな。
昨日のcomic6の不調(live8が落ちてしばらく後にcomic6も不調になった)も、
何か関連しているのかも。

**動け動けウゴウゴ２ちゃんねる** · 04/07/26 14:48

>>680 あ、どうもありがとうございます。元スレの方で、継続観測してみます。
今晩も起こるかどうか分かりませんがｗ

◆EA.clAssIc · 04/07/26 16:28

ﾀｲﾑｱｳﾄを5秒にしてみました

**root ★** · 04/07/26 21:18

遅延関連の設定をいじりました。

c.2ch不具合報告総合スレ
http://qb5.2ch.net/test/read.cgi/operate/1088828988/121-123

これで、改善するかどうか。

◆BFzK/mtqM2 · 04/07/26 21:35

なんかレスポンスが悪いような気がする。
トップとかはそこそこ軽いが、スレッドは重い。
BlackGoatの負荷が重くなってるのかな？

◆BFzK/mtqM2 · 04/07/26 21:39

転送量規制にかかっているとか。。。

と携帯から妄想してみる

**root ★** · 04/07/26 21:42

>>685
例の、blackgoatが「あふれ出す」時間と一致してますね。
diskdいれてみるか。

**root ★** · 04/07/26 21:47

まず、

cache_replacement_policy heap GDSF
memory_replacement_policy heap LFUDA

にしてみた。

**root ★** · 04/07/26 21:58

diskdを入れるにはkern.ipc.msgmnbとかをいじる必要があって、
それはrebootしないとだめ(sysctlでは不可)みたい。

というわけで、アクセスの多い今の時間はとりあえず保留。

**root ★** · 04/07/26 22:26

cache_mem を 80 MB に増やしてみた。
負荷が下がったみたい。

**root ★** · 04/07/26 22:29

あと、cache_swap_lowとcache_swap_highはどうすればいいのかしら。
ちなみにキャッシュディレクトリ(ディスク)は十分おおきいです。

**動け動けウゴウゴ２ちゃんねる** · 04/07/27 01:07

>>690 横からすんまそん。
cache_dir で指定したキャッシュの容量が大きければ、cache_swap_low _high の
差は数百Ｍｂｙｔｅにもなるかもしれません。そのためこの２つの数値を近づけた方が
いいかも… って記述しかありませんなぁ…
とはいえ、_low、_high ってヒステリシスなしきい（←なぜか変換できない（素））値やから
あまりシビアな設定にすると、酷い事になりそうやし。

とりあえず、デフォルトの 90、95 で様子を見て調整という、いつものパターンでしょうか？

＃ＩＭＥ２００２のあふぉたれめ。閾が「しきい」で変換できんやんけ

**動け動けウゴウゴ２ちゃんねる** · 04/07/27 01:09

「いきち」が正しい、はず。

◆BFzK/mtqM2 · 04/07/27 01:19

「しきいち」でも「いきち」ちゃんと閾値ってでるぞ　IME2000

**root ★** · 04/07/27 01:33

>>691
実際に大きいので、近づけてみるか。

もうちょっとしたら、blackgoatの設定変更やります。

**動け動けウゴウゴ２ちゃんねる** · 04/07/27 02:09

DDoS食らってる状態になるんだよみんなリロードしまくるでしょ

**root ★** · 04/07/27 02:47

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

◆EA.clAssIc · 04/07/27 18:46

ちょと確認させて頂きたいのですが、
ﾒﾆｭｰの中身があるｻｰﾊﾞは、

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種類ということで良いでしょうか?

**root ★** · 04/07/27 19:15

>>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

◆EA.clAssIc · 04/07/27 19:19

>>698
了解です、ありがとうございます。

**root ★** · 04/07/27 22:53

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

**root ★** · 04/07/27 22:59

c-others1、調整中。

**root ★** · 04/07/27 23:05

>>701 done.
c-docomo[23]、調整中&済み。
c-au[12]、これから少し調整します。

**root ★** · 04/07/27 23:09

とりあえずdone.
しばらくチェック。

**root ★** · 04/07/27 23:23

LAそのものはそれほどでもなく、入り口で詰まっているようなので、
様子をみながらhttpdの数を増やしてみた。< 各c-xxxx

**root ★** · 04/07/27 23:33

臨時にアクセラレータをはずしてみる。もたないか、もつのか。< c-docomo2

**root ★** · 04/07/27 23:35

ん、アクセスが多いときは、苦しい模様。< c-docomo2

アクセラレータ(キャッシュ)を入れるとamd64ではやや不安定。
アクセラレータをはずすととてももたないのか。

**root ★** · 04/07/27 23:40

c-docomo2、ほとんど瀕死かも。

c-docomo系が死んだら、c-au系やc-others系のhttpdが捌けるようになった。
blackgoatのI/O処理が滞っていたのか。

◆BFzK/mtqM2 · 04/07/27 23:42

Zend-optimaizerの方にしてみるとか。。。

◆EA.clAssIc · 04/07/27 23:46

root ★さん、
参考までに、docomo2でのｽｸﾘﾌﾟﾄの各ﾎﾟｲﾝﾄ毎の単純な処理時間です。
総処理 = 0.50580286979675
├初期化 = 0.0017189979553223
├ｽﾚｯﾄﾞ表示 = 0.50293588638306
｜　├ｿｹｯﾄ接続～切断 = 0.5008430480957
｜　└上記以外の処理 = 0.0020928382873535
└上記以外の処理 = 0.001147985458374

◆BFzK/mtqM2 · 04/07/27 23:47

やはり、datを全て読み込んで処理するので、そこがネックになっているようですね。

**root ★** · 04/07/27 23:50

どうも。

>>710 datをとってくるところが重いですか、、、。

c-docomo2、ログインもできないぐらいつらい状況。
しばらくだめだった場合、リブート依頼します。

◆EA.clAssIc · 04/07/27 23:53

BlackGoatへのｿｹｯﾄ接続～切断までの間では、
"ﾚｽ番1と指定のﾚｽ10個分を配列に格納する"という以外の処理は行っていないのですが、
最新10ｽﾚｯﾄﾞなどの表示では最後まで読み切らないといけないので時間がかかりますね…

**root ★** · 04/07/27 23:53

これからリブート依頼します。< c-docomo2

**root ★** · 04/07/28 00:00

>>712
そうですね。
blackgoatのディスクはストライピングにして、
かつnewfs -b 65536 -f 8192などとやってあるのですが、
そろそろI/O性能が苦しい状況なのかも。

今比較のために、一時的にaufsに戻してみた。
＊感覚では＊、diskdのほうが遅いような気がします。
統計的にも「漏れる」量が多いみたい。< blackgoat

**動け動けウゴウゴ２ちゃんねる** · 04/07/28 00:02

>>712
初期読み込みのデフォをレス番1～11に変更してみては？
それで統計取ってみて、最新を取る回数が多かったら戻すとか

◆BFzK/mtqM2 · 04/07/28 00:07

デフォルトで、１～11が表示されたら、その後、最新レス10を実行するから、
余計負荷がかかってしまう。

**root ★** · 04/07/28 00:26

cache_dir diskd /usr/local/squid/cache 100000 16 256
を、
cache_dir diskd /usr/local/squid/cache 100000 64 256

にして、squid -zの後にdiskdモードを復活させてみた。

◆EA.clAssIc · 04/07/28 00:38

>>715さん、
以前i2chでの統計を取ったのですが、
全ｱｸｾｽ中1/3が最新ｽﾚｯﾄﾞへのｱｸｾｽでした。
ですので、やはり>>716 ◆BFzK/mtqM2さんの仰る通りになってしまうかもです…

**root ★** · 04/07/28 00:48

cobra2247にログインできました。リブートして、調整中。

**root ★** · 04/07/28 00:48

cobra2247 = c-docomo/c-docomo2

**root ★** · 04/07/28 00:53

設定更新&リブートかけました。正常にもどったはず。

**root ★** · 04/07/28 01:31

こんどは、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

**root ★** · 04/07/28 01:38

パフォーマンスが出ないため、>>717 を前の設定 (16 256) に戻した。