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

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

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

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

Love Affair 作戦。
Part2 大黒埠頭

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

**げろっぴ** ◆/lQMO72QVo · 04/07/01 13:56

ヽ(･∀･)ﾉｳﾝｺｰ!!

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

２なら２ちゃん閉鎖

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

●はＰＣと共通で構わないのでは？
携帯上で購入可にするのは難しいのでしょうかねやはり

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

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

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

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

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

http://qb5.2ch.net/test/read.cgi/sec2chd/1079334987/597
597 ：だいこん ★ ：04/07/01 15:36 ID:???
毎日五個くらい携帯規制リストに追加している気がする。。。
リストが大きくなると、bbs.cgi が遅くなるというか負荷が上がるというか
処理が重くなるというか、、、

**root ★** · 04/07/01 23:55

>>9
携帯用判定文字列ってどんなかんじなんでしたっけ。
DNSにうまく載せられるのかしら。

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

私はパソコンがないので携帯から２ちゃんを閲覧しています。
携帯から閲覧できる機能は、とてもありがたいのですが、
そのせいで２ちゃんねるに負担をかけたり、以前のような閉鎖危機に陥ったりするのは嫌です。
サーバーの負担になるのであれば、携帯からの閲覧機能は無くてもいいです。
悲しいけど、２ちゃんねるが無くなるのはもっと悲しい。

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

>>11
俺はPCオンリーのユーザーだが君みたいな人にはなんとかしてあげたい

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

寄付とか受け付けてみたらどうでしょ？

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

>>10
http://qb5.2ch.net/test/read.cgi/sec2chd/1079334987/ 辺りを見ると、

au　　　　¥d{14}_[a-z]{2}.ezweb.ne.jp
docomo [A-Z]{5}¥d{6}　又は　¥d{15}

のようですねー。

vodaはよく分からなかったんですが、
http://specters.net/cgipon/labo/c_env.cgi?c=j&e=HTTP_USER_AGENT とか見ると

voda　　 {A-Z]+¥d+

でいいのかな。

auの "_" 以外は大丈夫そうですねー

◆BFzK/mtqM2 · 04/07/02 10:08

規制するのは端末固有情報だから、bbs.cgi叩きにいくときしか出さないはず。

**root ★** · 04/07/02 10:33

そうだ。せっかく占有のスイッチでつながってるんだから、
datディレクトリをNFSするというのはどうだろ。

あとで、やってみよう。

**未承諾広告※** ◆TWARamEjuA · 04/07/02 11:01

use Digest::md5;
:
:

sub Get_Mobile_ID($) {
my $Mobile_ID = Digest::md5->new;
$Mobile_ID->add(shift);
return $Mobile_ID->base64digest;
}
:
:

DispError('ＥＲＲＯＲ！', '寄生虫')
　if join( '.', unpack 'C4', sprintf qq|%s.bbm.2ch.net|, Get_Mobile_ID($ENV{HTTP_USER_AGENT})) =~ /^127.0.0/ ;

UA をそのまま MD5 にして bbm（仮名）送りはちょと強引かな？(^-^;)

◆BFzK/mtqM2 · 04/07/02 12:11

確かにNFSにするのが一番簡単ですね。
それならばクラシック側は変更もいらないですね。

**root ★** · 04/07/02 12:17

>>16
datの下だけNFSにすると「キャッシュが作成できません」と言われるなぁ。
たぶん、何か呪文が必要なのかも。
これ以上は中の人に聞かないと。

**root ★** · 04/07/02 12:17

>>18
単に、datの下をNFSに(動かしながら)するんじゃだめなんでしたっけ。
何か設定が必要なんだっけか。

**root ★** · 04/07/02 12:19

うーむ、NFSじゃなければいきなりmvしてもいけるみたい。
だとすると私の設定の問題か。

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

>>21 は勘違いでした。どうもいきなりmvするんじゃだめかも。
結局 >>19 か。

◆BFzK/mtqM2 · 04/07/02 12:29

パーミッションはどうなっていますか？
777ならキャッシュ作れると思うんだけどな～

**FOX ★** · 04/07/02 12:31

出来れば「目的」を書いてから「手段」(たとえば >>21)を書いていただけると
とてもありがたいです、

なにをしたいんだろう
そしてそれは何が目的なんだろう
結果どうなったんだろう

**FOX ★** · 04/07/02 12:49

マーリンルージュ作戦の目的をおさらいしよう。

携帯からのアクセスは速度が非常に遅い等の特徴があり
２ちゃんねるのサーバ全体のお荷物となっている。

受付嬢を置く等でそれが原因となる負荷
速度が遅いのを２ちゃんねるの各サーバへ
直接影響を及ぼさないようにダム(バッファー)になって
動作する、またディレイ値を設けることで全体の負荷もさげようです。

つまり

1) ダム(バッファー)になり通信速度の遅さを吸収し、全サーバを助ける。
2) ディレイ値を設けて、全体のアクセスを減らし、全サーバを助ける。
3) フロントのマシンは DSIK IO をしないで、通信に専念
4) BlackGoat はdatのキャッシング(遅延値=可変)に専念
5) どんなにアクセスが来ても二ヶ月はリブートなしで動くように、

大黒埠頭は
BBM等の各種一元管理＋四台目以降の増設方法(テクニカル、ポリティカル、エコノミカル)です

**root ★** · 04/07/02 13:00

>>24
今回の目的は、前スレにもありますが、

・PHPによる各種処理
・datキャッシュへのディスクI/O

を、分割するためのものです。

今回のNFS化がうまく動けば、現在のクラシックメニューのプログラムを変更せずに、
ディスクI/Oだけをバックエンド(BlackGoat)に持っていけることになります。

BBM(仮称)はBBQ同様、banana238かoyster243かな。
管理する必要があるデータの大きさで決まると思います。
小さければbanana238、大きければoyster243。

**root ★** · 04/07/02 13:05

というわけで、目的 (>>25) の 3) と 4) を実現しようというのが、
今回の眼目になりますね。

5)は「重くても重いなりに動く」という、現在の路線(LA=100でも一応動きはする)
という方向で、チューニングをすることになるかと。

**FOX ★** · 04/07/02 13:08

現在行っていることは、以下の事だと思っています
right ?

1) フロント三台に携帯からのアクセスを有る程度集めた
2) c-docomo 等が重い状況になっている
3) c-docomo のディスクi/oが処理に追いついていない
4) 当初の目論見どおり BlackGoat を導入して Disk i/o は分離

現在ここ

5) c-docomo の負荷が劇的にさがる　←　期待されること(達成すべきこと)

**root ★** · 04/07/02 13:16

>>28
3)までは概ねcorrect.

現在4)の方法を模索している状態。

◆BFzK/mtqM2 · 04/07/02 13:32

いまのc-othersのdatはNFS？

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

28-29
3.1)定期的に各鯖から差分ＤＬ
3.2)書き込み後もＤＬ

と妄想してみたり・・・

