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

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

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

Love Affair 作戦。
Part2 大黒埠頭

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

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

２なら２ちゃん閉鎖

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

5

6

7

8

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

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

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

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

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

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

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

あとで、やってみよう。

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（仮名） 送りはちょと強引かな？(^-^;)

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

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

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

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

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

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

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

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

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

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

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

つまり

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

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

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

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

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

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

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

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

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

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

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

現在ここ

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

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

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

いまのc-othersのdatはNFS？

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/

(^_^;)

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

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

その結果わかったこと

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

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

うんこ

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

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

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

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

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

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

>>37
了解です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>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は何とかなってるから、自動的にあれかぁ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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処理よりもコストが高いのかも。

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

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

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

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

って、BlackGoat の話しですか?

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

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

>>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がかかることを確認しています。
(これの確認には、実際に高い負荷をかけてみることが必要なので)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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迄

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

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

>>91
ｶﾞ(ry

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

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

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

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

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

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は劇的に低くなったがレスポンスは相変わらずですね。。。。

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がこんなに低いんだろう。。。。

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

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

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

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

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

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

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

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

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

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

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

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

>>108で書いたのは


このグラフで言うところの青線の方です。

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

おぅおぅ

たしかに。。。

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

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

>PIE-外部の帯域

の表現はちと違うかな?

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

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

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

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

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

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

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

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

現時点の受付嬢の仕様

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

各受付嬢の現状

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

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

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

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

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

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

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

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

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

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

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

は、

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

で、いいはず。

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

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

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

わくわく

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

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

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

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

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

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

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

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

ﾏﾀｰﾘ待っています

おそくなりました。

192.168.0.1:8080

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

アクセスできました。

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

これでいってみますか。

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

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

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

othersを切り替えました。

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

今　others だけですか?

auも今切り替えました。

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

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

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

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

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

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

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

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

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

おおっ　素晴らしい。。。

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

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

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

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

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

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

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

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

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

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

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

いい感じですね。

お忙しい所すみませんガ

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

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

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

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


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

>>159
みてきます。

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

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

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

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

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

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

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

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

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

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

で、>>157 ですが、

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

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

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

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

知恵をフル動因かと、

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

>>169

なるほど、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

越えられない壁

2)　転送量等の話し、

ですから

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

資料

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






アクセス数
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

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

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

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

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

>>200
なるほど。現有戦力で次にとれる手法は何で、そのための戦略は何？
ってことですか。

ちなみに、下記は済みのもの。

0) PHPの処理に時間がかかる → PHP acceralator導入(倍ぐらいのパフォーマンスに)

>>201
そです　そです。
そして突然「素晴らしい発想」が生まれ、「劇的な改善」が見込まれると、
1000% 効率アップとか、
それが出来るのは「若い柔軟な脳」だけかと、

・ 3 人娘を単なるクローンにする。
・ c.2ch.net はシリアル番号（機種固有番号）からランダムにいずれかの 3 人娘を呼び出す。
→ランダムなので純粋に負荷が 3 等分されるのではないか？＠帯域、負荷

○ 現状 3 人娘はそれぞれ違う処理を行っている？
→ HTML, HDML, MML, XML と違う出力にしているならば、
　その部分を切り離して UA でそれぞれ振分けてパイプ処理で変換させるとか？（nkf みたいな pod2html みたいな）

>>203
単に負荷を3等分する、というのは前にも少し考えました。
今でもpoundで簡単にできるけど。やってみますか？

後者は、中身の重そうな処理がどこかを調べることになるのかな。

c-docomo の挙動


これが c-docomo に襲い掛かっているアクセスである。
48hの推移を見ると三つの部分に分かれている
1) 最初の3kくらいのところ　→　DISK i/o が率速だった
2) 5k 位の平坦部　→　10Mbps の帯域制限が率速だった
3) 10k - 25k を乱高下　→　純粋に襲い掛かっているアクセス?

と考えていいんだろうか、実はどこかに別の秘密が隠されているのだろうか、
解せないのは、　3) が本来のアクセスならばなぜ 1) 2) が平坦になり乱高下が
観測されないんだろう。


>>204
だめだめ、ここからもしかしたら確信なのかも知れないから
台数増やすのはいつでも簡単に出来る一番安易な方法です
また、今の目標はそこにはないです。

>>204
c-docomo を軽くしようというのは目標ですが
絶対に他のキャリアとまぜないでください
勿論、au もですけど、

せっかく分けて、分析しているのですから、

簡単に言えば

「台数増やす　→　軽くなる」は既に解っている解決策ですから
実験する必要は全くないと思います。
平均化も台数増やすと同じことです。

>>205
> 3) 10k - 25k を乱高下　→　純粋に襲い掛かっているアクセス?
転送速度も絡んでいるのかもですね。
c-docomo 内部では処理が終わっているのに、なかなか全部受取ってくれていないとか。＠mova類

あと気になるのが鯖名。4xx 台ってば httpd のエラーコードなんですよねぇ(^-^)

>>205-207
了解です。物量以外の知恵で。

ccdによるストライピングにしてもそういうことでひねり出したわけで、
(これでディスクI/Oのキャパが2倍近くになった)。

で、乱高下は「その時の限界ぎりぎりまで資源が使われた場合」にこうなるようです。

でも、限界だと思っていたのが実は限界ではなかった、ってのを
既に何度も経験しています。

