【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part15

-M32は結局流れを阻害するので、やめ。

-b1048576 (CGIからのPOSTの時のバッファをデフォルトの8倍にする)したら、ex7がとっても好調に。
しばらく見て調子いいようなら、これにしてみよう。

ただしlive8の変更は、本日が落ち着いてから。

SpeedyCGI環境では、ある「壁」までは、割と軽く動くみたい。
その壁にぶち当たると、だめと。

今のhttpdの並列数は、768〜896あたりがせいぜい。
1024だともう苦しくて、それより大きいと「どーん」に耐えられないと。
大きくしても、bbs.cgiが詰まるだけ。

りょうかいですー

read.cgi(DSO味) の実験は live8 に触らなくてもよくなってからにします、
来年にでもまた、

>>765
そですね。

live8のbbs.cgiは今の(8.01+)でいきますか。
で、仕込みをdso.2ch.netでしっかりやる方向で。

これ見ました？
http://www-6.ibm.com/jp/developerworks/linux/041119/j_l-optperl.html
dW : Linux : Perlを最適化する

915 名前：root▲ ★[sage] 投稿日：04/12/01 23:15:49 ID:???
ex7は、httpdの並列数を896に戻した。
これ以上増やすと(少なくとも1280とかにすると)、
bbs.cgi(speedy_backend)が増殖しまくって、さっきみたいに結局意識不明に。

ex7も、入れたら768に戻しておこう。
カキコ遅くても、今のままだとこれ以上は、無理な模様。

>>767
おっ。見てみるか。

いきなり

> お粗末なプログラミングで、お粗末なパフォーマンス

きびしいのう。
といってもこれは、私だけで何とかできる問題でもないわけで。

dsoのbbs.cgiスレに期待しよう。

ざっと読むと、泣けるなぁ。書いてあることはわかります。
直感ですが、とっても、該当しているような気が。

dsoのbbs.cgiスレかここのbbs.cgiスレあたりで、話題振ってみていただけると。

さて、

・httpd起動数はもうこれ以上は増やせない (tiger: 768, cobra: 896)。
・「スロットいっぱい」「bbs.cgi詰まり」が観測された。
kqueueステータスだったので、DNSまわりの結果待ちな予感。
=> DNSサーバの再チューニングが必要か。
=> 特にBBS/BBQ/DNSキャッシュサーバ。

・mod_cgidsoは、パフォーマンスを確実に底上げしている。
read.cgiは、この路線で進むのが当面、正解と思われる。

・やっぱりbbs.cgi、こいつを何とかしなきゃ。

他に何があるかな。

http://mumumu.mu/mrtg/mrtg-rrd.cgi/bbqbbx/bbs.html

BBS変だったみたい。

BBQは(少なくともDNS側は)、変じゃなかったのか。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/bbqbbx/bbq.html

BBQはCobra(oyster243)だからなぁ。

http://mumumu.mu/mrtg/mrtg-rrd.cgi/traffic/bbqtraf.html

ちなみに、oyster243は、トラフィックのほうだと多少おかしく見えるけど、
bbs宛てのぶんかなぁ

BBSのDNS側ログをチェック中。
明らかにBBSシステムのDNS側、変でしたね。
この間、ひとつも処理できていない。
(時間はPST)

2004-12-01 05:06:03.757482500 cedf94fa:201d:2913 + 0001 1101906363.4977.60.40.234.32.0.40.1092895397.loveho.sakura02.bbspink.com.bbs.bbs.2ch.net
2004-12-01 05:45:57.994422500 cedf9837:c3f7:d610 + 0001 1101906363.66646.220.102.118.141.0.19.1101897431.dancesite.live17.2ch.net.bbs.bbs.2ch.net

日付変わったら、live8のbbs.cgiを他と同じものにしよう。

>>771
で、「スロットいっぱい」は、「bbs.cgi詰まり」により、惹起された模様です。
つまり、BBS処理がふんづまりになることによってbbs.cgiが滞り、
それによって詰まってしまった。

BBQは詰まっても大丈夫なように若者が対応したはずだけど(実験もした)、
BBSはどうなんだろう。

banana238 = BBS/BBY/BBX のdjbdnsを強化版(make WITH_PERSISTENT_MMAP=yes)に更新した。
おかしかったら、指摘よろしくです。

oyster243 = BBQ(niku) のdjbdnsも、強化版に更新。

cobra2245 = BBM のdjbdnsを同様に更新。
これで、更新はひととおりできたはず。

BBSがbananaではもたない、、、ということは、あるのか、ないのか。

「絶対に持つ」を前提に話すのが吉と思われ、

さて、めし、くってくるです。腹が減ってはなんとやら。

落ち着いたらもいっかい今日いじった掲示板cobra/tigerサーバ群の設定を見直しておこう。
設定もれとかがあると、いまいち。

>>781
ふむ。わたしもそう思っています。< BBS
BBQがbananaではもたなかったのは、DBがでっかかったから(これは明確)。

今のBBSはDBを持ってないので(データがないことしか返していない)ので、
もちろん、もつはずという前提です。

その前提で、サービスが停止した原因を考える必要があるとおもわれ。

# めしめし。

ちなみに今のBBQデータ。でかっ。

%ls -l data
-rw-r--r-- 1 ch2bbq ch2 73286705 Dec 1 07:20 data
%wc -l data
5158061 data

BBQ/dnscacheのログ
http://mumumu.mu/mrtg/mrtg-rrd.cgi/traffic/bbqtraf.html

該当時間、INが少ないですね。

つまり、一般の軽かったサーバも含めて、
問い合わせがDNSキャッシュに十分に行っていなかった、ってことなのか。

BBSのぶんがなかった、というのと一致するわけか。
さて、理由は。

bbs.cgi での各処理の順番はどうだったかな、、

BBQ -> BBX -> BBS -> BBY だったかな