ギコナビとかちゅ～しゃ両方で一部スレ取得してるからどうにかしたいこの頃
*一部スレ
ものすごい勢いで広告・宣伝を報告するスレ 7
http://qb5.2ch.net/test/read.cgi/sec2chd/1087899804/
【複数スレ】マルチポスト・コピペ報告スレッド11
http://qb5.2ch.net/test/read.cgi/sec2chd/1086698500/
【単独スレ】スクリプト・コピペ報告スレッド8【全板共通】
http://qb5.2ch.net/test/read.cgi/sec2chd/1088531654/
規制人を誘導するスレ3［報告スレではありません］
http://qb5.2ch.net/test/read.cgi/sec2chd/1080130473/
携帯及び●による荒らし報告専用スレッド２
http://qb5.2ch.net/test/read.cgi/sec2chd/1079334987/

(^_^;)

**root ★** · 04/07/02 13:59

昨夜やってみたことの簡単なまとめ:

・BlackGoatでフロントエンドと同じ構成のクラシックメニューを動かした
・三人娘ではpoundというプログラムを動かし、単純にBlackGoatにリクエストを
転送するようにした
・その結果、BlackGoatにディスクI/Oを集めることが出来たが、
同時にPHPでの処理もBlackGoatに移ったため、BlackGoatが劇重になった

その結果わかったこと

・対携帯のネットワーク処理だけを別マシンに移す方式ではだめだった

04/07/02 14:04

>>32
むむむさん、それって、失敗の巻きって事ですね。

04/07/02 14:10

うんこ

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

>>32
うん。ということで >>26 なわけだ。

**root ★** · 04/07/02 15:14

NFSでうまくいかなかったのは、statd/lockdを上げていなかったからだとわかりました。
(NFS設定するのなんて昔のSun以来だから、すっかり忘れていた)

で、正しく設定しても、どうもFreeBSDではうまく動かないみたい。
BlackGoat側のrpc.lockdがすごい勢いでCPUを食い、クライアント側(httpd)はハングアップ。

いろいろ調べてみると、どうもFreeBSDのNFS経由でのflockは、かなりいいかげんらしいと。

ということで、NFS路線はどうもやめたほうがいいみたい。
やっぱり、三人娘のクラシックをクラシック改にする必要がありそう。

◆BFzK/mtqM2 · 04/07/02 15:19

じゃあ週末にでもその辺の改造をやってみます。

**root ★** · 04/07/02 15:30

>>37
了解です。

では、blackgoatではProxyモードでApacheを上げておきます。
使い方等は別途。

◆BFzK/mtqM2 · 04/07/02 15:42

了解です。
キャッシュのdelayは黒山羊さんが握るんだよね。

**root ★** · 04/07/02 16:13

>>39
squidのdelay poolsを使えばいいかな。
Apacheのmod_proxyではできるんだっけ。

**root ★** · 04/07/02 16:18

>>40
あ、時間って指定できないかも。< squid

ありものでできるか別途調べた上で、なければ何か考えないといかんかな。

あらまほしい動作は、datが更新されていた場合でも
120秒は読み込まない、ということですよね。

◆BFzK/mtqM2 · 04/07/02 16:45

そうですね。
ちゃんとやるには差分とDelayを黒山羊さんに実装しないといけませんね。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 17:37

質問です(^_^;)
１　今回の失敗の巻は
　・BGにクラシックメニューを設置
　・受付嬢をリバースプロキシに変更
　だったのかな？

２　リバースプロキシはBGからのパケットをバッファして送出してたのかな？
　　つまり、BG側の送出をいかにすばやく完了させて、BGの処理を開放してあげるかが肝だと思うんだけど
　　そういう仕様になってたのかって話です(^_^;)

**root ★** · 04/07/02 18:12

>>43
1 Yes. (私としては正直「予想通りの失敗」です)

2 なかなかBGから携帯側に送り返すべき結果が来ない状態でした。
つまり、三人娘はすかすかで、BG側が過負荷でパンク。
ということで、BG=>三人娘の送出が詰まっていたわけではなく、
BG側の処理が詰まっている状態と。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 18:14

>44
えーっと(^_^;)どういう状態だったかってのは結果なので、それはそれでいいんですが
問題は
＞BG側の送出をいかにすばやく完了させて、BGの処理を開放してあげるかが肝だと思うんだけど
＞そういう仕様になってたのかって話です(^_^;)
これなんですよ。もし、そういう仕様になってなかったら、BGが重くなるのは当然だと思えるので(^_^;)

**root ★** · 04/07/02 18:14

クラシックメニューのPHPでの処理は、それなりにコスト高いです。
これと純粋なディスクI/O処理を分離したいというのが、今模索している方向かなと。

**root ★** · 04/07/02 18:16

>>45
リバースプロキシはpoundをとりあえずほぼデフォルトで使いました。
この場合どうなるのかな。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 18:20

>47
そこを検証しないと、結果だけ見て動いても問題は解決に近づかないと思われ(^_^;)
携帯側の低速なネットワークに対してバッファするのがフロントエンド
データをキャッシュすることで、フロントエンドのI/Oの負荷を下げ
かつ２ｃｈ側の負荷を携帯システムから分離するのがバックエンド
という役割分担をしたいわけなんだけど
もし、フロントエンドがパケット単位で受け取り＞送出（つまりストリーミングな処理）をしていたら
今までフロントエンドが単独で処理してたより、状況が悪くなりですよ。
１　フロント、バックに分けたことによるオーバーヘッド
２　フロント３台の処理を、バック１台にまとめたことによる負荷
３　ボトルネックとなったバックエンドからの低速なアクセスによる２ｃｈ全体の負荷

04/07/02 18:23

プロキシってのはそういうモンじゃないっしょ

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 18:23

少なくともフロントエンドは、携帯に送出する速度に関わらず
バックエンドから一気にデータを受け取ってしまわないと
携帯への送出速度に同期してバックエンドからデータを受け取ってしまうと
バックエンドが破綻するのはあたりまえといえばあたりまえの結果かと思います(^_^;)

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

>49
あ(^_^;)おいらの認識が間違ってるってのは普通のことです
なので「質問」なのですよ。

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

これから負荷が重くなる時間なので、バックエンドにクラシックメニューにして、
プロキシのチューニングをまずやってみるのが先決かな？

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 18:41

理想を言えば
バックエンドはデータのキャッシュ、差分取得、必要分の送出の３つだけを黙々とこなして
フロントエンドは、データ送出バッファとread.cgi（およびその付加機能）を担当できればいいんだけどね・・・・(^_^;)
バックエンドにユーザーインターフェースとかが入ってくるのは
負荷集中を生み出すだけだと思われ。

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

>>50
だあね。そのやり方だと結局今までと変わらないし。
フロント⇔バック間の処理は携帯の速度と非同期で
動かないと成功しないでしょう。

携帯　　→　　フロント　　　　　バック
　　リクエスト　　　　 (PORT閉)

携帯　　－　　フロント　　→　　バック
　　 TIME_WAIT　　　　リクエスト

携帯　　－　　フロント　　←　　バック
　　 TIME_WAIT　　　　　DAT転送

