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

**▲:/usr/local/bin/ch2 -o i686** ◆P8fXJj6wwo · 04/08/21 15:04

peko作戦について語るスレです。
サーバロケーションPIEに関する話題もこちらで。
現在の主要なテーマはpeko/cobraおよびtigerサーバが
特定条件下における突然死の原因究明です。
９月にrootさんが現地へ渡米して作業するそうです。

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

＜運営板PINKちゃんねる関係＞
【Project ama】PINKちゃんねる特化型ｻｰﾊﾞ構築作戦 Part2
http://qb5.2ch.net/test/read.cgi/operate/1082721809/l50
【PINKちゃんねる】新サーバ獲得会議☆3
http://qb5.2ch.net/test/read.cgi/operate/1080295660/l50

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

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

**root▲ ★** · 04/12/02 01:00:52

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

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

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

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

**root▲ ★** · 04/12/02 01:01:20

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

**FOX ★** · 04/12/02 01:02:38

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

**root▲ ★** · 04/12/02 01:05:02

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

**FOX ★** · 04/12/02 01:11:49

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

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

**root▲ ★** · 04/12/02 01:12:13

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)は、
該当時間、どうだったのかな。

**FOX ★** · 04/12/02 01:12:19

訂正

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

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

**root▲ ★** · 04/12/02 01:14:41

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

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

**FOX ★** · 04/12/02 01:19:34

んんん?

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

なぞだ、

**root▲ ★** · 04/12/02 01:22:57

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

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

**FOX ★** · 04/12/02 01:24:23

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

**▲ 某ソレ511** · 04/12/02 01:26:20

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

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

**root▲ ★** · 04/12/02 01:27:14

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

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

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

**root▲ ★** · 04/12/02 01:29:43

>>802
とすると、、、。

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

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

**FOX ★** · 04/12/02 01:31:42

その部分のコード

{
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;
}
}

**FOX ★** · 04/12/02 01:32:32

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

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

**root▲ ★** · 04/12/02 01:36:23

>>806
簡単です。

**FOX ★** · 04/12/02 01:37:30

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

**root▲ ★** · 04/12/02 01:39:46

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

**root▲ ★** · 04/12/02 01:45:44

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

**root▲ ★** · 04/12/02 01:46:31

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

**root▲ ★** · 04/12/02 01:46:53

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

**root▲ ★** · 04/12/02 01:48:22

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

**FOX ★** · 04/12/02 01:48:34

ですね、

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

**root▲ ★** · 04/12/02 01:49:20

すごいことになってる。
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

**動け動けウゴウゴ２ちゃんねる** · 04/12/02 01:49:43

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

**root▲ ★** · 04/12/02 01:50:21

BBSあげました。

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

**▲ 某ソレ511** · 04/12/02 01:50:43

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

**root▲ ★** · 04/12/02 01:51:45

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

**FOX ★** · 04/12/02 01:53:45

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

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

**▲ 某ソレ511** · 04/12/02 01:55:35

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

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

**FOX ★** · 04/12/02 01:56:19

ほぅほぅ

やってみよう、

**root▲ ★** · 04/12/02 01:57:36

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

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

**FOX ★** · 04/12/02 01:58:18

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

**FOX ★** · 04/12/02 01:58:58

>>823

live16,live17 りょうかいです

**root▲ ★** · 04/12/02 01:59:26

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

**root▲ ★** · 04/12/02 02:00:00

BBS止め中、、、。

**root▲ ★** · 04/12/02 02:00:17

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

**FOX ★** · 04/12/02 02:00:19

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

**FOX ★** · 04/12/02 02:00:41

>>828

I think so too.

**root▲ ★** · 04/12/02 02:00:56

>>829
了解です。

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

**root▲ ★** · 04/12/02 02:01:30

ブロックは、してるみたい。< 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

**▲ 某ソレ511** · 04/12/02 02:01:43

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

**root▲ ★** · 04/12/02 02:02:57

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

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

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

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

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

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

**FOX ★** · 04/12/02 02:06:14

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