というか、弱いマシンでやらないと、弱点も見えてこないものです。
強いマシンだと詰めが甘くても、動いてしまうし。

このへんの「苦しいマシン環境での力のしぼり出し」は本業的に昔取った杵柄なので、
(もう何年もやってないけど)もう少しがんがってみようかなと。

ロードアベレージで負荷を見ているわけですが、

LA 高の原因は単純に言って
入ってくる量 > 完了する量　なわけです。
つまり処理が完了する量に注目すれば(動かすことの出来る項だと仮定すると)
どんどん完了すればいいわけです。

なぜ完了しないのか?
c-docomo が完了できないのか
呼び出し側が完了してくれないのか。。。

>>210
見ている限りでは、c-docomoが完了できないように見えますね。
常にhttpdがCPUを食っていて、とても多忙に見えます。

一つの呼び出しを処理するのにかかる平均時間というのは計測できるんですかねぇ
docomo の場合
au の場合
その他の場合

で知ることが出来たら、何か出てくるかも、

>>211

>c-docomoが完了できない

と原因を仮定すれば、どこが問題ななんだろうか?

1) CPU 性能?
2) RAM 不足?
3) network ? or その他?

何を見たらそう断定できる?
また解決すればどれくらいの効果が見込める?

逆に、ハードは変更しないとしたらどんな解決方法があるか?

>214
非定額の場合でも大きな違いがありますよ(^_^;)
Docomoの主力の5xx&2xxシリーズは9600bpsだったはず。
auの主力の1xは144kbpsだったかな？
詳しい人フォローよろしく。

ちょっと疑問というか不思議なのは
当初、au : docomo : others = 4:5:1.5 という計測結果があって、
その上でいろいろ進めてきたわけですが、

http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/

を見ると　4:10:1.5 に見えます。
どしてこんなに docomo の比率増えたのだろぅ

うーむ疑問だらけじゃ

>>214
いくら携帯2chユーザのWIN率が高いって言ってもWINを基準にはできんじゃろう
FOMAも同じく
mova 最大 28.8kbps (505i以降)
au 最大 144kbps

ってマァヴの親父とかぶったよ

でも、よーわからんのだけど、ネットワーク速度がボトルネックなってる場合
１　コネクションが足りなくなって、エラーを返す
２　コネクションを開放できなくてメモリが不足してスワップが起こってLAが上がる
のどっちかになるんでないのかな？(^_^;)
現状、LAが高いんだから１ではないわけで・・・・

>217
あ、28800bpsまで上がってるのか(^_^;)＞5xx,2xx

>>216
i => cの誘導を開始してから、DoCoMoの比率がかなりの勢いで上がった気がします。
あと、深夜はドコモの比率が高いような。他が少なくなるだけなのかもしれませんが。

>215,217
非定額でも転送速度の差が結構ありますねぇ
転送量が少なくてもユーザーが一杯いれば僅かな差も塵も積もれば何と
やら状態って事ですかねぇ

http://itpress.air-nifty.com/itpress/2004/06/post_1.html
この辺の関係で解約が出てるのかしら＞ボーダフォン「10の約束」反故に
そしてDoCoMoへ、なんて。

iMona破綻でドコモユーザが流れてきた？

>>213
いまのところ、1)に見えますね。
メモリ不足には見えないです。

ただ、プログラムの「つくり」とか、システム(カーネル)のチューニングで
相当改善できるような気がしていたり。

で、クラシックメニューの場合画像とかはないので、携帯相手でも
転送そのものはそれなりになんとかなっているようです。

netstat -mで見ると、Send queueにデータがたまっている
(送っているが携帯が受け取ってくれない)ものはほとんどなく、
TIME_WAIT(携帯側が待っている)ものがどっさりある状態。

c-othersの今日17時ごろへこみは、私がちょっとごそごそしたせいです。
あらかじめ。

一回本当の各キャリアのアクセス数を取りたいですね。

>>255
ほほぅ　なるほどです、

ちと　考え中。。。


ちなみに、docomo を二つに分けるとしてどんな分け方あるですか?
今までと同様 IP で振り分けたいのですが、

>>255
GJ！

>>228
今振り分けはIPじゃなくて、携帯が名乗ってくるUAでやっています。
もちろんIPでもできるけど、今はまだやってないです。

もう1台投入した場合、二つやり方があります。

DNSで自然にラウンドロビンさせるやり方と、poundを使ってロードバランシングするやり方。
DNSで自然にやるのは、同じ性能のマシンがいっぱい来るときはシンプルでいいです。
poundだと、こっちに1/4、向こうに3/4とかいう決め細やかな制御ができます。

おのおののphpスクリプトから、その鯖のキャリアと関係ないキャリアに
対応したスクリプトをばっさり削除するってのは？
docomo専用クラシック、au専用クラシック、とか

>>230 続き

DNSの場合: c-docomo.2ch.netという名前に複数のIPアドレスをつける

poundの場合: 設定で振り先のマシンを変える

いずれも、ユーザ側には同じURIをみせることができます。

>>230
平均化とか、それを目的にやるのじゃなく
折角のチャンスだからいろいろデータを取って
あれこれ研究するのが目的ですー

つまり　分け方の一例としては
1) 回線速度　a 低速 b 高速
等でわけたいのです。