携帯　　－　　フロント　　　　　バック
　　 TIMEWAIT PHP処理　(PORT閉)

携帯　　←　　フロント　　　　　バック
　　 cHTML転送　　　　 (PORT閉)

携帯　　　　　フロント　　　　　バック
　　 (PORT閉) 　　　　 (PORT閉)

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

>>53
そうですね。というか当初からそれしかないと思われ。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 18:55

>55
ですよね(^_^;)
で、リバースプロキシはそういう動作をするものなんでしょうか？
↑実はどういうものか全然わかってなかったりする(^_^;)

**▲ 某ソレ511** · 04/07/02 18:57

リバースプロキシの検索結果のうち日本語のページ約 1,900 件中 1 - 50 件目 (0.43 秒)

http://e-words.jp/w/E383AAE38390E383BCE382B9E38397E383ADE382ADE382B7.html

**root ★** · 04/07/02 18:57

>>54
昨日やったのはこれですね。★のところが重いわけです。

ちなみに現在の各フロントエンドので発生しているディスク書き込み量は、
ピーク時のgame6の倍以上、負荷がやや高い時のlive8ぐらいあります。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/io/

携帯　　→　　フロント　　　　　バック
　　リクエスト　　　　 (PORT閉)

携帯　　－　　フロント　　→　　バック
　　 TIME_WAIT　　　　リクエスト

携帯　　－　　フロント　　←　　バック
　　 TIME_WAIT　　　　　★必要に応じdatを取得・datを保存・PHP処理・結果転送

携帯　　－　　フロント　　　　　バック
　　 TIMEWAIT そのまま転送　(PORT閉)

携帯　　←　　フロント　　　　　バック
　　 cHTML転送　　　　 (PORT閉)

携帯　　　　　フロント　　　　　バック
　　 (PORT閉) 　　　　 (PORT閉)

**FOX ★** · 04/07/02 18:58

>>57
このスレッドに記録するのが目的だったり

**root ★** · 04/07/02 19:03

>>56
そういう動作はしませんです。

今回の実験は、前スレのこれ↓を受けた試験だったということで。

960 名前： ◆BFzK/mtqM2 [sage] 投稿日：04/06/30 18:23 ID:vQ7rJwVR
クラシック本体をバックエンドに持ってきて、フロントを介して携帯とやりとりするのかな？

961 名前：root ★[sage] 投稿日：04/06/30 20:22 ID:???
>>960
はい、最初(Tigerサーバ/w SCSI stripeが入る前提だったころ)は、それも考えていました。
で、各フロントエンドは、リバースプロキシをすると。

しかし、今回入るバックエンドはbananaサーバです。
ということで、PHPをバックエンドではあんまり動かしたくないかもなぁと。

ただ、どっちの方式がいいかは、やってみないとわからないところがあります。

1)方式1

・フロントエンドはクラシック(改)
・バックエンドはApacheのプロキシ+キャッシュ

2)方式2

・フロントエンドはApacheのリバースプロキシ
・バックエンドはクラシック

962 名前： ◆BFzK/mtqM2 [sage] 投稿日：04/06/30 20:33 ID:vQ7rJwVR
まずは、負荷かかるかもしれないが、（2）を試して、
その間に（1）の準備をしましょうか。

963 名前：root ★[sage] 投稿日：04/06/30 20:47 ID:???
>>962
そうしますか。
なら、一番苦しいとこからやんないと意味ないですね。
c-auやc-othersは何とかなってるから、自動的にあれかぁ。

**▲ 某ソレ511** · 04/07/02 19:05

いやこのリンク先、単なるIT用語辞典なんだけどね、、
さすがに用語の意味くらいなら検索したほうがいいんじゃないかと思って。
IT用語辞典が消えることはインターネットがある限りないと思うし。
それをどのように適用するかなら書いても価値があると思うんですけど、、

とりあえずかいつまんで書いておくと、
　外部からネットワーク内部へのアクセスをする際に通されるもののことで、
　中継時にURLやパケットの内容を保存することでセキュリティを強化したり
　アクセス数の多いデータをキャッシュとして保存することにより高速化したりできる。（←今回はこれが目的かな）
　内部から外部へ接続するプロクシの反対なので「リバース」がつくと言われている。
こんなところかな、

**root ★** · 04/07/02 19:10

で、もしバックエンドのPHP処理やディスクI/Oがおなかいっぱいで、
かつクラシックメニューが簡単には改造できないとしたら、
以下の構成もありかなと。

フロント <=> バックエンド1(クラシック)
　　　　　<=> バックエンド2（クラシック)
　　　　　<=> バックエンド3(クラシック)

フロント<=>バック間はリバースプロキシでURLを見てロードバランスする。
(これは簡単に設定できます)

つまり、ディスクI/OやPHPをやる人の負担を単に1/3に薄めると。

**root ★** · 04/07/02 19:12

で、>>62 の構成は今の路線(今はURLを見るのではなくて、au/docomo/othersで割っている)
で、これを細かく割ると。

ただ、どうみてもこれは筋悪だし、本格的な解決になってないというのがここの判断かなと。
ということで、>>53 >>54 方式かなと。

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 19:13

>62
それだと携帯ユーザーが満足できるだけバックエンドを入れた時点で２ｃｈ側の負荷が・・・・(^_^;)
フロントいっぱい＞バックエンド少し＞２ｃｈ
という分散モデルにならないと・・・・(^_^;)

**マァヴ** ◆jxAYUMI09s **＠マァヴ ★** · 04/07/02 19:14

まー、外野であれでなと、これでないとと騒ぐのは簡単なんですけどね(^_^;)

**root ★** · 04/07/02 19:16

>>64
ということで世間的には、バックエンド1,2,3を
別途用意した同じProxyサーバにつなぐわけです。はい。

**root ★** · 04/07/02 19:18

ただ今回は、もうめざす路線は概ね合意できている気がするので、

・携帯からの受付・PHP処理・dat/subject.txtリクエスト…フロントエンド
・フロントからのリクエスト受理・dat/subject.txt取得・管理…バックエンド

その形をめざして動くことでよいのではないかと。

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

blackgoat、これからちょっとファイルシステムのチューニングをしてみます。

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

Pekoでやったようなメモリ周りのチューニングはいかがでしょ

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

blackgoat、チューニングできた。
ちょっと、c-docomoでためしてみます。

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

c-docomo => blackgoatを復活させた。
さて、どこまで上がるか。< blackgoat

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

今のところいい感じ？
ttp://mumumu.mu/mrtg/mrtg-rrd.cgi/load/c-docomoload.html

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

ccdを使って、blackgoatのディスクをストライピングにしてみた。
ちゃんとad0とad1にほぼ均等にアクセスがいくようになった模様。

ただし、ディスクは確かに楽になったけど、LAは改善されてないみたい。

ただ、今はまだ無制限に受け付けるので、
接続が目いっぱいまで使われてしまうことも、原因にあるかなと。

httpdを24, 32, 48, 64, 96, 128, 160 と変えて試してみたけど、
24の状態で既にPHP処理だけでCPUはめいっぱいみたい。
ほとんどのhttpdはRUN状態(PHP処理中)になっています。