>>777
>BBQは詰まっても大丈夫なように若者が対応したはずだけど(実験もした)、
>BBSはどうなんだろう。

ここでのお題目は、その「つまり」を起こさないことかな。
起った場合の逃げコードはサザン ★君が暇になったら
ぼちぼちやってもらうという事にして、

BBQ -> BBX -> (BBY) -> BBS だった。

Load Average @ stats.2ch.net

2004/12/01 21:00:00 LA= 9:00PM up 186 days, 22:19, 0 users, load averages: 0.00, 0.06, 0.11
2004/12/01 21:10:00 LA= 9:10PM up 186 days, 22:29, 0 users, load averages: 0.08, 0.10, 0.08
2004/12/01 21:20:00 LA= 9:20PM up 186 days, 22:39, 0 users, load averages: 0.20, 0.18, 0.12
2004/12/01 21:30:00 LA= 9:30PM up 186 days, 22:49, 0 users, load averages: 0.06, 0.12, 0.11
2004/12/01 21:40:00 LA= 9:40PM up 186 days, 22:59, 0 users, load averages: 0.17, 0.10, 0.08
2004/12/01 21:50:00 LA= 9:50PM up 186 days, 23:09, 0 users, load averages: 0.25, 0.15, 0.10
2004/12/01 22:00:00 LA=10:00PM up 186 days, 23:19, 0 users, load averages: 0.06, 0.12, 0.10
2004/12/01 22:10:00 LA=10:10PM up 186 days, 23:29, 0 users, load averages: 0.07, 0.10, 0.08
2004/12/01 22:20:00 LA=10:20PM up 186 days, 23:39, 0 users, load averages: 0.05, 0.11, 0.08
2004/12/01 22:30:00 LA=10:30PM up 186 days, 23:49, 0 users, load averages: 0.02, 0.05, 0.06
2004/12/01 22:40:00 LA=10:40PM up 186 days, 23:59, 0 users, load averages: 0.04, 0.09, 0.08
2004/12/01 22:50:00 LA=10:50PM up 187 days, 9 mins, 0 users, load averages: 0.29, 0.32, 0.20

LA 見る限りは、特に負荷が上昇しちまったようには見えず、

上がるとしたら、負荷じゃないですね。

BBQがだめぽになった時も、LAがあがらなかったです。
プロセスが増えるわけじゃないから。

BBQの時はI/Oがつらくなって、処理がふんづまりました。
LAは低いままで、DNS問い合わせに答えられなくなったと記憶。

てなわけで、今送信側(news18とかnews19)のDNS問い合わせログをチェック中。

1行目の「負荷」は、LAと読み換えてくださいです。>>791

ということは、
DNS問い合わせのたびに呼ばれるプログラムは特に問題ないということかな?
どんどん呼ばれてもどんどんはけて行く or 一個しか起動しない。

>>793
そっち側が変になっても、DNS側がブロックしないように組んであるはずです。
# いちおう、確認してみます。

>>778 の順番に処理しているんで

呼ばれる回数は BBQ > BBS ( >>> BBX >>>>>>>>>> BBY) です

news18の問い合わせログを見ました。

2004-12-01 05:06:06.098103500 tx 0 1 1101906365.98088.0.0.0.0.0.57.1101628087.anime.news18.2ch.net.bbs.bbs.2ch.net.maido3.com. maido3.com. cedf93fe cedf94fe
2004-12-01 05:06:06.102803500 nxdomain cedf93fe 2560 1101906365.98088.0.0.0.0.0.57.1101628087.anime.news18.2ch.net.bbs.bbs.2ch.net.maido3.com.
これは「ないよ(nxdomain)」の応答があるのに、

2004-12-01 05:06:13.843026500 query 2292275 7f000001:4d75:fe65 1 1101906373.98241.0.0.0.0.0.94.1101743825.mnewsplus.news18.2ch.net.bbs.bbs.2ch.net.
この問い合わせに対する、BBSのDNS側からの応答(nxdomain行)がありません。

で、このあと、BBSについてその状態がずっと続く。

つまり、
・問い合わせ側システムは正常
・でも、BBSのDNS側からの返事がなかった

ということになります。

同じサーバ(banana238)で動かしている別のDNS(BBX/BBY)は、
該当時間、どうだったのかな。

訂正

>>788 の順番に処理しているんで

呼ばれる回数は BBQ > BBS ( >>> BBX >>>>>>>>>> BBY) です

>>796
BBXとBBYはその時間無事動いていたことを確認しました。
また、BBQも同様に確認しました。

おかしかったのは、BBSだけか。

んんん?

それはいったいどういうことじゃ?

なぞだ、

しかも、live8やex7が変だった時間と、一致するような予感。

というよりひょっとすると、BBSが変になったことで、live8やex7もつられて落ちた、
というのが、正しいような気もする。

ちなみに
BBS呼び出し側(bbs.cgi)には、タイムアウトを検出する処理はいってます

マツケンサンバが始まったのが22:05:00 ころですね。
その直後にlive8は落ちました。ex7はもうちょっとあとかも。

>>800
その可能性は、なんかあるかも、、
BBSが動いてない時間に、どの鯖でもbbs.cgiが微妙に動作が遅かったですね、、

入ってましたか。つまりブロックは数秒(何秒でしたっけ)ですむと。
つまり、他のサーバは「あれ？」ぐらいで、済むわけか。

「数秒のブロック」が雪ダルマ式に影響が出るのは、
その時カキコが激しかったサーバということだとすると、
ex7とlive8だけ壊滅するのは、ありうることかも。

live8とex7のシステムログを、緻密にあたってみます。

>>802
とすると、、、。

ex7/live8からものすごいDNSアクセスがBBS側のDNSに来て、
BBS側が不調になり、
bbs.cgiの滞留が起こりはじめ、
それが顕著に起こったex7/live8が、ブロックプロセス過多で壊滅した