何か他に分ける方法というか物差しありますかねぇ?

>>233
例えばFOMAはこっちでPDCはこっちってかんじですね。
それなら、UAで見ればいけるかなと。

あとはなんだろう。< 分け方

http://www.nttdocomo.co.jp/mc-user/i/spec/useragent.html

DoCoMo/1.0 → mova
DoCoMo/2.0 → FOMA

これは個人的におもしろそうなんで統計とってほし

次の一手は・・・

1) peko 機を移動してこのLANに接続
2) c-docomo を peko 機でそのまま運用(まだ分割しない)
3) これで CPU がへたれかどうかが検証できるはず !?

懸念されることは c の機能がそっくりそのまま改造することなく peko で動くか
かな?

>>236
こないだまでcomic4(cobra2246)で動いてました。< cの機能

あのときはLA=50ぐらいで、全部のキャリアを受けてたかな。

DOCOMO/AU/otherの振り分けは間違いなくできてるという前提で
LAでなく接続端末数はどうなっているのだろう

待ちプロセス多数でメモリが足りないなら接続受付数の調整で変化出てるとは思いますが

>>237
あっ　そうだった、、

この間のcobraでは送出待ち多数な状況でしたねえ(接続数とか処理周りに違いはあるけども)。
docomoとauはcobraが必要なんすかねぇ…

まだ出ていないようなので、浅知恵で意見致します。

DoCoMoとauの大きな違いは、
端末でキャッシュするかしないかだと思いました。

それから、端末って、ちゃんと「処理完了」のお返事してるのでしょうか？
その辺は解決済みですか？

httpd -F on tcpserver という手も残されているのかな？
実験してみたところ、無駄に風呂敷（メモリ）を広げずに動いているみたいです。StartServer も無視。
接続数なども tcpserver 側で制限できるので(-c)、その分 httpd のお仕事も減らないかなぁと。

>>241
TCP レベルのお話かな？＠処理完了のお返事

続けて失礼します。

キャッシュがあると、
1.リクエストの間隔が長くなる、
2.一度のデータが大きくなる、
と思います。

誤差程度かもしれませんが、一応書いておきます。

>>243
？どこからどこまでのキャッシュの話？

>>242
どの階層かは思い付きませんが、その辺です。＜TCP

>>244
携帯端末内のキャッシュです。

>>220 docomo2xx、5xxは下り28.8、上り9.6じゃなかたっけ。
http://k-tai.impress.co.jp/cda/article/showcase_top/16825.html

そーすっと。ここらへんも関係あるかも。

>>247
5xx全てが28.8Kでは無い。
504以降から28.8Kだったっけ
詳しくは知らん。

鯖負荷を見ていたら、c-docomoとc-auがパンク状態でc-othersがガラガラ
一応、c.2chの機種別総合アクセス統計が必要かも…。
・D（FOMA/mova）
・au（cdmaOne＆CDMA2000/WIN/TU-KA
・v（V6＆J5/V8）
・PHS（AirH" PHONE/PALDIO brouserphone/ASTELドットi）
てな感じで…。

>245 そうですね。
ADSLみたいに非対称通信といいたかったわけで。

一台増えるけど、
squid---c-docomo---黒山羊
の三段体制とかは？
squidとc-docomoは同居でも良いと思うけど。。

>>248
28.8k対応：
50xは504以降。
25xは252以降。
21xは該当無し。
6xxも該当無し。

>>251
これ以上の鯖増設は携帯ユーザーの資金でお願いします。

今の状態を見る限りキャリアの問題とは違うんじゃないかな？

auもdocomoもほぼ同じアクセス数で同じような負荷

>>254
>多分どこかでバッファリングしてるはず。
http://www.hitachi.co.jp/Sp/TJ/2002/hrnmay02/hrn0508j.htm
http://www.hitachi.co.jp/New/cnews/2002/0311/index.html

auは確か日立だったと、
docomoはNECなので、少々違うと思います

>>241に関連したことですが・・・・
「携帯電話は移動する」　→　電波状況が悪くなる　→　強制切断
・・・で、「２ｃｈからのデータが完全に送信完了されない」ために
ゴミが溢れるということは考えられないですか？

前々から逝ってるけど中間（ｒｙ

ついでですが・・・・
ＦＯＭＡに限って言えば年末あたりにパケット定額料金の契約者に限定して
ネットワークの混雑状況に応じて個別に帯域制限をかける予定らしいので、
そのことで２ｃｈ鯖→ＦＯＭＡ携帯へのデータ送出が詰まりやすくなることも
懸念されてくるような気がしますです。

各キャリアの公式メニューに載せて有料にしちゃえよってのはガイシュツ？

>>253
それで正解にしよう。
これ以上巻き添いは拙いだろう。

>>260
http://qb5.2ch.net/test/read.cgi/operate/1086695147/6

携帯からの接続に課金してたんじゃないのかよ！
最初はそういう話じゃ無かったか？
いくら鯖増強したって、保つわけないよ。

有料でも快適に利用したいという希望者用に●専用鯖併設というのは？

今ここはそういう話をしてるんじゃないんです

しかもおまえら全部既出

docomoの190ってすげーな

そういえば、3 人娘の Apache がまだ 2.0.49 のままですよね。＠メモリリークの件