で、マァヴさんが言っていた状態になっているかどうか(BlackGoat側の送信部分が
ふん詰まり状態になっているか)をnetstatコマンドなどで確認してみましたが、
いずれの状態もバック=>フロントへの送信そのものは速やかに終わっていました。

つまり、BlackGoat側からフロント側への送信はすばやく終わっていて、
BlackGoat側で送信そのものに詰まっている状態は、観測されていませんでした。

コストかかっているのは、やはりPHP処理とディスクI/O処理のようです。
接続数を多くするとリニアにLAが上がっていく状態。
実はへたすると、PHPの処理の方がディスクI/O処理よりもコストが高いのかも。

自宅に帰ったらフロントエンド側を調整して、接続数制限を入れてみるか。

**root ★** · 04/07/03 00:05

>>72
そっちは、ねぇ。PHP処理とディスクI/O処理をしない状態になるから、軽くなるんですよ。
こっちが、重要。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/load/blackgoatload.html

実際のDoCoMoのユーザさんのレスポンス具合はどうかなと。
たぶん、今は昨日までとあんまり変わらないはず。

**FOX ★** · 04/07/03 00:07

>コストかかっているのは、やはりPHP処理とディスクI/O処理のようです。

って、BlackGoat の話しですか?

であるならば、
まずは何よりも先に「本来の目論見である、DISK i/o だけ」にするのが先かと、

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

>>74
あんまり変わらないですね。ただもともと接続速度が遅いので
そんなに気になりませんが。
FOMAの人は気になるレベルかもしれません。

**root ★** · 04/07/03 00:14

>>75
はい、その通りですね。

今回のテストでは「PHP処理とディスク処理のどちらがより苦しいか」の
再検証と、BlackGoatをディスクI/Oに特化させるための準備
(BlackGoatへのストライピングの導入&テスト)をやっていました。

ということで、BlackGoatのディスクをストライプ構成にできました。
(FreeBSDには標準でその機能があります)

/etc/ccd.conf に以下のように書くと、ストライプ構成にできます。

# ccd ileave flags component devices
ccd0 64 none /dev/ad0s1f /dev/ad1s1d

/dev/ccd0を/homeにmountしました。
/homeに書き込むと、ad0とad1に均等にI/Oがかかることを確認しています。
(これの確認には、実際に高い負荷をかけてみることが必要なので)

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

>>73
＞実はへたすると、PHPの処理の方がディスクI/O処理よりもコストが高いのかも。
よーしこうなったらkage.cgi（仮）をＣで作っちまおう

**root ★** · 04/07/03 00:18

んで、ディスクI/Oは相当楽になりました。
ccd化はパフォーマンス向上にかなり効果ありそうです。
しばらく動かして問題なければ、機を見てフロントエンドの/homeもこの構成にしようかなと。

ここはバックアップ要らないということで、バックアップ用ディスクをつぶしました。

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

いまN900iからｱｸｾｽしています。
1ﾍﾟｰｼﾞ開くのに30秒くらいかかります。
ヤフーは5秒です。

**root ★** · 04/07/03 00:25

>>76 >>80
どうも。
>>73 >>74 でも書きましたが、今までのこの時間と概ね同じか。
LAは少し低くなりましたが、あんまり変わりませんね。
100超えていたのが80台になったぐらい(このぐらいは誤差の範疇)。

つまり、ストライピングによる I/O性能の向上では、
PHP処理の重さは埋めきれなかったと。

ということで、>>75 であることが改めて裏付けられたと。
(もしこれで軽くなっていたら、I/Oがボトルネックだったことになる)

**FOX ★** · 04/07/03 00:32

Front - BlackGoat 間の通信に何を使えば一番いいのかはわかりませんが
一つの案としては、素直に http を使うのもありだと思っています

つまり(予測ですが) Front の２ちゃんねるのサーバ群への dat 要求を
現在 http で行っている。その部分を BlackGoat に書き直す(たぶん private IPs)
だけで front 側の修正は ok なはず

んで、　BlackGoat 側でのfrontとの会話部分を新たに開発すれば
以上終わりだと思います。この辺でいろいろな方法があると思う。

**root ★** · 04/07/03 00:37

私も、概ねそう思っています(>>82 の前半部分)。
単純にシンプルな形でいいんじゃないかなと。

基本的には、120secのディレイをうまく処理できるProxyサーバみたいなものがあれば、
いいんじゃないなと思っています。

あとは、クラシックメニュー側で持ってきたdatファイルをopen()とかstat()とかしていたり、
追加書き込みをしていたりするところがあると思うので、
それへの対応が >>82 の後半部分になるのかなと。

**root ★** · 04/07/03 00:40

で、ぐちというか、ひとりごとを。

最初からTiger+ストライピングだったら、うんうんうなりながらccdとかvinumとか
調べたりしませんでした。

つまり、いわゆるただ働きモデルでストライピングは実現できたわけで。
しかし、どきどきしながらパーティションのつけかえをしたり、
リモートでccdの設定したりして、なかなかスリリングで楽しかったです(w。

ただし、カネを使ってハードウェアでやるストライピングには、もちろんかないませんが。

**FOX ★** · 04/07/03 05:39

1) 受付嬢から必要な時に必要なデータ(.dat .txt) を BlackGoat から取得する
　　この場合、受付嬢はデータを溜め込むとか何もしない
　　もしかしたらディレイ値 0sec で動かせばそうなるのかな?(中見たことないので推測)
　　ただし２ちゃんねるの各サーバから取得するのではなく
　　BlackGoat から全部取得する

2) BlackGoat は受付嬢からの要求が来たら、キャッシュしつつ
　　２ちゃんねるの各サーバから実際に持ってくる
　　　・初めてのとき or 指定された delay値を超えた場合は実際に取りにいく(差分取得)
　　　・そうでないときは自HDに溜め込んでいるデータを帰す。

3) 　この二つを達成するために受付嬢 - BlackGoat の間にはデータやり取りの
　　決め事を作らなければならない。
　　　・ http を使ってやり取りするとしたらどんな方法?
　　　・ cgi にしちゃう? (これが第一歩かも・・・)

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

２ちゃんを月１００～３００円くらいの有料コンテンツにして
鯖増強してほしい。

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

>>86
有料にしても同じ人数が集まるならいいが
確実に人が減るので今のような有益な情報が集まらなくなる。
するとさらに人が減る
2chあぼーん

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

いや半分ぐらいになった方が良いかもしれん。
あとから入ってくる人はアホみたいに居るし。

ってスレ違いだよ、頑張れオレ。

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

携帯（ﾊﾟｹﾎ）での観覧だけ有料にするとか？
ｽﾚ違い。。。

**未承諾広告※** ◆TWARamEjuA · 04/07/03 12:19

http://c-au.2ch.net/_service/20040703.txt
ちょと変です(苦笑)

**ミラー名無しさん** · 04/07/03 15:28