というシナリオは、ありうるわけだ。

その部分のコード

{
my $BYTES = length($FORM{'MESSAGE'});
my $BHOST = "$NOWTIME.$$.$ENV{'REMOTE_ADDR'}.$NEWTHREAD.$BYTES.$FORM{'key'}.$FORM{'bbs'}.$ENV{'SERVER_NAME'}.bbs.bbs.2ch.net";
eval{
alarm(3);
my $YACHO = gethostbyname($BHOST);
alarm(0);
};
alarm(0);
if($@ =~ /timeout/){
last;
}
}

ちゃんと動いていると思うんですが

BBS だけ止めてみるなんてこと出来ますか?

>>806
簡単です。

タイムアウト処理が正しく動いているか検証してみよう。

時間決めて、しばらく止めてみろということですか。
では、1:45から2分、BBSだけ止めてみます。

これから止めます。< BBSのDNS

今、BBSだけ止まっている状態。

5秒ぐらい? ディレイかかりますね。

書き込みが多いサーバ(ex7)の様子をチェックしてきます。
まだ、BBSは止めています。

ですね、

これと同じことが当該時間帯に別のサーバで起ったという記憶があります

すごいことになってる。
LA上がってないけど、ブロックばかり。

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
631 dnscache 98 0 32868K 32172K select 0 104:59 5.81% 5.81% dnscache
11196 ch2ex7 4 0 7112K 6336K kqread 2 0:01 5.08% 2.00% speedy_back
11051 ch2ex7 4 0 7092K 6320K kqread 0 0:00 3.24% 1.86% speedy_back
11045 ch2ex7 4 0 7080K 6376K kqread 0 0:00 3.15% 1.81% speedy_back
11037 ch2ex7 4 0 7088K 6316K kqread 0 0:00 2.96% 1.76% speedy_back
11301 ch2ex7 4 0 7096K 6324K kqread 0 0:00 12.26% 1.71% speedy_back
11330 ch2ex7 4 0 7068K 6304K kqread 3 0:00 35.00% 1.71% speedy_back
11302 ch2ex7 4 0 7092K 6320K kqread 2 0:00 11.56% 1.61% speedy_back
11310 ch2ex7 4 0 7088K 6320K kqread 1 0:00 11.56% 1.61% speedy_back
11041 ch2ex7 4 0 7092K 6320K kqread 0 0:00 2.71% 1.61% speedy_back
11043 ch2ex7 4 0 7092K 6320K kqread 0 0:00 2.71% 1.61% speedy_back
11046 ch2ex7 4 0 7060K 6292K kqread 0 0:00 2.81% 1.61% speedy_back
11263 ch2ex7 4 0 7100K 6316K kqread 3 0:00 6.02% 1.56% speedy_back
11319 ch2ex7 4 0 7060K 6292K kqread 0 0:00 15.89% 1.51% speedy_back
11253 ch2ex7 4 0 7068K 6300K kqread 0 0:00 5.65% 1.46% speedy_back
11039 ch2ex7 4 0 7092K 6320K kqread 0 0:00 2.47% 1.46% speedy_back
11316 ch2ex7 4 0 7092K 6320K kqread 0 0:00 10.50% 1.46% speedy_back
11296 ch2ex7 4 0 7092K 6324K kqread 3 0:00 7.53% 1.37% speedy_back
11292 ch2ex7 4 0 7096K 6324K kqread 0 0:00 7.26% 1.32% speedy_back
11067 ch2ex7 4 0 7064K 6296K kqread 1 0:00 2.30% 1.27% speedy_back
11217 ch2ex7 4 0 7064K 6296K kqread 0 0:00 3.50% 1.27% speedy_back
11062 ch2ex7 4 0 7064K 6360K kqread 2 0:00 2.22% 1.27% speedy_back
11305 ch2ex7 4 0 7092K 6320K kqread 0 0:00 9.10% 1.27% speedy_back
11073 ch2ex7 4 0 7080K 6312K kqread 1 0:00 2.22% 1.22% speedy_back
11247 ch2ex7 4 0 7060K 6296K kqread 2 0:00 4.13% 1.22% speedy_back
11171 ch2ex7 4 0 7080K 6316K kqread 1 0:00 2.65% 1.12% speedy_back
11152 ch2ex7 4 0 7080K 6380K kqread 3 0:00 2.49% 1.12% speedy_back

なんか重いと思ったらまた遊んでやがんなｗ
ま、原因がわかったらはよ直してね

BBSあげました。

ex7のブロックは解消しました。

体感では、さきほどBBSが止まってた時と
ほとんど同じくらい(2〜3秒)の引っかかり感がありますね。

BBSの戻りは一切チェックしなくてもいいので、
bbs.cgi側のディレイを「なし」にできると、うれしいかも。

alarm(3);
を
alarm(0); とかにすればいいのか?

それとも alarm(1); が最小なのか?