サーバのチューニングも大切だけど、PHPを使うのを
やめるのもひとつの方向性かもね。
全部のスクリプトを変えなくても、一部の重い処理だけを
バイナリ化するだけでも全然違うだろうし。

>>267
64bits 環境じゃないので関係ないですね。m(_ _)m

>>268
プログラムの保守性や開発のしやすさとの兼ね合いもありますね。< PHPをやめるかどうか
個人的には、PHPを少なくとも全面的にはやめないほうがいいかなと思っています。

圧倒的にCPUを食っているのがhttpdなので、
PHPの処理であることはほぼ間違いないですね。
あとは「どの」処理に最もコストかかっているかの見極めかと。

ちょっとだけAPC(無停電電源じゃなくてPHPを高速化するモジュール)をc-auでためしてみたけど、
あんまり速くならない模様。

これでZend optimizer, PHP acceralator, APCを試してみたけど、
フリー物ではPHP acceralatorが一番(しかも、相当)いいみたい。

さきほどc-othersとc-auで呪文を唱えました。
c-docomoでも機を見て唱えてみる予定。

>>272 は「効果があれば」の話です。
しばらくはc-auで様子をチェックで。

内容は >>271 をもう少しまじめに設定してみた、ということで。

PHP用プロファイラって無いの？
PHPじゃtruss/traceしても仕方ないか

きたく。

>>274
プロファイリングはしたいところですね。
このへん(PHPのプログラムでどの処理が高コストなのかを調べる)は、どうやるのがいいんだろう。

>>275
> このへん(PHPのプログラムでどの処理が高コストなのかを調べる)は、どうやるのがいいんだろう。

勘で。

あんまり効果ないっすね。設定が悪いのかもしれないけど。
いちおう、shmモードで動かしてみてました。

php_acceralatorと一緒に動かしたり(さっきのc-others/cのダウン)、

apc.optimization = 1
を入れたりすると恐ろしいことになる(今しがたのc-othersの急激な負荷上昇)ので注意。

前からの問題だが、c-auとc-docomoの鯖負荷が物凄い。
i.2ch時代はそれぞれの鯖でcgiを叩いて負荷が分散されたが、
c.2chでは中間鯖を経由してdatを読む、それに呼び出しが殺到な感じ。
機種別統計の必要性が感じられる。

機種別統計案は>>249で上げて居ます。

ということで、さきほどphp_acceleratorに戻しました。< c-au/c-others

>>279
参考までに昨日のログでアクセス数を調べてみるかな。

game6と同じ問題があるかもしれない(高負荷時には統計取りの負荷もばかにできなくなる)ので、
アクセス統計の取り方を変えてみよう。

それまで、少しアクセス統計とるのをおやすみ。< c-au/c-docomo

統計とめてしばらく見てるけど、まさに焼け石に水だなぁ。

それでも働き続けている彼女たちは健気ですよね。＠ 3 人娘

でもってもしかして、素敵な淑女達でやるよりも、
幼気な少女（低スペック＋低帯域）を何十人と集めて捌いた方がいいのかな？＠キャンディーズよりも娘。みたいな（ｗ

こんなのあった。とりあえずメモ。
これで板カテゴリを出すところとか、相当にキャッシュできそうな予感。
キャッシュデータをMySQLで管理するのにも対応しているし。
http://www.jpcache.com/

サーバ側のセットアップ(まだやってません)の後に、プログラム側の書き換えも必要なのか。

プロファイラと言うよりデバッガなのかな？
http://inagi.himitsukichi.com/~aozora/cgi-bin/pukiwiki/pukiwiki.php?xdebug%A4%F2%BB%C8%A4%C3%A4%C6%A4%DF%A4%EB

root ★さーん

cobra2247 のセカンドポートがLANのスイッチにつながったという
未確認情報がきましたー

>>287
これから確認します。

で、OKなら、
cobra2247のセッティング変更・掲示板バーチャルホストのmemoriesへの移動などをすすめます。

接続されていますね。192.168なアドレスをつけました。
セットアップ作業にはいります。

c-au or c-docomo を 分割じゃなく全面移行で、

私としては c-au だけど、
実験を目的とするなら c-docomo ですかねぇ

>>290
c-docomoですかね。

cobra2247はdual channelのSCSIですが(peko仕様)、
両方が同じチャンネルに接続されています。

他のpeko同様に別のチャンネルにわけてもらったほうがよいので、
これは別途すすめます(メールはCc:します)。

etc2 society2 food5 の内容をmemoriesに転送中。
この後別スレで変更の儀式の予定。

今回の目的は

CPU パワーがあれば解決するの?

yes /no でーす

>>292
了解。

それだと、PHPアクセラレータが使えるi386モードがいいのかな。
あ、i386互換モードで動かせばいいのかも。

いずれにせよ、まずはできることをやってみましょ。

>>291
乙です。
先に移転した分↓についてもmemories入りをよろしくお願いします（念のため）。
etc2→life6(body hikky mental psy sousai utu)

１０倍はこなせるですよね？

>>294
すべてホームディレクトリをまるごと移動しました。