0000000 067 066 063 063 012 000 000 000 000 000 000 000 000 000 000 000
0000000 7 6 3 3 \n \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000010 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
0000010 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
00007d0 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 062
00007d0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 2
00007e0 060 060 064 057 060 067 057 060 063 040 060 064 072 063 060 072
00007e0 0 0 4 / 0 7 / 0 3 0 4 : 3 0 :
あ、ぬる（ry

リブート前のログは正常なんですけど、なんででしょうね。
http://www6.ocn.ne.jp/~usada/c-au/20040703.0.txt 但し2:30迄

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

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

◆EA.clAssIc · 04/07/03 18:16

いままで直接各ｻｰﾊﾞに
GET /operate/dat/1086680380.dat HTTP/1.1
でﾘｸｴｽﾄしていたものを、
BGの指定ﾎﾟｰﾄ経由(proxy)で
GET http://qb5.2ch.net/operate/dat/1086680380.dat HTTP/1.1
とﾘｸｴｽﾄするように変えてみますか?

**FOX ★** · 04/07/03 18:25

ふむふむ、で

・受付嬢は DIsk i/o しなくなる

ができるなら、それがいいです。
そして BlackGoat はそのまま各サーバから
データを持ってくる状態になっているのだろうか?
それであるならば、あとはその部分を改良すれば良いだけな気がする。

>>93 をやって何がわかりどんな期待が出来るか。。。

1) c-docomo 一台でフロントとしての実力がわかる
2) BlackGoat をどの様に改善すればよいかの情報がとれる
ただし
3) BlackGoat がフロントからの要求を全て直接各２ちゃんねるのサーバに
　　問い合わせるので、各サーバの負荷はあがる

受付嬢の要求仕様は >>93 をやる事で完成だと思う

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

>>91
ｶﾞ(ry

◆EA.clAssIc · 04/07/03 18:42

>>94 FOXさん、
では、ちょっとやってみます。

･受付嬢変更点
1) dat、subjectのﾘｸｴｽﾄ先をBGへ(PROXY経由)
2) ｷｬｯｼｭの作成を停止
3) 2)より、ﾃﾞｨﾚｲは実質的に0secへ(ﾃﾞｨﾚｲ処理はBG側に任せることになります)

BGは現段階でproxyとして動作可能なのでしょうか?
もし動作可能であるなら、接続の為のport等の情報をﾒｰﾙして下さると幸いです。　>>rootさん

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

とりあえず、キャッシュ生成しないバージョンを入れてみました。
ちょっと、バグがあるけど（＾＾；

現在、ディレイなしで直接各サーバからdatを読み込み、それを処理するようにしてみました。
PROXYはとりあえずなしです。

◆BFzK/mtqM2 · 04/07/04 02:35

2004/07/04 01:41:21 LA= 1:42AM up 22:18, 0 users, load averages: 92.06, 93.51, 93.92
2004/07/04 01:50:02 LA= 1:50AM up 22:26, 0 users, load averages: 93.77, 94.52, 94.51
2004/07/04 02:01:19 LA= 2:01AM up 22:37, 0 users, load averages: 93.92, 93.44, 93.98
2004/07/04 02:10:00 LA= 2:10AM up 22:46, 0 users, load averages: 95.25, 94.00, 93.86
2004/07/04 02:20:00 LA= 2:20AM up 22:56, 0 users, load averages: 1.91, 21.91, 53.72
2004/07/04 02:30:00 LA= 2:30AM up 23:06, 0 users, load averages: 1.39, 4.18, 27.20

LAは劇的に低くなったがレスポンスは相変わらずですね。。。。

◆BFzK/mtqM2 · 04/07/04 02:45

c-docomo
2004/07/04 02:40:00 LA= 2:40AM up 23:16, 0 users, load averages: 1.30, 2.15, 14.43

c-au
2004/07/04 02:40:00 LA= 2:40AM up 22:10, 0 users, load averages: 20.86, 23.19, 23.66

c-others
2004/07/04 02:40:00 LA= 2:40AM up 21:55, 0 users, load averages: 0.59, 0.52, 0.51

うーん、c-docomoはなんでLAがこんなに低いんだろう。。。。

◆BFzK/mtqM2 · 04/07/04 02:46

とりあえず、しばらくこれで動かそうかな。。。。。

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

>>100
よーわからんけど乙です。

◆BFzK/mtqM2 · 04/07/04 04:32

全部読み込んでいるので、レス数が大きいスレは開くのに時間かかるね。
やはり、BG側で必要な情報だけを渡すようにする必要がありますね。

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

そこは注目のところですね、

受付嬢 - BlackGoat 間の通信が十分にはやいなら
受付嬢は dat の全データを貰っても貰わなくても ok な気がします。
もしこの間の通信がおそいなら・・・　別の手を考える必要があるのかな?

まずは、毎回dat全取得という方法に固定しておきましょう。
次は BlackGoat でのキャッシングでどう変わるか。。。

1) 受付嬢の負荷はほとんど変わらないか、若干改善か?
2) ２ちゃんねるのサーバたちの負荷は大幅に改善される。
3) BlackGoat が受付嬢三人娘はかるがるとこなし、
　　10人までだったら相手にできるかも? の感触をつかむ。

◆BFzK/mtqM2 · 04/07/04 04:51

そうですね。
受け付け嬢へのデータ加工機能をBGに入れるとすればそれなりの負荷が発生しますよね。
単なるプロキシならほとんど負荷はかからないんじゃないかな？

◆EA.clAssIc · 04/07/04 10:26

>>◆BFzK/mtqM2さん、
ちょと改造されたところを拝見したのですが、
getres の 86 と 99 行目で2回にわたって dat ﾘｸｴｽﾄしているようです。
どうしましょう、私が改造しても良いのかな?
もし複数人で改造を行うなら、日時と変更箇所を簡単にｺﾒﾝﾄした方が良いですね…

◆BFzK/mtqM2 · 04/07/04 13:03