＞ 指定した秒数(実際は 1 を引いたもの)が経過した後、 SIGALRM をプロセスに伝える。
＞ つまり、 `alarm(15)' はそれから 14 秒以上経ったある時点で SIGALRM を起こす。

らしいので、alarm(1); でディレイ0になるんじゃないかな。

ほぅほぅ

やってみよう、

あ、そういえば、
bbs.cgi 配布サイトに、live16 と live17 も加えておいてくださいです。
これらは FreeBSD 5.3R への更新に伴い、
perlcc バージョンの使用をやめました。
今後も、perlccバージョンにする予定は当面ないです。

live8 もさきほど perlcc をやめましたが、
私の判断で、perlcc版とスイッチするかもしれないので、
当面従来どおり配布ホストには、入れなくてよいです。

alarm(1);のbbs.cgi に全サーバ置き換えた

>>823

live16,live17 りょうかいです

bbsにはあいかわらず、query来ています。
このカキコの後で、BBSを再度止めてみます。

BBS止め中、、、。

ちょっと引っかかる感じはありますが、さっきよりいい感じですね。

live16 , 17 も元々配られているようです

>>828

I think so too.

>>829
了解です。

ex7の様子を確認してきます。

ブロックは、してるみたい。< ex7

631 dnscache 97 0 32868K 32172K select 1 105:17 6.10% 6.10% dnscache
25373 ch2ex7 4 0 7072K 6280K kqread 0 0:01 14.80% 2.69% speedy_back
25418 ch2ex7 4 0 7068K 6308K kqread 2 0:00 21.01% 2.00% speedy_back
25323 ch2ex7 4 0 7060K 6268K kqread 2 0:00 5.62% 1.66% speedy_back
25393 ch2ex7 4 0 7068K 6284K kqread 0 0:00 11.91% 1.66% speedy_back
25412 ch2ex7 4 0 7060K 6292K kqread 3 0:00 17.43% 1.66% speedy_back
25388 ch2ex7 4 0 7060K 6272K kqread 3 0:00 11.56% 1.61% speedy_back
25398 ch2ex7 4 0 7060K 6268K kqread 0 0:00 11.56% 1.61% speedy_back
25372 ch2ex7 4 0 7060K 6272K kqread 0 0:00 8.34% 1.51% speedy_back
25317 ch2ex7 4 0 7060K 6340K kqread 0 0:00 4.96% 1.46% speedy_back
25333 ch2ex7 4 0 7060K 6272K kqread 0 0:00 5.46% 1.42% speedy_back
25311 ch2ex7 4 0 7060K 6276K kqread 1 0:00 4.79% 1.42% speedy_back
25379 ch2ex7 4 0 7060K 6344K kqread 0 0:00 7.80% 1.42% speedy_back
25383 ch2ex7 4 0 7060K 6268K kqread 1 0:00 7.80% 1.42% speedy_back
25394 ch2ex7 4 0 7060K 6340K kqread 0 0:00 9.45% 1.32% speedy_back
25400 ch2ex7 4 0 7064K 6268K kqread 1 0:00 8.75% 1.22% speedy_back
25262 ch2ex7 4 0 7060K 6272K kqread 0 0:00 2.98% 1.17% speedy_back
25260 ch2ex7 4 0 7064K 6344K kqread 1 0:00 2.85% 1.12% speedy_back
25054 ch2ex7 4 0 7096K 6292K kqread 3 0:01 1.57% 1.07% speedy_back
25264 ch2ex7 4 0 7060K 6268K kqread 0 0:00 2.73% 1.07% speedy_back
25340 ch2ex7 4 0 7064K 6268K kqread 2 0:00 4.14% 1.07% speedy_back
25435 ch2ex7 4 0 7060K 6296K kqread 1 0:00 22.00% 1.07% speedy_back
25348 ch2ex7 4 0 7060K 6272K kqread 0 0:00 4.19% 0.93% speedy_back
25297 ch2ex7 4 0 7064K 6276K kqread 0 0:00 2.66% 0.88% speedy_back
25280 ch2ex7 4 0 7060K 6268K kqread 0 0:00 2.42% 0.88% speedy_back
25350 ch2ex7 4 0 7060K 6272K kqread 2 0:00 3.97% 0.88% speedy_back
25271 ch2ex7 4 0 7060K 6272K kqread 0 0:00 2.29% 0.83% speedy_back

>>821
これ、perl alarmで検索して一番上のところにそう書いてあったんだけど、
ほかのところはどこ見てもそう書いてないなぁ、、だいじょぶだべか、

BBSを再度動かしました。
ex7のブロックは解消しました。

遅延なしにはできてないみたいですが、さっきよりは、改善されたです。

live8 , ex7 が落ちたのは
直接的には BBS の返事がないから処理が貯まりに貯まって落ちたと、
元々 live8 , ex7 は物凄い書き込み数だと言うことが原因の一端であると、

しかし、根本的には何が起ったかというと
BBSがなぜか応答しなくなったと
なのに不思議なのは、同じサーバにある別のもの BBY 等は問題なく動いていたと

質問
同じサーバ内で BBS だけがぽしゃる事なんてあるんですか?

投げっぱなしで応答をまったく期待しない場合の
コーディング方法募集中です　(Perl >>805)

>>835
BBS担当、BBY担当、BBX担当のDNSサーバは全部別プロセスなので、
ありえますね。というか、全部がぽしゃらないようにしてあるともいえます。

>>836
具体的には gethostbyname() の結果がDNSから来なくても、
次に進んでほしいということですね。

>>837
なるほど、
ということは、サーバの負荷というよりも BBS(DNS)の限界?

>>839
それを疑っています。

その時間だけBBSのログがないのです。まったく「すぽーん」と。
まるで、サーバそのものがいなかったかのように。

しかし、djbdns+daemontoolsで作ってあるので、
プロセスがいなくなっても立ち上がるし、
サービスダウンには、とりわけ強いはずなんですよ。
すくなくともこんなふうにサービスがいなくなることは、これまで一度もなかった。

banan238の他のシステムログもあさっていますが、
今のところ不審なものは、発見できていませんです。

BBS はどれくらいコールされているかというと、、、
一日で 150万〜180万
ピーク時で一分間に・・・

どれくらいでしたっけ?
1,000 くらい?

>>841
投稿数のピークと同じですね。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/bbqbbx/bbs.html

12000/5min が、ピーク値かと。

ぐおっ　2,400/min

つまり 24ms毎にリクエストがあると、(平均ですが)
ぱっと見、それくらいいけそうな数字ではあるんですけど、

1分ごとだと3000〜3500かな？
夏〜秋ごろに、1分ごとのデータをグラフにしてたことがあるんですけど、
その時も記憶に残ってる限り最高で3500くらいでした。

>>843
普段はいけてますね。(>>842 のグラフ参照)
今回は、、、。

ん?
計算変かな?

35000/min だとすると 17ms 毎くらいか

もう二桁くらい小さい値で動くと思うんですけどね　< DNS
(単なる勘です)

で、いけない数字とは思えないんですよ。
DNSコンテンツサーバ側って、数千query/secぐらいは、さばけるはずなんです。

あと、今日やったMMAPの手術(>>778-780)で、
さらに30%らいは強化されているはず。

こちらで別の機会に実験した値でも、
DNSのコンテンツサーバ側は数千queries/secまでは問題なく動く、
という結果が出ています。>>847

初めての経験ですからねぇ

「たまたまだった」という結論にでもしますかねぇ
二度目があったら・・・そんときに再度考える?

BBSが動いていない現象自体はしょっちゅうありますけどね、、
確かにこんな長い時間動かなかったのはめずらしいけど

今日のところは、そうしておきたいかも。>>850

DNSサーバ側を緊急強化したので、これで様子を見たいかなと。
今月は、機会が連日連夜あるに違いないわけで。

# うへー、明日朝早いんだよなぁ。

げっ
そういえばそうか?

たまたまじゃないのか?

DNS 自体は返事していて、単に数え漏れが発生しているということではない?
>>851

http://mumumu.mu/mrtg/mrtg-rrd.cgi/bbqbbx/bbm.html

BBM ってどうして毎日ざっくりりこんになっているんだろぅ

>>851
しょっちゅうあるのは、いまいち、、、かも。

DNS側がブロックしないように、ちゃんとなってるかちょっと見てみます。

>>853
んまぁ、、確かに他の止まってる時とは明らかに動作が違ってたですからねぇ。
いつもは数え漏れなのかもしれませんねぇ。
そうかも。いや、そうだべ。うん、きっとそうだ！

うーん。
http://mumumu.mu/mrtglog/2004/11/01/bbqbbx/bbs.html
http://mumumu.mu/mrtglog/2004/10/22/bbqbbx/bbs.html

確かにこのグラフの凹みは、とっても気になる。

強化したので、明日以降の様子をチェックしたいなと。

しかーし

限界を拝めるとは幸せなことで、

個人的には、ネットワークのチューニング問題な気がとってもするです、、、。

PIE の?

>>860
ではなく、banana238のです。

# netstat -s -p udp
udp:
361330042 datagrams received
0 with incomplete header
0 with bad data length field
8 with bad checksum
327 with no checksum
152972 dropped due to no socket
125983 broadcast/multicast datagrams dropped due to no socket
9072993 dropped due to full socket buffers
0 not for hashed pcb
351978086 delivered
352298516 datagrams output

今BBS止めてたんで、この値そのまま信用できないところがありますけど。

今netstat -z でカウンタをリセットしたんで、
この後様子を見てみます。

ドロップパケットとかが出てるようだと、
ネットワーク系を何かチューニングしないと、いかんかなと。

udp:
212 datagrams received
0 with incomplete header
0 with bad data length field
0 with bad checksum
0 with no checksum
0 dropped due to no socket
0 broadcast/multicast datagrams dropped due to no socket
0 dropped due to full socket buffers
0 not for hashed pcb
212 delivered
212 datagrams output

DNSはUDPなんで、具体的には、

# netstat -s -p udp
udp:
1996 datagrams received
0 with incomplete header
0 with bad data length field
0 with bad checksum
0 with no checksum
0 dropped due to no socket
0 broadcast/multicast datagrams dropped due to no socket
0 dropped due to full socket buffers
0 not for hashed pcb
1996 delivered
1996 datagrams output

の、droppedなんちゃらのところがカウントアップされるようだと、
いまいちですね

各個のサーバを強化し
台数も増やすと、、、

土台が小さく感じ始めるということかしら、
当然なんですけどもね、

>>863
それを　_serviceに吐き出しておくとか、
皆で観察 !

>>864
それは、多分にあるかなと。

今、２ちゃんねるで動いているDNS系の仕組みはこんなかんじです。
おおむね、上から負荷が大きい順。

・dnscache

量産型bananaからのDNS問い合わせを処理
cobra (oyster243)

・BBQ

BBQチェック、投稿毎に呼び出し、巨大DB参照
cobra (oyster243)

・BBS

野鳥の会、投稿毎に呼び出し、DB参照なし
banana (banana238)

・BBM

携帯版BBQ、携帯からの投稿で呼び出し、DB参照
cobra (cobra2245)

・BBX

Rock54、広告っぽい投稿毎に呼び出し、DB参照
banana (banana238)

・BBY

ヘッドライン&スレ立てチェック、スレ立て毎に呼び出し
banana (banana238)

>>865
やってみるです。

もっと書き込めるようにスレ保持数さげて(ex7)
現象が顕著に現れるようにしてみよう。

http://stats.2ch.net/_service/netstat-20041202.txt

10分ごとのはず。
BBQにもしかけてくるです。

楽すみ〜

BBQにもしかけた。
http://bbq.2ch.net/_service/netstat-20041202.txt

>>868 おっ。

>>871
droppedてｶｳﾝﾄされてますな

ふむ。

これよめと。
http://publibn.boulder.ibm.com/doc_link/Ja_JP/a_doc_lib/aixbman/prftungd/2365c92.htm

Dropped Due to No Socket
受け取った UDP データグラムのうち、宛先ソケット・ポートが開かれなかった数。
結果として、「ICMP Destination Unreachable - Port Unreachable」という
メッセージが送信されます。ただし、 受け取った UDP データグラムがブロード
キャスト・データグラムである場合は、ICMP エラーが生成されません。
この値が大きい場合は、アプリケーションがソケットをどのように処理しているかを調べてください。

port unreach か。
いまいちな予感。

>>868
いくつまで減らしたの？

処理が追いついてないのか、、、。
BBQはでっかいDBをrbldnsでmmap()してるからなぁ。

mmap() の頻度をもっとまばらにしてみるです。

ちょっと狼のスレ数減らさないでよ
大体ハロプロって50人くらいメンバーいるから
それぞれのカップリングスレだけでも50×50で2500は必要なんだし
各メンバーのファンスレ数種類にアンチスレ数種類もひつようだし
最低3000は必要だよ

BBQのdjbdnsは強化型になっていなかった(portsが古かった)ことが判明。
再度手術するです。

人が多い所はスレ保持数2000くらいでまわせるような感じにして欲しい

>>878 をやりました。
これからbbqのnetstatのカウンタをリセットします。

で、すみませんがスレッド保持数の話は、別のところでおながいします、、、。

狼をどうぞ沢山増やしてあげてください
VIPは300くらいでいいです
落ちても誰ひとりとして気にしません

>>877

狼なんてｲﾗﾈｰﾖ

VIPER一同より

我々はFOX ★がどんなに理不尽な仕様にしようとも受け入れて生きていきます

ex7のスレ保持数について
http://qb5.2ch.net/test/read.cgi/operate/1101926438/

スレ保持数については↑のスレでお願いしたほうが効果がありますよ

★☆★【狼ラウンジVIP野球競馬】ex7(tiger503)運用情報☆★☆
http://qb5.2ch.net/test/read.cgi/operate/1101909143/l50

>>880
とりあえず、これで、しばらく様子見ですかね。

>>887
そっすね、、、。

BBQ側のカウンタが微妙にいやんな感じなのが、ちと気になるです。
でもさすがに今日はもう寝ないといかんので。

tigerサーバ/cobraサーバのspeedycgiを、バッファ拡張版にした。
( #!/usr/local/bin/speedy -- -r1 -t60 -b1048576 )

今日は、ここまでかなと。

流れそうだから、もっかいおれさまメモ。(>>767)

意識なくなってきたんで、おやすみなさい。

2004/12/02 04:05:00
udp:
155591 datagrams received
　-略-
1 with no checksum
204 dropped due to no socket
　-略-
155387 delivered
156167 datagrams output

まぁ、今のところのstatsがdelivered以外0なのに比べると
確かに微妙にいやんかも、、
おやすみなさい。

>>891
http://bbq.2ch.net/_service/netstat-20041202.txt

増えてますね。
DNSキャッシュサーバをチューニングしてみるか。

FreeBSD 5.3R-p2
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-04:17.procfs.asc

workaroundは、procfsを使わないことか。

思い出したときに書いておこう。

今の902だと、/homeにAMD64なバイナリ(read.cgi/offlaw.cgi)が入っているから、
次のを作るときも、AMD64アーキテクチャじゃないと大変めんどいですね。
/homeを共有することになるわけだから。

Cobraクラスにするかもっと安いのにするか(組みようにより、安いamd64も組めます)は、
別途考えることになるのかなと。

下記がもしほんとだとしたら、、、。
DNSサーバ系も絶対5.3Rにしよう、そうしよう。

blackgoat4: FreeBSD 5.2.1R

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
684 squid 96 0 347M 341M select 0 212.3H 19.48% 19.48% squid <= CPUを20%食ってる
623 root 96 0 42420K 5416K select 0 4:59 0.00% 0.00% httpd
561 root 96 0 1608K 928K select 2 2:04 0.00% 0.00% ntpd
658 root 8 0 1232K 484K nanslp 0 1:50 0.00% 0.00% svscan
297 root 8 0 3108K 2508K nanslp 1 1:42 0.00% 0.00% ipmon
586 root 96 0 3512K 2012K select 1 1:08 0.00% 0.00% sendma
686 root 96 0 2224K 1440K select 0 0:30 0.00% 0.00% proftp
603 root 8 0 1340K 824K nanslp 3 0:19 0.00% 0.00% cron
427 root 96 0 1312K 704K select 3 0:10 0.00% 0.00% syslog

blackgoat3: FreeBSD 5.3R

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
626 squid 20 0 282M 278M kserel 1 10:18 0.20% 0.20% squid <= CPUを0.2%しか食っていない
582 root 96 0 42012K 7776K select 0 0:01 0.00% 0.00% httpd
1449 service 96 0 2616K 1912K CPU1 0 0:01 0.00% 0.00% top
1007 service 96 0 6092K 2996K select 3 0:00 0.00% 0.00% sshd
598 root 96 0 5048K 4244K select 2 0:00 0.00% 0.00% snmpd
653 dnscache 96 0 32820K 32220K select 1 0:00 0.00% 0.00% dnscac
525 root 96 0 2880K 1776K select 2 0:00 0.00% 0.00% ntpd
306 root 8 0 1804K 1392K nanslp 3 0:00 0.00% 0.00% ipmon
628 root 8 0 1236K 664K nanslp 3 0:00 0.00% 0.00% svscan

ネットワーク周りのGIANTLOCKが解消されたからでは？

#!/usr/local/bin/speedy -- -b1048576
バージョンのbbs.cgiをex7に投入しましたー

bbs.cgi再開発プロジェクト４
http://qb5.2ch.net/test/read.cgi/operate/1101984763/74-75

昨日のピーク時 350投稿/min くらいで、沈没　→　DNSの強化でなおったばす
今日のピーク時 350投稿/min しらいで平和
さて明日は? SpeedyCGI フルスペック版bbs.cgi がどう動くのか

1) 軽くなって 400投稿/min でもへっちゃら
2) やっぱ意味無しで 350投稿/min で沈没
3) かえるの歌でも歌ってみる

かーえーるーのーうーたーがー♪

かーえーるーのーうーたーがっ♪

遅れて･･･
　　　　　　　　　　　聞こえて･･･
　　　　　　　　　　　　　　　　　　　　　　　　　来るよ･･･

書き込めない
早く対処しろ

お前だけだカス

>>902
お前は黙ってろ

質問だす

#!/usr/local/bin/speedy -- -b1048576
で bbs.cgiが起動され speedy_back プロセスが走り出すと思うのですが
このときの speedy_back の pid を 74745 とすると

プロセス 74745 が殺される(or自滅する)タイミングって何時ですか?

昨日は本業で疲れ果て、そのまま寝てしまいました。

さて、今週はシステム系サーバの工事。
↓
システム系サーバ工事に伴う書き込み不安定・一部サービスダウンのお知らせ[12/3]
http://qb5.2ch.net/test/read.cgi/operate/1102042361/

>>897
おおっ。bbs.cgiスレが激しく進んでいると思ったら、いよいよすか。

>>904
-rと-tのデフォルト値に依存してるですね。
http://perldoc.jp/docs/modules/CGI-SpeedyCGI-2.21/SpeedyCGI.pod

によると、
・bbs.cgiが500回実行される(-r500)
・1時間、何のリクエストも来ない(-t3600)

と、バックエンドプロセスが切り替わるようです(両方とも変更可能)

MaxRuns( -r オプション、デフォルトが500 ）判定で再execされても
古いバックエンドが kill されないように見えるということですか？

うわっ、調べてる間に詳しいレスついてた、ハズい・・・・

ex7の1プロセスあたりのCPU時間を30秒から120秒に増やしました。
(speedy_backendが500回分ずつ処理するので、1プロセス的に消費時間が増えるため)

ふんふん

つまり Speedy は時限装置が組み込まれていると、
そしてサーバは殺しに行かないようにしたと、

こういう感じ?

>>909
そういうことになります。120秒が短いなら、またのばそうかなと。
bbs.cgiには暴走癖がありますが、それは120秒制限で遅かれ早かれ死ぬはず。

でex7ですが、今のところ平和なかんじですね。
300投稿/minを超えるあたりからが、見ものか。

でも冷静に考えてごらんよ。

このまま進むと確かにそう遠くない将来(Febころ?)
tigerで 500投稿/min をこなすようになるですねぇ
なったらどうなるかというと・・・・・

道路を作れば渋滞が解消するという幻想を
抱いている方々と同じ境遇というか、、

車減らさなきゃ渋滞解消しないのに、
道を快適にすればそれ以上に車に乗る人が増えるのに、

>>911
しょうがないすね。
それはもう、「宿命」とか「業」とかのレベルかなと。

DNSサーバ構築で巻き込まれはじめ、
uma作戦以降どっぷりと漬かってからというもの、
サーバの資源不足が解消するなんて、はじめから思ってないっす。

とりあえず、きゅうり踊りだけはちょっとだけうまくなったのかもしれないけど。

いや必ずどっちかが限界に達する
それか質的にかわるか

http://mumumu.mu/mrtg/mrtg-rrd.cgi/bbqbbx/bbs.html
http://stats.2ch.net/_service/netstat-20041203.txt

このメンテ中にもbbs不調だったっすね、（カウントもけっこう多くの板でされてなかったみたい）
でも、netstatのほうは見てもあまり不調ではないっぽいが、、

>>914
dnscache止めてた = bananaサーバからの書き込みができなかったはずなので、
本当に書き込み数が減っていたはず。

oyster243を観察中。

ネットワークはじめ、全体的にとても軽くなった気がしますね。
やっぱ、ネットワーク周りのgiant lock解消が効いてるのかなと。

ｅｘ７書き込めないんだけど何とかしてよ

>>917
>>897-900

わけわかめ

撃沈させたら勝ちらしい…

ちゃんと説明してくれんと意味がわからん

>>915
そうでしたかぁー。
いや、kawase-m見る限り狼も数字動いてなかったもんで、、

>>922
狼= ex7は別の要因と思います。(bbs.cgiが違う)
BBQのalerm()な処理が入ってないんだと思う。

そうでしたか。微妙にそんな気はしたけど、、
おつかれさまですー。。

>>923
あっ
もしかして、使ってなさそうな処理をばっさり削ったのが原因かも。。。

alerm() は入っているけど、　シグナルなんとかってのはばっさり削ったのだ
はっはっは

きっとそのせいだ、、

お狐様のたたりじゃー

<br> 関係もコピペの問題なんだろうなぁ。。。

もしのソースからもう一度慎重に持ってくれば直る予感。

やはり、感でいじってるのか…

狐さんの言うことを信じるとアレだよ

FOXさーん、
bbs.cgi をいじって、return 0;を入れませんでしたか?

qb6のだけ、いじったです。
で、これを配布すればいいのかな。

return 0; も 1 も沢山入れたからわからないなぁ、

いつごろのことですか?

あっ　入れた気がする　!!

うへへぇー

間違ってくばっちった、

>>932
6時間ぐらい前だと思います。

で、Proxyチェックのところをパスするにようなっていたことが判明したので、
そこを元に戻したものを配布しておきました。

これで、BBQは再度有効になったはず。

↓またFOXか

てなわけで、たぶんBBQの問題は解決したはずです。

なるほど、「避難訓練実施中」バージョンの時ですね。>>933

了解です。
で、今後はもうBBQは止めないので、これで問題ないでしょう。

>>936
試したら、BBQ戻ってますね。
乙ですー

BBQのquery数、戻りましたね。

でも相変わらずoyster243は軽いので、
5.3Rへのバージョンアップの効果は大きいみたい。

∩( ・ω・)∩ばんじゃーい

おい！！いつになったら書き込めるようになるんだ
早く直せ糞野郎

書き込めうよ

>>942
書き込めてたらこんなとこ来ねぇよ

かつをが小学校を卒業したら、

>>943
とりあえず書き込めない板とスレを出さないと解決にならないと思われ

>>943
惜しい。もう少しでIDがEX7。

普通にサクサクと書き込めるぞ
自分の環境を晒せよ

>>944 永遠に無いと。。

川沿い2階建てアパート、築12年くらい

>>944
死ね

竪穴式住居、2DK

提案です

ex7 も read.cgi(DSO風味)やっちゃいませんかー? > root ★さん

>>952
やりますか。

んじゃ、ごそごそしてきます。

ほほーい

read.cgi@ex7 一回止めて
.so 版　構築します

しました

ex7、Apache側は設定完了。

FOXとrootは俺の肉便器

500 error になるっすね、、、

なんか間違ったかなぁ

FOXとrootは夫婦

んー、なんか変だなぁ。

[Fri Dec 03 07:10:40 2004] [error] [client むにゃ] /home/ch2ex7/public_html/test/read.cgi: /home/ch2ex7/public_html/test/read.cgi: mmap returned wrong address: wanted 0x8048000, got 0x2873b000, referer: http://ex7.2ch.net/morningcoffee/

>>958
アナルを小指で軽く触ってみるといい。マジで。

ぽーーーーーーーーーーーーーーーーーー！

何やろうとしてるの？

ちょっと、ex7のApacheの設定いじります。
dsoと同じにしてみよう。

エラー出てる(ﾟ�听)

どれが最新だか解らなくなったので
dso.2ch.net からバイナリをコピーしました　

うごいた

動いたと思う。
んー、SuExecしないといけないのか。いまいちだなぁ。

後で、もう1回設定見直してみるです。

ぽーーーーーーーーーーー！

>>966
んじゃ、もう1回SuExecなしにしてみます。

SuExecなしにした。
動いた。ということで、>>966 が備後の模様。

FOXドラクエ買った？

ワロタ

楽しそうだな
>>root▲ ★
>>FOX ★

おいFOX
VIPの機能戻せよ
飽きっぽい奴だな

そうやって一時の気紛れでチョコチョコやったり
また戻したり
蓄積という言葉を知らないと
器のデカイ大人に成れねえよ

他はどうでもいいけど戦闘力と!baseと!774!force!3は戻してほしいな

ダイエット中ですから、

次スレ立てました。
http://ex7.2ch.net/test/read.cgi/news4vip/1102087282/l50

>>974-975
今やってるのはどう見ても気まぐれじゃないって。

ｽﾏｿ、出しゃばりすぎですね。

FOX★はさすがだなあ

僕に★頂戴

そろそろ、次スレの季節か。
立ててきます。

ﾜﾛｽ

俺が代わりに立てるでー

およいずむに★をあげてください

rootさんに任せた
俺が考えたテンプレート
-----
peko作戦について語るスレです。
サーバロケーションPIEに関する話題もこちらで。
現在の主要なテーマはSpeedyCGI、mod_cgidsoの導入など。

＜関連サイト＞
レンタルサーバー maido3.com ２ちゃんねるの転送量: http://server.maido3.com/pie/
MRTGによる統計情報: http://mumumu.mu/mrtg/
２ちゃんねる/PINKちゃんねる 稼動中のサーバ一覧: http://mumumu.mu/serverlist.html

また挑戦。＠2ch掲示板
http://dso.2ch.net/myanmar/
また挑戦２。＠2ch掲示板
http://dso.2ch.net/yangon/

bbs.cgi再開発プロジェクト４
http://qb5.2ch.net/test/read.cgi/operate/1101984763/

＜運営板PINKちゃんねる関係＞
【PINKちゃんねる】新サーバ獲得会議☆3
http://qb5.2ch.net/test/read.cgi/operate/1080295660/

＜携帯電話特化型サーバ構築作戦関係＞
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part3
http://qb5.2ch.net/test/read.cgi/operate/1095146311/

＜前スレ＞
【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part15
http://qb5.2ch.net/test/read.cgi/operate/1093068260/

過去ログ一覧
　Part1 http://qb3.2ch.net/operate/kako/1052/10529/1052923573.html
　Part2 http://qb3.2ch.net/operate/kako/1062/10621/1062137886.html
　Part3 http://qb3.2ch.net/operate/kako/1068/10680/1068017802.html
　Part4 http://qb3.2ch.net/operate/kako/1074/10741/1074124767.html
　Part5 http://qb3.2ch.net/operate/kako/1076/10761/1076162131.html
　Part6 http://qb3.2ch.net/operate/kako/1076/10764/1076413123.html
　Part7 http://qb3.2ch.net/operate/kako/1076/10767/1076733846.html
　Part8 http://qb3.2ch.net/operate/kako/1078/10789/1078972549.html
　Part9 http://qb3.2ch.net/operate/kako/1080/10802/1080298357.html
　Part10 http://qb3.2ch.net/operate/kako/1082/10821/1082125059.html
　Part11 http://qb3.2ch.net/test/read.cgi/operate/1082990543/l50(なぜか未HTML化)
　Part12 http://qb5.2ch.net/test/read.cgi/operate/1084429098/
　Part13 http://qb5.2ch.net/operate/kako/1085/10856/1085678587.html
　Part14 http://qb5.2ch.net/operate/kako/1087/10876/1087666806.html

>>982
>>978

>>978
そこ、VIP…

★ほしーー

たまにはVIPもいいかと

【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part16
http://qb5.2ch.net/test/read.cgi/operate/1102087698/

>>985
どもです。

bbspink、携帯電話特化型はとりあえずはずしました。
また必要なら、自然に入るかと。

>>991　うい。

>>991

あら

1000もらい

systat -pとかsystat -vとかすると、いろいろとわかるです。

誤爆？

>>996
ですね。

>>1 が8月21日か。
このスレでの作業は、とても有意義だったなぁと。

いつもおつかれさまです。
これからもいっしょに（？）遊ばせてもらいますー

そろそろ1000か

FOXの実験には大爆笑する

( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼/ ＼


　　　　　　　　　　　　　　　　　それがＶＩＰクオリティ
　　　　　　　　　　　　　　　　　http://ex7.2ch.net/news4vip/

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。