>>295
おどしですか(w。

FOX様、もしいらっしゃいましたらこちらへお願い致します。

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

bananaとpecoのCPUの性能の差をいよいよ見られるわけで まじにわくわくです

FOX様、おられましたらこちらへお願い致します。

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

お店からですかね・・・＞狐さん

http://tmp4.2ch.net/test/read.cgi/mog2/1089018804/

363 名前： ◆BDFCNV1.to 投稿日：04/07/07 20:30
さてさて、

ﾀﾞﾀﾞﾀﾞﾀﾞﾀﾞﾀｯ

クラシックさん and/or ◆BFzK/mtqM2さん、いますか。

新c-docomoの準備ができました。

c-docomo.peko.2ch.net という名前を一時的につけてあります。
アカウント等の設定は現c-docomoと同じです。

中身を入れ込んでくださいです。
c-docomoから転送しようと思ったけど、重い重い重い重いでだめぽでした。

＞root★さん、

いますよーん

＞◆EA.clAssIcさん、

c-othersのでいいんだよね。

>>302
裏口も含めて設定済みですので、同じものでよいはず。
準備できたらここで知らせてくださいです。

>>302
私やりますよー

携帯用とＰＣ用は内容を分離することきぼんぬ。
（＝同じものは見えない）

既に作業進行しはじめている予感。

ということで、うまく調整してくださいです。

あら、、、
確認ですが、作業完了後に名前がc-docomoに変わる、
で良かったですか?　>>rootさん

>>307
そうです。(>>290)

あら、コピーしおわちゃった。

多分大丈夫な予感です。

おつです。＞両氏

いちおう、両氏からの動作OKの確認を待って、儀式依頼します。

でも中の人が >>300 であることと、DNSが変わるのに時間がかかることから、
本格稼働は明日以降になる予感も。

動作確認OKです。
今名前が変わる前なので、subjectをｷｬｯｼｭしちゃってますが、
c-docomoに変更後は期待通り動作すると思います。

ところで、.BAKﾌｧｲﾙは削除して良いですか?　>>◆BFzK/mtqM2さん

削除しちゃってくださいｗ
他にいらないのも。。。。

了解ですー
皆様、お疲れ様です。

datﾌｫﾙﾀﾞもsubjectﾌｫﾙﾀﾞももう要らないんだよな。。。。

おつです。
では、儀式依頼へと。

依頼しました。

さて、poundでちょっとつないでみるか。

旧c-docomo=>新c-docomoをpoundでつないでみた。

さて、どうかな？
ログを見る限り、だいじょうぶそうにみえるけど。

LAが2とか3ぐらいしかいかないや。< 新c-docomo
うそみたいだ。何か間違ってるのかな。

お、ちょっとまずいかな。
設定かえます。

大丈夫だった。再度上げました。

c-docomoは　503 Service Unavailable　です。

>>322
pound側でほんとうに携帯からしかみられなくなっています。
どうせ新c-docomoで止まるので、解除します。

携帯からは見れました。

そっかぁ。poundで飛ばすとIPアドレスが変わっちゃうのね。
PCから見るとわれわれも人大杉になっちゃうなぁ。しかたないか。

LAが1切ってるけど、何かの間違いってことはないよなぁ、、、。

うーん、むちゃくちゃ軽い。。。。

やっぱ、サーバとしての「モノ」が違うってことなのかなぁ。

アクセスカウンタ復活させてみませんか？　＜　新c-docomo

>>329
やってみる。

負荷は脈動的にかかるけど、LA=1〜3で安定してるみたい。
やっぱ、Pen4 Single IDEとOpteron dual SCSIでは比較することすらおこがましいのかも。

ちなみにPHPアクセラレータのamd64版はないため、次善の策としてAPCを導入しています。

ホントに軽いね。
http://ch2.ath.cx/load/c-docomo.html
って、pekoのが反映されてるのかな？

ためしにAPCを切るとか

>>332
DNSが更新されていないので、旧c-docomoです。
今は単に新c-docomoに転送しているだけだから、軽いわけで。

LA情報はしばらくはこちらで。
http://c-docomo.peko.2ch.net/_service/20040708.txt

>>333
明日以降、DoCoMoゲートウェイから直接来るようになったらやってみます。

>>334
なろほど、旧c-docomoがバッファになっている可能性もあるのかな？

いずれにしても、旧c.2ch.netの実績からすると当然のような気もしますね。
comic4鯖とdomoco以外のアクセスがなくなっているわけだし。

>>336
で、ディスクもストライピングを導入してnewfsのパラメータを変えてチューニングしてあるし、
apc(PHPキャッシュ)を入れているし、datキャッシュはblackgoatがやっているし、
掲示板がないのでPHP処理に注力できると。

でもこのへんのチューニングノウハウは、遅いサーバで四苦八苦したからこそ得られたわけで。

>334
同じファイルを指しているような。
http://banana404.maido3.com/~ch2c-docomo/_service/20040708.txt

>>338
お、こっちもpoundで運ばれるのか。
じゃ、既にメモリは変わったことになるわけか。

>>334
鯖監視所のc-docomoはc-docomo.pekoを読んでるみたいですね。
http://c-docomo.2ch.net/_service/20040708.txt
http://c-docomo.peko.2ch.net/_service/20040708.txt
ココまでオマケで転送掛かってるみたい。

旧c-docomoはmumumu.muのMRTG統計で取ってる方が
正規のLAなんじゃないですかね。

メモリ => 目盛
(ch2.ath.cxのことです)

http://ch2.ath.cx/load/c-docomo.html

しかしそうして見ると、改めてすごい。

>>340
そうすね。こっちはhttpでとってないので、転送の影響出ないし。

295 名前：wbcc1s15.ezweb.ne.jp＠FOX ★ 投稿日：04/07/07 22:14 ID:???
１０倍はこなせるですよね？

とりあえず、今の負荷からすると10倍こなせそうな予感はしますね。

負荷は喫水線を超えるとがばっと来るので油断は禁物ですが、
とりあえずそれなりに性能は出せている…のかな。>>343

live8を作っていた時にも思ったけど「これで本来の性能」と思うと、
実はそうじゃなかったりするんだよなぁ。

ところで、pekoは一時的なもの？

まだr.i/p.iを止めていないサーバがかなりあるわけで、、、。>>345

そうですね。
またしばらく様子見ですね。

11日は球宴（長野）と参院選開票があります。どれくらいの負荷が
かかるか興味があります。

さて、DNS変更後もこの軽さが続くことを祈りながら、本日はおやすみなさい。

ためしにhttpdを再起動してみた。するとLAが一時的に上がる。
APC(PHP中間コードキャッシュ)がうまく動いている予感。

さて、ねるか。

でしょ

次はフロント全部peko にして
30倍の負荷を BlacGoat へですよー

で、このとき多分耐えられなくなるけど
これを解消するのはソフトウェァ的手段で、という運びになっとります。

>>351
えっ、もう次のプランですかぁ・・・
相変わらず、早いですねぇ・・・

がんばってください・・・

>>351
あと2台のpekoをどこから調達するのか気になります。
cobra2246が空いてて、もう1台は…?

othersどこかと同居でも問題ないんじゃないかなぁ〜

>>354
cobra 2244(game6とnews11)をどけるのでは？
移動させるとしてもgame6がbanana3台分いるのですよね。
値段調べてませんが、banana3台とTiger1台どちらが安上がりなのかわかりません。

news12が空くんじゃない　（ﾎﾞｿ

キャッシュの効率化を考えたら、キャリアじゃなくdatを取りにいく先で分けたほうがいいんじゃないかな？

>>358
お、それいいですね。
絶対ヒット率上がるし。

news*、tv*、... 用blackgoat
etc*、life*、... 用blackgoat
love*、comic*、... 用blackgoat

っていうかんじかなと(上記分け方に意味はないです)。

>>357-358
その方法は封印して一台で動くようにプログラムを書こうという話でーす。

>>360
なるほど、それがソフトウェア的手段(>>351)だと。
何か、勝算がおありなので。

まずは　30倍負荷下の BlackGoatを作り出さなきゃ
なにも見えてこないかと・・・

つまりあそこが悲鳴を上げるかな? とかは予想は出来るけど
実際にはわからないわけで、

と言う訳で入り口を広くしましょうと言うことですね。

とすると実作業は、

1)c-auをpekoにする
1')c-others/c(同じマシン)をpekoにする
2)すべてのサーバのr.iとp.iを止める
3)i.2ch.netのr.iとp.iに行く入り口をふさぐ