直しちゃってくださーい。
rewindがうまく行かなかったんで(^^;

そうですね。これからは変更したらコメント入れましょう。

◆BFzK/mtqM2 · 04/07/04 13:36

うーん、docomoはずーっと、アクセス数が一定なんだけど、、、
なんかしちゃったかな？
http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/c-docomoaccess.html
その割にLAはずーっと一桁
http://mumumu.mu/mrtg/mrtg-rrd.cgi/load/c-docomoload.html

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

>>107
DoCoMoはbananaの10Mbps制限に引っかかってるみたいだけど、
auは帯域制限が効いて無くて、20Mbps程度でてるみたい
　＞フロント←→2ch鯖間通信

その辺の関係で、DoCoMoは窓口数と処理が掃ける速度により
事実上アクセス上限に当たってる状況なのではないかと推測したり。

**FOX ★** · 04/07/04 14:13

使用帯域は、どっちも 1Mbps 以下かそれくらいのような、

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

>>109
どもー。
1Mbps以下ってのはPIE-外部の帯域じゃないですか？

>>108で書いたのは
http://server.maido3.com/pie/graph/c-do.gif
http://server.maido3.com/pie/graph/c-au.gif
このグラフで言うところの青線の方です。

ここの傾向がauとDoCoMoで明らかに違うので何らかの
影響があるのではないかと思うのですが。
# いちおうリンク http://server.maido3.com/pie/

**FOX ★** · 04/07/04 14:42

おぅおぅ

たしかに。。。

これが BlckGoat を通すことによってなくなるはず
というのが検証できますね。

BlackGoat - ２ちゃんねる　の間はキャッシングすることによって
いろいろと、、、

**FOX ★** · 04/07/04 14:49

>PIE-外部の帯域

の表現はちと違うかな?

http://server.maido3.com/pie/
のサーバのグラフは
青 Switch -> Server の使用帯域
緑 Server -> Switch の使用帯域です

また Switch 以降はルータまでとルータから外部は十分に太いので

青外 -> Server の使用帯域
緑 Server -> 外の使用帯域と言いかえられます。

これからの作業として　「受付嬢 - BlackGoat 間を
インターネット(GrovalなIP,ネット)を使ってをやっているのを
内部LANを使ってやる」となっています。

もし　10M の制限がなかったら
(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ　もんでしたなぁ

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

>>112
>PIE-外部の帯域
という表現が乱暴だった事は承知しておりますm(__)m

今回の作戦の成果(キャッシュ効率)を示す指標の一つはBlackGoatの
「Local(受付嬢)帯域 / Global(2ch)帯域」比をどれだけ大きくできるか、
ですね。

これからの流れとしては
(1) BGのキャッシュシステムを構築→キャッシュ効率・負荷の評価
(2) 受付嬢のチューニング→負荷、処理能力の評価
(3) 受付嬢-BG間のdat取得方法の見直し (BGのLAN側100Mbpsが飽和)
(4) 大黒埠頭時代を見据え、BGの性能評価。増強が必要ならスペック検討。
といった辺りでしょうか。
(3),(4)まで進んで嬉しい悲鳴をあげる事が出来ますように…(-人-)

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

現時点の受付嬢の仕様

（１）キャッシュなし
（２）その都度、２ｃｈの各サーバからdat全取得（過去ログ等はキャッシュしている）
（３）Delayなし
（４）docomoは10Mbps帯域制限中、auは10Mbps帯域制限かかっていない、othersは不明

各受付嬢の現状

docomo　LAは低いが、帯域制限されてレスポンス遅い
au 帯域制限されていないので、比較的レスポンスはよい。ただしLAは高め
others　いつも通り余裕

**root ★** · 04/07/04 21:50

昨日・本日とおやすみしておりました。

というわけで、まずは>>93-94 >>96に対応します。

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

>>96
とりあえず設定しました。(Apacheのmod_proxy+mod_disk_cache)

c-au, c-docomo, c-othersから、192.168.0.1:80をProxyにしてみてください。

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

お、ちょっとまってください。
キャッシュ関連を調整します。>>116

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

携帯用と高機能版があるけど携帯用を選択したら見違えるくらい軽くなった。
高機能版はﾚｽﾎﾟﾝｽに30秒以上かかっていたのに5秒くらいになった。

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

Bad Requestがでるな。。。
まだ設定終わっていないのか、送り方間違っているのかな。。。。

**root ★** · 04/07/05 00:44

キャッシュの調整、おわりました。
ということで >>116 でおながいします。

**root ★** · 04/07/05 00:45

>>119
送り方ですが、>>93 の

GET http://qb5.2ch.net/operate/dat/1086680380.dat HTTP/1.1

は、

GET http://qb5.2ch.net/operate/dat/1086680380.dat

で、いいはず。

◆BFzK/mtqM2 · 04/07/05 00:46

>>120
Proxy経由で接続も確認できました。
これから三人娘に導入します。

**root ★** · 04/07/05 00:46

HTTP/1.1 をつけてもいいのかな。
ちと、ためしてみるです。

**root ★** · 04/07/05 00:46

>>122
ほい、ではよろしくです。

**FOX ★** · 04/07/05 00:48

わくわく

◆BFzK/mtqM2 · 04/07/05 00:52

？？
http1.1はとった方がいいのかな？

**root ★** · 04/07/05 00:55

c-othersからきはじめたかな。

>>126
どうもとらないとだめみたいですね。
設定をへまっているのかしら。(とりあえずApacheのmod_proxyを使用)

**root ★** · 04/07/05 00:57

私のプロキシ側の設定がいまいちな予感。
ちと、とめてくださいです。

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

現在、c-othersで実験中
私のPCからのみPROXY接続で、それ以外は直接接続です。

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

Apacheのmod_disk_cacheにはバグがいるみたい。

.htmlな拡張子だとちゃんと動くけど、.datという拡張子だと
キャッシュにデータが入っている時に再度同じものをとろうとすると、
httpdがsignal 11で死んでしまう。

キャッシュしないモードではちゃんと動きますが、それじゃ意味ないし。
ということで、squidに切り替えます。

◆BFzK/mtqM2 · 04/07/05 01:31

ﾏﾀｰﾘ待っています

**FOX ★** · 04/07/05 01:39

　　　　　　　　　　　　　　　　　　落着いて待ってます…

　　　　　　　　　＝≡＝　∧＿∧
　　　　　　　　　／　　　（・∀・　）
　　　　　　　　〆　 ┌　 |　　　　| .∈≡∋
　　　　　　　　　|| 　γ ⌒ヽヽコノ　　 ||
　　　　　　　　　||　.｜　　　|:::|∪〓　 ||
　　　　　　　 .／|＼人＿.ノノ _||_.　／|＼

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

―――――――――――――‐┬┘　　　　　　　　　　　　　　＝≡＝
　　　　　　　　　　　　　　　　　 |　　　　　　　　　　　　＿＿　〆
　　　　＿＿＿＿.＿＿＿＿　　 | 　　　　　　　　　　　 ───　　＼
　　　　　|　　　　 |　∧＿∧ |　　 | がっ！　　　　　　　　　　　　　　　＼＿＝二 ∧＿∧
　　　　　|　　　　 |. （#´Д｀）| 　　|　　　　　　　　　　　　　　　　　＿　　|ヽ　　＼（；･∀･）／
　　　　　|　　　　 |⌒ 　　て)　　人　　　　　　　　＿　　―――‐　γ ⌒ヽヽ　⊂　　　つ　 ∈≡∋
　　　　　|　　　　 |（　　___三ﾜ＜　＞　　―――　　 ―― ―二　 |　　　|:::| 三ﾉ　ﾉ　ﾉ　 ≡ //
　　　　　|　　　　 |　)　　）　 | 　　∨ 　　　￣￣￣　―――‐　　人＿ノノ　（_ノ､_ノ　　＿//
　　　　￣￣￣￣'￣￣￣￣　　 |

**root ★** · 04/07/05 02:41

おそくなりました。

192.168.0.1:8080

でやってみてください。HTTP/1.1 形式が必須のようです。

◆BFzK/mtqM2 · 04/07/05 02:49

アクセスできました。

statusが返ってこないのがちょっと気になるが。。。。。