**root▲ ★** · 04/12/02 02:06:16

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

**root▲ ★** · 04/12/02 02:06:58

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

**FOX ★** · 04/12/02 02:08:10

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

**root▲ ★** · 04/12/02 02:14:15

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

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

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

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

**FOX ★** · 04/12/02 02:15:24

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

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

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

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

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

**FOX ★** · 04/12/02 02:19:56

ぐおっ　2,400/min

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

**▲ 某ソレ511** · 04/12/02 02:22:18

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

**root▲ ★** · 04/12/02 02:24:36

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

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

ん?
計算変かな?

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

**FOX ★** · 04/12/02 02:26:27

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

**root▲ ★** · 04/12/02 02:26:47

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

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

**root▲ ★** · 04/12/02 02:28:43

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

**FOX ★** · 04/12/02 02:29:03

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

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

**▲ 某ソレ511** · 04/12/02 02:31:55

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

**root▲ ★** · 04/12/02 02:33:04

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

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

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

**FOX ★** · 04/12/02 02:33:18

げっ
そういえばそうか?

たまたまじゃないのか?

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

**FOX ★** · 04/12/02 02:34:00

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

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

**root▲ ★** · 04/12/02 02:34:04

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

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

**▲ 某ソレ511** · 04/12/02 02:35:15

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

**root▲ ★** · 04/12/02 02:36:38

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

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

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

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

しかーし

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

**root▲ ★** · 04/12/02 02:39:02

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

**FOX ★** · 04/12/02 02:39:45

PIE の?

**root▲ ★** · 04/12/02 02:41:57

>>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止めてたんで、この値そのまま信用できないところがありますけど。

**root▲ ★** · 04/12/02 02:43:52

今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

**root▲ ★** · 04/12/02 02:45:14

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なんちゃらのところがカウントアップされるようだと、
いまいちですね

**FOX ★** · 04/12/02 02:46:37

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

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

**FOX ★** · 04/12/02 02:48:11

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

**root▲ ★** · 04/12/02 02:53:31

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

**root▲ ★** · 04/12/02 02:53:53

>>865
やってみるです。

**FOX ★** · 04/12/02 03:02:56

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

**root▲ ★** · 04/12/02 03:07:09

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

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

**動け動けウゴウゴ２ちゃんねる** · 04/12/02 03:10:11

楽すみ～

**root▲ ★** · 04/12/02 03:12:42

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

>>868 おっ。

**動け動けウゴウゴ２ちゃんねる** · 04/12/02 03:18:40

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

**root▲ ★** · 04/12/02 03:21:12

ふむ。

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

**root▲ ★** · 04/12/02 03:22:41

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

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

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

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

**root▲ ★** · 04/12/02 03:29:43

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

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

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

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

**root▲ ★** · 04/12/02 03:33:57

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

**動け動けウゴウゴ２ちゃんねる** · 04/12/02 03:36:31

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

**root▲ ★** · 04/12/02 03:37:39

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

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

**動け動けウゴウゴ２ちゃんねる** · 04/12/02 03:37:53

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

**動け動けウゴウゴ２ちゃんねる** · 04/12/02 03:39:47

>>877

**動け動けウゴウゴ２ちゃんねる** · 04/12/02 03:40:42

狼なんてｲﾗﾈｰﾖ

**動け動けウゴウゴ２ちゃんねる** · 04/12/02 03:41:22

VIPER一同より

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

**WaterLineVVVF ★** · 04/12/02 03:41:32

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

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

**動け動けウゴウゴ２ちゃんねる** · 04/12/02 03:42:23

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

**▲ 某ソレ511** · 04/12/02 03:44:24

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

**root▲ ★** · 04/12/02 03:48:35

>>887
そっすね、、、。

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

**root▲ ★** · 04/12/02 03:53:17

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

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

**root▲ ★** · 04/12/02 04:10:04

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

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

**▲ 某ソレ511** · 04/12/02 04:12:25

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なのに比べると
確かに微妙にいやんかも、、
おやすみなさい。