ということになるのかな。

概ねそんな順番かと、

c-au をpeko にして、r.i / p.i を順次とめてみて
どこまで耐えられるか、、、
c-others はpeko化が必要になった時点で、

各板のi/index.html生成もとめてみればいいかと＞r.i/p.i停止

要は、c.2chの負荷テストですかな？
でも、失敗すると、少し前にc-docomoがダウンした二の轍を踏むのでは…。
現在は少し前の過負荷状態は解消されたが…。予断が許さない状態だし…。

>>366
たぶん /i/ の停止は一番最後になる予感
bbs.cgi の改造ですし、

削除じゃなくて、c-　への誘導リンクにして欲しいな
と思ってみる。

これはどのように理解すればいいのだろうか?

>>370
これは今のbanana404かな。

だとすると、
・入るほうは: (1)携帯からのリクエスト (3)cobra2247からの応答
・出るほうは: (1)携帯への戻り (2)cobra2247への転送

かと。つまり、今は単純に「水道管」になっているだけかと。

なるほど、なるほど

ということで、c-docomo/c-au/c-othersの代表化作業ができました。
DNS浸透すれば(1日かな)、形が整います。

ということで、クラシックさん、◆BFzK/mtqM2 さんにお知らせです。

1)それぞれのフロントエンドへのアクセス方法:

c-au1.2ch.net
c-docomo2.2ch.net
c-others1.2ch.net

でアクセス(ファイルのうｐ等)してください。

また動作確認が必要な場合には、それぞれの名前でhttpアクセスすることもできます。
デバッグ用のアクセスコントロールもしてあります。

2)設定

それぞれのフロントエンドには、代表名でアクセスが来ます。
つまり、携帯側から送られてくるホスト名は、今までと同じです。
(c-au.2ch.net, c-docomo.2ch.net, c-others.2ch.net となります)

LAがピークで24ぐらいになるのか。
ということでちょっとだけ設定をいじってみた。

# Apacheを起動しなおすとPHPの中間コードキャッシュがなくなるので、LAが一時的に急上昇。

負荷監視所見たら、au鯖だけ物凄い負荷（一時に比べ、1/10だが）。
他鯖（c.2ch以外含む）の10倍の負荷がかかっている。下手すれば、ダウンしかねない。
docomo/others鯖は負荷が今のところ安定している。