これでいってみますか。

**root ★** · 04/07/05 02:50

>>135
アクセス確認しました。
statusは、、、設定しないとだめなのかな。

# なにぶん数年ぶりで設定するので。< squid

**root ★** · 04/07/05 02:51

たくさんきはじめました。

◆BFzK/mtqM2 · 04/07/05 02:52

othersを切り替えました。

statusは出来れば設定してほしいですね。
何か問題あるかもしれないけど、他も切り替えてみます

**FOX ★** · 04/07/05 02:53

今　others だけですか?

◆BFzK/mtqM2 · 04/07/05 02:53

auも今切り替えました。

◆BFzK/mtqM2 · 04/07/05 02:55

あら、スレありませんがでた。

**root ★** · 04/07/05 02:55

diskdだとsquidが死ぬみたいなので、aufsに変更してみた。

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

>>142 の影響だとおもう。今はどうですかね。>>141

**FOX ★** · 04/07/05 02:56

ということは
others au docomo の転送量が裏の経路に回るので
帯域問題は解決するかも? ということですね、
帯域問題が次に発生するとしたら BlackGoat - 各サーバの部分と、

期待したいのは「受付嬢は何も問題なく動きはじめる」といことだー。

**root ★** · 04/07/05 02:58

aufsにした後は死ななくなったみたい。
status設定をちょっと調べてみます。

◆BFzK/mtqM2 · 04/07/05 02:58

>>142
大丈夫になりました。

んじゃ、最後にdocomoも切り替えます。

◆BFzK/mtqM2 · 04/07/05 03:00

現在、３人娘はすべてPROXY経由になりました。

**FOX ★** · 04/07/05 03:01

おおっ　素晴らしい。。。

んで　BlackGoat さんはdat,txtをキャッシュするですか?

**root ★** · 04/07/05 03:02

時間帯があれなのでなんともいえませんが、いまのところゆとりあります。< blackgoat

>>144
そのように期待しています。

**root ★** · 04/07/05 03:02

>>148
今のところなんでものはず。htmlでもgifでも。
Pragma: no-cacheとか命令されない限り。

**root ★** · 04/07/05 03:04

ストライピングの効果がうまく出ているようです。
ディスクI/Oが2本のディスクに分散されて、いいかんじ。

◆BFzK/mtqM2 · 04/07/05 03:04

いまのところ、datのみをリクエストしています。
あとで、subject.txtもPROXY経由で取得するように変更します。

**FOX ★** · 04/07/05 03:04

>>149-150
りょうかいでーす

うまく動いているようなどっかで固定して
48h 間くらいいろいろデータ見てみたいでーす

**root ★** · 04/07/05 03:08

ごめん。今、1分ぐらいsquidとめました。

今日一時的に止める時は、ここに書きます。

**root ★** · 04/07/05 03:09

>>153
そうですね。了解。

◆BFzK/mtqM2 · 04/07/05 03:12

いい感じですね。
http://server.maido3.com/pie/graph/blackgoat.gif

**FOX ★** · 04/07/05 03:14

お忙しい所すみませんガ

BlackGoat のキャッシュする機能としては
どかん設定なのでしょうか?
1) 何秒のディレイと考えればいいのか
2) BlackGoat - ２ちゃんねるのサーバ間の通信での差分読み込みの有無
3) BlackGoat に性能の限界が来るとすれば、どの部分と予想されるか、

この辺を記録として残したい気分です、

**root ★** · 04/07/05 03:14

ログを見る限り、結構キャッシュはヒットしている予感。

**FOX ★** · 04/07/05 03:34

とっても良さげなんだけど。。。

http://ch2.ath.cx/load/c-docomo.html
docomo だけ負荷が高いのはなぜなんだろう。
DISK i/o が無くなり、帯域の制限もなくなり・・・
何がネック?

**root ★** · 04/07/05 03:36

>>159
みてきます。

**root ★** · 04/07/05 03:40

ディスクI/Oがなくなったので、
httpdでかけていた接続制限(128個まで)を大きくしてみることにした。< c-docomo

とりあえず128 => 192に変更。

◆BFzK/mtqM2 · 04/07/05 03:45

うーん、体感的に c-docomo 早くなった希ガスる

**root ★** · 04/07/05 03:45

Apache statusで見る限り、さっきよりは健康になった予感(単に時間が遅くなったからかも)
既に現時点でF/Eのc-docomoは2台必要なのかも。

**FOX ★** · 04/07/05 03:47

ちなみに三台とも同じ設定ですか?
違う場合は同じ設定にしていただけるとありがたいです
条件一定にしないと比較できないからでーす

◆BFzK/mtqM2 · 04/07/05 03:47

いずれにしても、今日一日様子見てみないとなんともいえませんね。

**root ★** · 04/07/05 03:48

>>164
了解です。
これから3人娘の設定を>>161に変えます。

◆BFzK/mtqM2 · 04/07/05 03:54

>>163
c-others がスカスカなのがもったいないよね。

必要なデータが取れた時点で、
banana405 上に c-docomo2 を作って、ラウンドプロキシで負荷分散ってのは？

**root ★** · 04/07/05 03:55

>>166 done.

今の3人娘のhttpd.confの該当箇所:

<IfModule prefork.c>
StartServers 64
MinSpareServers 5
MaxSpareServers 32
ServerLimit 192
MaxClients 192
MaxRequestsPerChild 1000
MaxMemFree 2048
</IfModule>

php.iniでPHP accesralatorを導入。

zend_extension=/usr/local/lib/php/php_accelerator_1.3.3r2.so

**root ★** · 04/07/05 03:58

で、>>157 ですが、

1)F/E側の設定によります。
もしF/E側でディレイなしなら、ディレイなしです。

2)これもF/E側で制御できるのかな。
HTTP/1.1で制御すれば、それでいいはずなので。

3)しばらく見てみないとわからないですが、
ディスクI/Oかなとは思っていたり。

**FOX ★** · 04/07/05 04:01

>>167
いやー　まだまだ
r.i p.i とまってるのまだ 1/3 位だと思う(台数で)
今やりたい事は、「手法」の考案で劇的な変化を求めたいのだ
小手先の節約は劇的にはならないから

知恵をフル動因かと、

たぶん docomo の中の人とか au の中の人が通った道のりと思われるので
そこに少しでも近づければ、、、
きっと　ﾆﾔﾆﾔされていると思われ、

**FOX ★** · 04/07/05 04:07

>>169

なるほど、

で、F/E側の設定値はいかほどなんでしょうか?

◆BFzK/mtqM2 · 04/07/05 04:16

３人娘の仕様は>>114です。
データを毎回読みにいくので必然的にディレイはありません。
また差分も内部にキャッシュ持たないため難しいでしょうね。

**root ★** · 04/07/05 04:18

>>172
つまり、バックエンド側でディレイや差分を実装する(or しているソフトを入れる)
必要があるということですね。

**FOX ★** · 04/07/05 04:21

うーん
ヒンフューズドというかコンプリケイティドというか
I am stupid 状態ですが

BlackGoat 側ではキャッシュの設定は受付嬢側に委ねられている設定で
受付嬢はキャッシュはしない設定であると。。。

ということは、どういうことなんでしょうか?

現在 BlackGoat はキャッシングしてない?

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

バックエンドは、datが更新されれば内部キャッシュを更新しているんじゃないかな？
だからスレの速度がゆっくりしたデータは今以上にディレイ付くが、スレの速度が速い奴は頻繁に更新されるんじゃないかな？

**root ★** · 04/07/05 04:42

>>174
BlackGoatは現在、単純なProxyサーバとして動いています。

1)c-xxx →datのリクエスト→ blackgoat

2)blackgoatでdatの準備、こんなかんじ

　if (blackgoatがそのdatを持っている) {
　　　　blackgoat →datの更新チェック→ 各サーバ
　　　　if (datが更新されている) {
　　　　　　　　// ここでsquidが増分取得をしているかは未確認
　　　　　　　　blackgoat →datのリクエスト→ 各サーバ
　　　　　　　　blackgoatはdatをキャッシュに格納
　　　　} else {
　　　　　　　　// キャッシュヒットにつきdatの取得はしない
　} else {
　　　　// 持っていないのでdatを取得
　　　　blackgoat →datのリクエスト→ 各サーバ
　　　　blackgoatはdatをキャッシュに格納
　}

3)blackgoat →datの送信→ c-xxx

**FOX ★** · 04/07/05 05:01

なるほど、なるほど

48h ほど観察して、次の話題は
1) BlackGoat にディレイ機能を入れたらどうなるか
　→　転送量(２ちゃんねる各サーバの負荷)
2) 差分読み込みまでする必要があるかどうかの検討
------------------------------------------
3) 受付嬢(とくに docomo) の負荷が高いのは
　　単純にアクセス数が多いからなのかどうか

あたりですかねぇ

**root ★** · 04/07/05 05:51

そうですね。そんなところかと。>>177

で、思いついたことを。
三人娘側でディレイを実現するのは、
どの板のどのdatをいつ最終取得したかをチェックできればいいわけです。

つまり、今までdat本体をストアしていたところに
大きさ0のxxxxxxxxxx.datファイルを作ることにして、
取得の際にそのファイルのmtimeを更新するようにするようにしておいて、
その時刻が現在時刻よりも120秒以上経過していなかったら、
blackgoat側にリクエストをそもそも発行しないようにする、というのはどうかなと。

**root ★** · 04/07/05 05:56

>>178
これやると、ちょっぴりですが三人娘側でI/Oが発生しますね。

一番いいのは、blackgoat側で今もっているデータよりも120秒以上未来になってなかったら、
更新されていないとみなすようにすることか。

これってsquidの設定でできるのかしら。

**FOX ★** · 04/07/05 06:02

>>178-179
これまでの雰囲気からは、 >>179 が本線だと思いますー

**FOX ★** · 04/07/05 06:10

つまり
現在の目標は、
1) 受付嬢の負荷を極力避けて、より多くのアクセスをこなせる様にする。

越えられない壁

2)　転送量等の話し、

ですから

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

>>179
よくわからないけど、refresh_patternかな。

**root ★** · 04/07/05 06:29

寝る前にごそごそ調べたら、squidはそもそもこの機能を持っているかも。

ということで、squid.confの設定を変えてみた。
なんとなくうまく動いているような予感。

# changed, 2 minutes delay
#refresh_pattern . 0 20% 4320
refresh_pattern . 2 20% 4320

それでは、おやすみなさい。

**root ★** · 04/07/05 06:30

>>182
お、かぶりましたね。どうもそうみたい。

**root ★** · 04/07/05 06:32

ログ的に TCP_HIT がぐんと増えたから、うまくいっているのかな。

参考:
http://www.unix-power.jp/linux/redhat/squid1.html

◆BFzK/mtqM2 · 04/07/05 09:39

＞root★さん　FOX★さん
お疲れ様です。
昼時がどれくらいになるか楽しみですね。

◆BFzK/mtqM2 · 04/07/05 10:07

なかなか更新されませんね。

**root ★** · 04/07/05 12:26

ひるどき。-docomo, c-auとも劇重。
vmstat 1 で runnable process が150とか出るし。

PHPってこれ以上高速化できないのかしら。

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

c-others、blackgoatはまだ相当ゆとりありの模様。
あと念のため、裏側のネットワークの使われ具合をチェックしてみる必要があるかな。

◆BFzK/mtqM2 · 04/07/05 12:35

受付嬢の前にもプロキシを置くと緩和されないかな？

**root ★** · 04/07/05 12:56

どうだろう。PHPで毎回ページ作っている(= キャッシュされない)んじゃなかったっけ。>>190

で、産児制限するとそれなりにつながるようになるので、
接続要求を同時に受け付けすぎの予感も。< c-docomo

**root ★** · 04/07/05 13:11

ということで、観察を継続するために元の設定に戻しました。
重くても、明日夜まではこのままいきます。> c-{au,docomo,others}

◆EA.clAssIc · 04/07/05 13:34

今c-xxでは、ﾘｸｴｽﾄした全てのdatが、まるまる配列に格納されています。
ﾒﾓﾘに乗り切れてないってことはありますか?

**root ★** · 04/07/05 13:59

>>193
Perlでいう「連想配列がばちょ」ですね。
重そうな処理だなぁ。

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

c-docomo の負荷がなぜ高いかの推測大会ですね、

04/07/05 15:21

よーしじゃんじゃん妄想するぞー

**root ★** · 04/07/05 15:22

>>195
ちなみに昼休みはc-auも高負荷だったので、
アクセス数が多いことは当然原因の一つではあるかなと。

わたし的には「単純に数が多くてもうむりぽ」なのか、まだ改善の余地はあるのか、
が問題で。

vmstatでみると、httpdがRUNになっている状態のものが圧倒的に多いですね。
つまり、処理がおいついていないように見える。

blackgoatは今のところ余裕があるので、横並びでc-docomoをもうひとつ増やしてみる
というのは、可能ではあるのかも。

**FOX ★** · 04/07/05 15:27

資料

転送量(使用帯域　対インターネット)
http://server.maido3.com/pie/

http://server.maido3.com/pie/graph/c-au.gif
http://server.maido3.com/pie/graph/c-do.gif
http://server.maido3.com/pie/graph/c-ot.gif
http://server.maido3.com/pie/graph/blackgoat.gif

アクセス数
http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/

http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/c-auaccess.html
http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/c-docomoaccess.html
http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/c-othersaccess.html
http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/blackgoataccess.html

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

公衆便所の壁になに書いてもおんなじやで、ハヨみんな死ねよ、ちんぽおめこ、くさー

**FOX ★** · 04/07/05 15:33

>>197
そういう事じゃなく

今まで
1) DISK i/o が問題と推測　→　DISK i/o をなくした
2) 帯域が問題と推測　→　帯域制限にかからないように方式変更
3) 今度は何?

前提としては「需要 > 供給」は当たり前なわけで、