傾向としては、アクセス数がある喫水線を超えると負荷がぐわっと上がる感じだなぁ。
c-au1とかは明確にそうだし、peko化して劇的に軽くなったc-docomo2もその傾向。

あちこちのr.i/p.iを止めた時に、どうなるのかなぁ。
もしレスポンスが悪く重くなったら、またチューニング(= 悪あがき)の日々か。

それもまた楽し。

おっ　何かが切り替わった?

でもこれらはどういう意味なんだろ、、、
難しいなぁ、、、

>>378
DoCoMoのサーバにDNSが浸透しましたね。
c-docomo1=>c-docomo2へのpoundでの転送をとめます。

>>379
上は、c-others1に代表(c-docomo, c-au, c-others)を集めたからですね。
c-auの青線がたまに上回るのは、なんでだろう。

とうめん　c-docomo1 (banana404) が空いている状態ですが、
ロビンちゃんの実験(別にする必要はないけど)でもしますかー?
au 用をターゲットに、

>>382
おぉ、c-au2の登場ですか。いいかも。

今日はもう眠くてアタマが回らないので、
明日の午後あたりにでも。

c-au2のバーチャルホストの設定しました。
儀式場にて。

c-au2の準備ができました。
アカウント等の設定は現c-au1と同じです。
2ch.net的DNS設定はまだですが、banana404.maido3.com でアクセスできます。

ということで、中身を入れ込んでくださいです。 ＞両氏

見えないので書き込み

c-docomo1中身は消しちゃったのかな？
そのままで動くはずです。

>>387
そうすか。
だとすると、バーチャルホストとしてc-auを受け付けるようにすればいいのかな。

実験だし、それでいいかな。
んじゃやってみます。

ロードバランスしてみた。

ログでみる限り、うまくいってそうな予感。
そのうち転送量グラフに反映されるかなと。

で、今回はDNSラウンドロビンではなくて、poundの分散機能を使用。
こんなかんじで。

UrlGroup ".*"
BackEnd 206.223.150.95,80,1
BackEnd 206.223.150.140,80,1
EndGroup

現在のところ、こうなのかな?

c.2ch.net (banana405)
|- c-au1 (banana403) -|
|- c-au2 (banana404) -- 二台でロードバランス
|
|- c-docomo2 (peko247)　- 強力な一台
|
|- c-others (banana405) - c と共用

そうですね。>>392

こんなかんじで、分業制で機能しています。

・総合受付、携帯との通信担当
　banana405

・PHP処理担当
　au係 banana403 banana404
　DoCoMo係 cobra2247
　その他係 banana405

・dat/subject.txtキャッシュ、I/O担当
　banana406

ロードバランスなんてするとFOXさんに怒られますよ

なんて。

>>394
実験だし。
でも2ch.netドメインでロードバランシングを導入したのはお初かもね。

ロードバランシングはかなり効果ある模様。今日のピークを乗り越えられるか。
http://ch2.ath.cx/load/c-au1.html

順次p.iとr.iを止めていき、BlackGoatの限界を見ていくフェーズに移行かな？

c-docomo2は徐々にメモリが少なくなってきていますね。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/memory/c-docomo2memory.html

ふうむ、MaxRequestsPerChildが1000の時よりも100の時のほうが断然軽い、、、。< c-docomo
ちょっと不思議な気がするけど、PHP+APCキャッシュな設定ならではなのかも。

>>398
ということで、設定変えてみたです。メモリというより処理自体が滞留していたみたいなので。

あらホントだ、
LAが100→30に一気に下がった。

c-au[12]も重くなってきたので、c-docomo2と同じ設定にしてみた。

つまりphp_accerelatorを止め、APCキャッシュに変更し、
MaxRequestsPerChildを1000から100に変更。

c-au[12]も下がった。アクセスがハイレートの時は、APCキャッシュのほうが効果あるのか。

念のためc-others1も同じ設定にしておいた。

どうもhttpdのゾンビさんがいっぱいいました。< c-docomo
とりあえずリブートしてみた。

これで概ね落ち着いたはず。
少しめしくってきます。

c-au1とc-au2のアクセス数統計を復活させてみた。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/

次の実験はDocomoとauの鯖を取り替えっこですかい？
Docomo→ﾛｰﾄﾞﾊﾞﾗﾝｽ
au→peko鯖

次は
もうちょっと統計情報を取ってから
どんどん r.i / p.i を停止して、どこまで負荷が上がるか。。。

c-docomo2 (peko) が果たしてどこまで受け止められるか !?
c-au1 / c-au2 のコンビではどうか。。。

を予定してますー。

>>409
あと、BlackGoatはBananaで充分かもね。

りょーかいです ｍ9っ｀Д´)

p.i / r.i を廃止しているサーバを五台ほど増やしてみた。

c-docomo2はまたLA100超えたね。

即日おなかいっぱいか、、、。< c-docomo

もう携帯は禁止するしかないよ
携帯向けカテゴリだけpeko鯖に入れて別運用

作戦失敗かな？
i.2ch止めてc.2chがパンクしたとなると…。
i.2chでは各鯖に負荷がかかっていたが、c.2chでは特定の鯖にドンと負荷がかかっている訳だし…。

>>416
失敗じゃなくて、たんに現実をつきつけられた段階かと。

ふやす気になれば受付嬢は横並びで増やせるわけですが(c-auのように)、
ふやすためには第8層や第9層のプロトコルが(りゃ。

しかし、c-docomo2、涙が出る状況だなぁ。
何か手法はないもんかなぁ。

PHPの実行回数を減らす(キャッシュ使うとか、物量でクリアするとか)
1回の実行コストを下げる

このあたりか。

c-auとc-docomoの鯖を替えてみようぜ〜。

c-docomo2.2ch.net は作業中でしょうか？＠応答無し
uptime にも 1 user と入ってましたので。

>>420
作業中でした。異常なシステムメッセージが出て、パフォーマンスが悪くなったため、
リブートをかけたところ上がってこず。

リブート要請中。もし上がってこない場合、現地対応が必要かも。

>>421
やはりそうでしたか。
おつですおつですm(_ _)m

ﾒﾆｭｰの実行ｺｽﾄを下げるなら、
表示に関しては r.i と完全互換にして、ﾒﾆｭｰの機能を削るとかですか…

1)　URL解釈
2)　1)に沿って指定のｺﾝﾃﾝﾂを要求(dat、subject)
3)　ｺﾝﾃﾝﾂを整形

というようなｼﾝﾌﾟﾙなものなら、ｺｽﾄもいくらか安いかと。

移行に向けての試験の為一時的にr.i/p.iを止めて、c-docomoが飛んだ。
と言う事は、作戦失敗が濃厚になって来た。かな…。

×　一時的にr.i/p.iを止めて
○　順次r.i/p.iを廃止して

>>424
>>417

現状でクラシックメニューをPHPで動かすには重すぎたのかも。

・機能を減らしてPHPのままで様子見
↓
・減らしたままスクリプトをバイナリ化して様子見
↓
・おとなしくフロントエンド増やすor高スペックに変更

こんな流れ？

もはや、カテゴリ鯖（ここならqb5）の数だけ、c.2ch鯖を用意しないと持ちませんな…。
現在c-docomo脂肪状態だし…。志半ばで挫折か？

いよいよ「大黒埠頭」ですかねぇ

>>429
早くも登場ですかぁ・・・「大黒埠頭」・・・

c-docomoの脂肪の件：
1:廃止前提で止めているアレを復活（暫定的に）[type:rebith]
2:c-au/c-othersの中の人にdocomoを超臨時で受け入れ（危険が高い）[type:helply]
3:ミラーや私家メニューに誘導する（殺到すると問題あり）[type:paralel]
4:きっぱり諦める[type:salender]
どのように調理するか…。
野次馬は程々にして寝るぽ。

寝る前に…。
負荷実験で一時止めて、成功なら順次廃止、でも、「失敗したら」どうするんだ？
c-docomo脂肪は半ば挫折とも言えなくもない。作戦失敗の場合は謝罪と責任（ｒｙになりかねない。

ああ、眠くて頭がうまく回らん…。

>>432
なーんにも問題はないかと。
r.iや p.iが「はじめからそこにあったもの」と思ってますか？

>>432
あなたの言う「作戦失敗」とはいったい何なの？

携帯アクセスを受けるための器を作るとして、現在考えられている手段として
(a)システムチューニング、(b)プログラムチューニング、(c)課金モデル構築、
そのお金で(d)マシンを増やそうがあるわけで。

今、取りかかっているのは(a)で、何が処理の足を引っ張っているのかを見極めている
段階。(a)が行き詰まれば(b),(c),(d)を模索するだけの事。そう言う意味で、まだ始まった
ばかりの作戦で、打つ手、打たなければならない手は沢山あるのに、何を持って「失敗」
と言おうとしているのかわからん。

ま、サクサク動いて管理者はヒマでヒマで…という日が来れば「作戦成功」だろうが、
そんな日が近いうちに来るとは(多くの人は)ハナから考えてないんじゃないかなぁ。

荒鷲の要塞＝ＦＯＸ★

俺＝グレゴリー・ペック

俺＝ペ・ヨンジュン

俺＝グレゴリー・ペック によって、
荒鷲の要塞＝ＦＯＸ★は陥落！！

ここまでの一切のレスを読まずに発言。

携帯から削除依頼されるとアドレスが全く違うので確認できない。
アドレスをクリックしてもPCからだと人大杉になるのでスレタイすら見られない。
専用ブラウザでは対応していないので見られない。

この辺の解決策って何か出てるのかな？

>>439
Cのスレを表示する。
↓
「写」をクリック
↓
一番上のボックスににスレタイとread.cgi用URLあり。


これにて削除依頼可能。携帯のブラウザ機能を使うよりも便利だったりする。
r.iをread.cgiに書き換える必要ないし。

というかまあ削除依頼はフォーム依頼を前提としてるからねぇ。
携帯用投稿フォームも必要かなと感じたり。

とりあえず上記手法で本来のURLをひっぱってくることは可能。

setrootbyname failed
ffs_mountroot: can't find rootvp
Root mount failed : 6

>>442
あわわ、、、（汗）
そこで、wheel ★ ﾀﾝのご登場？（違

二人羽織中、、、。

あがりました。< cobra2247
中身をチェック中。

だいじょうぶな模様。リブートチェック中。

Me:
Reboot test is ok. I think the trouble of cobra2247 is fixed.
Jim-san, thank you for your work.

これからc-docomo復活させます。

動作チェック中。

概ね問題なさそう。< c-docomo