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

oyster902、また落ちているすね。うーん。

何が起きているのか。症状はこの間と同じ。

・pingには答える
・httpdは応答しない(connection refused)
・sshはつながる、しかしログインできない

ちゃんとコンソールから調べてもらった方がよさそうなので、
今日はリブート要請をせず(コンソールのメッセージがわからなくなる)、
今夜にでも現地の中の人と別途調整することにします。

# 902はSumaの制御でシリアルポートを使っているので、リモートコンソールではないのです。

なお、Sumaストレージにはリモートログインできて、異常なく動いていることは確認しました。
いまのところ 902 側のハードウェア不良の可能性が大きいか。

> ・httpdは応答しない(connection refused)

今はConnection timed outします。ううむ。

サービスがいないポート(10)はちゃんとrefused
サービスがいるポート(80)は固まる

%telnet oyster902.peko.2ch.net 10
Trying 206.223.151.230...
telnet: connect to address 206.223.151.230: Connection refused
telnet: Unable to connect to remote host
%telnet oyster902.peko.2ch.net 80
Trying 206.223.151.230...
^C

で、>>244 のシステムエラー、そしてSuma側には異常がないことからすると、
システムディスクがつながっている、AdaptecのRAIDコントローラがいまいちな予感。

さて、これで連日、3回目のダウンなので、何らかの問題が生じたことは明らかかと。

・今日の深夜に現地の中の人と連絡をとり、状況を伝える
・システムコンソールのメッセージを見てもらう
・場合によっては入院・加療か

ちなみに902のRAIDコントローラは、Adaptec 2120Sです。
OSはFreeBSD 5.2.1/amd64。

>>244 のエラーも含め、何か情報があればここに書いていただけると。

ちょっと覗かせて頂いたものです。関係あるかは分かりませんがAdaptec 2120Sといえば・・・
http://ask.adaptec.co.jp/cgi-bin/adaptec_japan.cfg/php/enduser/std_adp.php?p_sid=RumNikoh&p_lva=&p_faqid=1215&p_created=1064535857
&p_sp=cF9zcmNoPTEmcF9ncmlkc29ydD0mcF9yb3dfY250PTEmcF9zZWFyY2hfdGV4dD0xMjE1JnBfc2VhcmNoX3R5cGU9MjpmYXFzLmZhcV
9pZCZwX3Byb2RfbHZsMT02NSZwX3Byb2RfbHZsMj1_YW55fiZwX2NhdF9sdmwxPX5hbnl_JnBfc29ydF9ieT1mYXFzLmZhcV9pZDpEJnBfcGFnZT0x&p_li=

>>250
どうもです。

シーゲートファーム問題すか。
いちおう、2台のディスク(RAID 1で運用)が最新ファーム(6)なことは前に確認しているです。

>>251 補足
渡された当日の古い dmesg。

http://mumumu.mu/oyster902/dmesg-freebsd52-i386.txt

というわけで、今日あたり対応を。

今のところはたぶん、2120Sコントローラがいまいちになったものというのがわたしの推測。
Jimさんに連絡とって、作業のスケジューリングをぼちぼちと。

Dear Mumumu,

I will take this machine to Polywell this morning if it is ok to take it offline.

Your friend,

Jim

私の返事:

Ok, please do it.

I think Suma is completely no problem, so you can bring only 902 itself to
Polywell.

-- Mumumu

というわけで、902はPolywellに入院の方向で。
こんなメール出してあるので、その筋での調査&検査入院かと。

Jim-san,

In the several days, oyster902 is encountered suddenly system downs.
And today, 902 has been down since today's evening in Japan.

We dare to suspend rebooting 902 for checking system console message.
So, if you can, please go to PIE and check system console message of
902.

I checked the details of Suma storage the day before yesterday, and
they works fine and I cannot detect any errors. So, there are no
problem on Suma.

And yesterday, I detected strange system message as seen below:

Oct 18 02:48:08 <0.2> oyster902 kernel: aac0: **Monitor** NMI ISR: NMI_MEMORY_CONTROLLER_ERROR

This means Adaptec RAID 1 controller (aac0) on board memory is wrong,
so fixing the card is needed, I think.

Anyway, please check current system console message of 902.

Yoroshiku-Onegai shimasu.

過去ログはしばらくお預けということだろうか。

>>256
英語がスラスラ書ける人ってのはカッコよく見えるんだよなァ。
rootさんかっこえぇ

>>257
ですね、、、。

過去ログが入っている外付けディスクそのものは正常なので、
本体が直れば復活かと。

>>258
痛い目になんどもなんどもあって少しずつおぼえたです。
100%現場のみ。

最期がローマ字なのは何か意味があるのだろうか・・・

Jim (02:18 AM) :
this is error right now
aac0: Command 0xfffffff8ed5990 timeout after 3184 seconds
Me (02:19 AM) :
Oh, I think my guess is correct. aac0 is Adaptec 2120S RAID controller driver name of FreeBSD.
Me (02:20 AM) :
So, I think we need to fix the wrong card.
Jim (02:21 AM) :
this just happened? how can the card become wrong after it was right for many months?
Jim (02:22 AM) :
I am going to turn oyster902 off now
Me (02:23 AM) :
Hmm... Surely, this card is correct during about 8 months.
Me (02:23 AM) :
Ok, please do it.

やはりシステムディスクを接続しているSCSIカードに問題が出た模様。
ということで 902 は入院となりました。

>>260
あいてがJimさんだから、そのへんは呼吸で。

Jim (02:34 AM) :
ok, I will go to polywell now. I will leave oyster902 there for the whole day.
Me (02:35 AM) :
Thank you for your work. Otsu-desu.

Jim (02:36 AM) :
dai jobu mata atode friend
Me (02:36 AM) :
Ok, mata atode.

ということでJimさんは902を持ってPolywellに向かいました。

これからFreeBSD 5.3R-RC1化したlive8のセットアップの続きを少しやって、ねるとするか。

障害が、はっきりして良かったですね・・・

>>265
そうすね。

しかし、ディスクはRAID 1にしてあったのに、RAIDカードに問題が出るとはなぁ。
まぁ、そういうこともあるか。

>>266
ディスクコントローラがいかれるのはディスク不良が発生する確率より
若干低いとはいえ、ありえなくはないです。
ディスクコントローラに限らずチップ内の劣化断線なんてよくある話ですから

エンタープライズ級の使われ方をしてる2chの鯖なら
どこかしら不具合を起こすのも日常茶飯事かと。

ということで、復活へと。

【実況板】 live15/16/17 鯖 Part1
http://qb5.2ch.net/test/read.cgi/operate/1097931665/

順調に進めば5.3は２５日リリース予定だそうです。

ttp://distrowatch.com/?newsid=02018#0

鯖落ちスレから転載
SMP enableなんだろーか。

---
191 名前： root▲ ★ [sage] 投稿日： 04/10/21 00:22:10 ID:???
これ(注：ex7作業)でOSがFreeBSD 5.3-RC1になりました。
さて、しばらくは live8 とともに人柱になっていただくということで。

%uname -a
FreeBSD tiger503.maido3.com 5.3-RC1 FreeBSD 5.3-RC1 #0: Tue Oct 19 23:43:06 PDT 2004 [email protected]:/usr/obj/var/src/sys/I386_TIGER_53 i386

>>270
当然、9月にPIEに行って5.3-BETA2にした時からSMP enableです。< ex7
その後突然のハングは一度も起こっていないので
(普通にkernelがpanicして落ちたことはある: betaだし)、
SMPなマシンでの不安定の原因はもう確定とみてよいでしょう。

■　新企画 Hack72 (BBQ に貯まっている串の速報)　part1
http://qb5.2ch.net/test/read.cgi/operate/1093978218/200-

ということで、生誕の儀式いきます。
以下を2ch.netのDNSに追加お願いします。

+hack72.2ch.net:206.223.151.220

>>272
done

>>273
登録確認しました。

そろそろlive8の構築ををお願いしますと、見習いさんにおつたえくださいです。

>>271
あう、そーでしたね＞enable
ここ最近は特に記憶力の減退がひどいな・・・・

新生live8、その実力は。

実はあの日のように、わくわくしていたりして。
あのときは確か、ロード・オブ・ザ・リングをやった日だっけか。

今日はどうですかね
実況的に熱そうなのはこれかなｗ
http://tv.yahoo.co.jp/bin/search?id=18999502&area=tokyo

http://oyster243.peko.2ch.net/~ch2hack72/

>>276
最初のときなんてsoftupdate disableという状態で平然だったわけですからねえ
これで瞬発力も持久力も抜群ならどうなんだろ。

ひ（りゃの意見が聞いてみたいですね

コンパイルはさくっととおりました。

【実況板】 live15/16/17 鯖 Part1
http://qb5.2ch.net/test/read.cgi/operate/1097931665/116

116 名前：root▲ ★[sage] 投稿日：04/10/22 15:08:58 ID:???
live8のbbs.cgiをperlcc版に切り替えた。
Perl5.8.5ベースになったためか、バイナリの大きさが前の半分ぐらいに。

%ls -l bbs.cgi
-rwxr-xr-x 1 ch2live8 ch2 536536 Oct 21 23:06 bbs.cgi

rootさん、こんばんはーヾ('-')ﾉ

見事にlive8避けられたな

ん〜やっぱり突発的な実況には耐えられないか・・・>live18
ほかはボチボチ分散しているようです。
んが、live8はいつもどおりだなｗ
なんでも実況Jが出来たの知らないのかな。

あとなんでcomic5とgame8が負荷が高いんだろう（＾＾；；

>283
アニメ中断の･･･

シャア専はex5だっけ？

>>284
あっなるほど（＾＾；；
ん〜まぁそのうち復活するかな。

そういえば、oyster902はいつごろ復活するんでしょう？
もうすこしかかるのかな。

283 動け動けウゴウゴ２ちゃんねる sage New! 04/10/23 18:53:37 ID:wTQO6Odm
ん〜やっぱり突発的な実況には耐えられないか・・・>live18
ほかはボチボチ分散しているようです。
んが、live8はいつもどおりだなｗ
なんでも実況Jが出来たの知らないのかな。

あとなんでcomic5とgame8が負荷が高いんだろう（＾＾；；

284 動け動けウゴウゴ２ちゃんねる sage New! 04/10/23 19:02:28 ID:ejfd13Jj
>283
アニメ中断の･･･

誤爆ｽﾏｿ

(･∀･)ﾆﾔﾆﾔ

live8よりも、ex7でいい負荷試験ができたのかも。

FreeBSD 5.3 release　キター

正式版来たんならlive16,17でも実験キボン

902ってどのような状況なんでしょか?

902ってどのような状況なんでしょか?

>>294
>>234-264

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

こういうことらしいです。>294

どもども

代わりに banana では代用できないんですかね?

>>297
PCIなFCカードがJimさんの手元にあれば意外と簡単に出来るんじゃないかのう。

Sumaとの接続はFCだで。

>>291 >>292
ようやく、か。
まずは ex7 と live8 を正式版に更新からかな。
次は live 系あたりから、順次更新していこうと。

>>297 >>298
物理的には刺さるかもしれないですが、
64bit PCIカードじゃないとI/Oが苦しい気がするので、
bananaではFCカードのパフォーマンス的に無理だと思います。

常時、相当数のアクセスがあったので。

>>299
常に二台(902,banana) を接続しておいて
902だ駄目なときはbananaが稼動っていうのじゃだめですかね?
まったく見られないよりは良いかと思いまして、

>>300
なるほど、SumaはFCだから1台にステーションを2台接続できるかもしれないですね。
FCのSCSIカードとbananaサーバ1台っていうかんじですか。

FCのカードは今の902のやつと同じもの(QLogic 2300)でいける気がします。

GENERICからoption SMPがなくなりました。
SMPを使う場合は、

make buildkernel KERNCONF=SMP
make installkernel KERNCONF=SMP

とする必要があるみたいですね。

live8でCVSup。
ex7は、、今重いからなぁ。

>>302
あ、もう書かれちゃった。
確かに、SMPがデフォルトではなくなってますね。
まあ、安全側に振ったということでしょう。

# おぐらけい、若いな。それよりゲストの若さに驚いたかも。

#　実況は実況板で

>>301
Strage共有にスイッチは不要でしたかの？
ちと不明なのでそのへんを訊いてみる。。

確かにSumaに穴は二つあるようじゃが、

>>305
穴(I/F)を入れられる場所は2つありますが、今は1つしか入ってないです。

FC-ALなので、リング状に接続すればいいんではないかと思っていたり。

あ、>>306 は「I/Fカードが今のSumaには1枚しか入ってない(今のSumaなら1枚しか要らないから)」
という意味です。

>>306
ちと Jim さんに接続の方法を聞いてみたりしてみます
週明けになると思いますが、

root ★さんも JIm さんを捕まえたら
手配しちゃってくださいー

技術検証、まぁちっとは役に立つかも計画ですが、

>>303
ためしに、GENERIC入れたら、やっぱり非SMPでしたｗ

いま、CPUひとつでSMPをbuildkernel中

>>308
了解です。
もしつかまったら、902のステータスも聞いてみてくださいです。
退院してくるなら、それがいちばんよいので。

うおっ
久しぶりにメールを見てみたら

10/21 にこんなメールが

Oyster902 is back on the rack.
It ran for 1 day at polywell with no errors.
It has had one extra fan installed. (Now 7 fans in it.)
and a new adaptec raid 1 card. lets see how it does for a few days.

Jim

>>311
お、状況再現せず、負荷による温度上昇かもと疑いファンを増設して、SCSIカードも換えたと。

さて問題です
今日は何日でしょう？

Jimさんが泣いています

>>306
ひょっとしてわっかにしたらわっかのどこかが落ちたりして欠けたらアレなんじゃ。。。。

>>311
おー

Jimさんと連絡とれました。
今日午前中にPIEに行って(現地時間)チェックしてみるとのこと。
HWに問題がなければ、今日のうちには上がるでしょう。

Me (12:42 AM) :
Ok, wakatta. I will wait for 902 is back again.
Jim (12:42 AM) :
it will be back up today.
Me (12:43 AM) :
Ok, thank you.
Jim (12:43 AM) :
dou itashi mashite

FreeBSD 219.113.242.220 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Mon Oct 25 00:14:28 JST 2004 [email protected]:/usr/obj/usr/src/sys/SMP amd64
一足お先に、5.3R導入

>>315
リングにするから、1台落ちても大丈夫なわけで。

>>317
お、はやいな。

>>318
あ、わっかといっても三角にするだけだから
どっかが落ちても経路が潰れるわけじゃないのかー

oyster901 = live8 を5.3Rに更新した。

%uname -a
FreeBSD oyster901.maido3.com 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Sun Oct 24 09:22:11 PDT 2004 [email protected]:/usr/obj/usr/src/sys/AMD64_COBRA_53 amd64

902ｸﾙ━━━━━(ﾟ∀ﾟ)━━━━━!?

tiger503 = ex7 も更新した。
他のサーバの更新は明日以降。

FreeBSD tiger503.maido3.com 5.3-RELEASE FreeBSD 5.3-RELEASE #1: Sun Oct 24 11:01:59 PDT 2004 [email protected]:/usr/obj/var/src/sys/I386_TIGER_53 i386

902 動いているようで、
bananaを一台追加予定、
だめだったら tiger を考えていたり、

>>324

それは掲示板に使ってよいものですか？
memoriesのバックアップ用？

memoriesのバックアップ用　でーす

どのような方法があるのかわからないけど
902 が落ちたときに補完になれば、

>>325
仮に後者目的に使うのであればセカンダリ＝バックアップでしょーな。
ただbananaでは少々つらいかも。
>>299の懸念を902+bananaコンビのデュプレックスだけでは払拭でき無そうですし。
peko2台(1台は902)ではオーバースペックだろうし。
# 将来的には必要かもしれませんがね

>>326
方法としてはc={c1/c2}同様にDNSラウンドロビンという手でいくのが妥当かと思います。
ただしこの方法だと902が落ちたときに相方のbananaに負荷が集中して結局落ちる可能性がありえます。
そんなんではバックアップの意味が無いわけで。。。。

他にいい方法ないでしょうかねぇ

902、RAID 1で構成したシステムディスクが片肺飛行状態になっているかも。

21日からネットワークに接続されていない状態で動いていた模様。
↓1行目はこないだのエラー。

Oct 18 02:48:08 <0.2> oyster902 kernel: aac0: **Monitor** NMI ISR: NMI_MEMORY_CONTROLLER_ERROR
Oct 21 03:14:03 <0.2> oyster902 kernel: aac0: **Monitor** SCSI bus reset issued on channel 0
Oct 21 03:14:30 <0.2> oyster902 kernel: aac0: **Monitor** <...repeats 1 more times>
Oct 21 03:14:30 <0.2> oyster902 kernel: aac0: **Monitor** Drive 0:0:0 online on container 0:
Oct 21 03:14:51 <0.2> oyster902 kernel: aac0: **Monitor** SCSI bus reset issued on channel 0
Oct 24 00:45:30 <0.2> oyster902 kernel: aac0: **Monitor** <...repeats 4 more times>
Oct 24 00:45:32 <0.2> oyster902 kernel: aac0: **Monitor** Drive 0:1:0 returning error
Oct 24 00:45:32 <0.2> oyster902 kernel: aac0: **Monitor** SCSI bus reset issued on channel 0
Oct 24 00:45:32 <0.2> oyster902 kernel: aac0: **Monitor** ID(0:01:0) - Cmd[0x28] failed (retries exhausted)
Oct 24 00:45:37 <0.2> oyster902 kernel: aac0: **Monitor** ID(0:01:0) - Cmd[0x2a] failed (retries exhausted)
Oct 24 00:45:37 <0.2> oyster902 kernel: aac0: **Monitor** Alarm Adapter Event -- turning Alarm On!
Oct 24 00:45:37 <0.2> oyster902 kernel: aac0: **Monitor** Mirror Container 0 Drive 0:1:0 Failure
Oct 24 00:45:37 <0.2> oyster902 kernel: aac0: **Monitor** <...repeats 2 more times>
Oct 24 00:45:37 <0.2> oyster902 kernel: aac0: **Monitor** Drive 0:0:0 online on container 0:
Oct 24 00:45:47 <0.2> oyster902 kernel: aac0: **Monitor** Mirror Failover Container 0 no failover assigned

>>329
5.3にあげるつもりがあるのでしたら>>324のときに再構築したほうがいいかもですね。

httpdのスロット数は増やしたいけど、
bbs.cgiの起動数は例えば同時に100個とかまでにしたい、とかいうのって、
設定で何とかならないんだろか。

>>331
mod_cgidsoが実装されれば容易に調整できそうなものですが。

live8が上がっていたのでhttpdの起動数にリミッターを入れました。(一時的に1024に上げていた)

live8 512
ex7 384

に設定。

また風邪を引いてしまったらしく症状がひどいため、今日はたぶんあまり見られないです。すまぬ。

>>333
たぶんどころかみちゃだめです。鯖のお守りより自分のお守りをしてください。。。

とりあえず24時間寝ることを薦めます

>>333
ぶっちゃけ、一週間くらい2ちゃんが落ちても、そんなに困る人は居ない。
けど、あんだが一週間寝込んだら困る人、居るでしょ？奥さんとか。ご自愛下され。

>>333
ゆっくり休んでくださいー

(ry

RC1に逆戻り。

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/conf/newvers.sh.diff?r1=1.62.2.15.2.2&r2=1.62.2.15.2.3

　　　　　　　　　　　 ＼　　　ｼｮﾎﾞｰﾝ　　　　 ／（　＾∀＾）ｹﾞﾗｹﾞﾗ
ｼｮﾎﾞｰﾝ　　　　　　　 　＼　　(´･ω･`) 　 ／
　　(´･ω･`)　　　　　　　 ＼∧∧∧∧／∀｀)＝◯＜´･ω･`＞◯＝（・
　　( つ旦O　　　　　　　　＜　な　シ　＞　　　　　　(　　　)ｼｮﾎﾞｰﾝ
　　と＿)_)　 　　 　 　 　　＜　　　　ｮ　＞ 　　　　　　∪∪
──────────＜　悪　ボ　＞───────────
　 　 　 |　　|／(　´_ゝ`)＼＜　　　│　＞　　　　( ´･ω･`)ﾌｰ
　 　 　 |　　|.　　　∩∩　 ＜　寒　ン　＞　　　／　　　人
　 　 　 |ｼｮﾎﾞｰﾝ￣￣￣￣／∨∨∨∨＼　　/　＼ ＼⌒i
　 　(´･ω･`)　　　　　　／２人でｼｮﾎﾞｰﾝ ＼ |　　／＼ ￣））
　 　 (∩∩)───　／（´･ω･`)人(´･ω･`＼／　　／|￣|
　 ／|￣￣| ｶﾀｶﾀ ／　（ 　∩∩）　（∩∩　　）＼／　 ゝ＿_）

ex7を実験台に、KeepAliveありの設定を実験中。
同じ人がリロードするのには、このほうが負荷が低いかもしれないので。

HTTP/1.1をまともに実装しているクライアントからは、
KeepAliveONのほうが、かける負荷はずっと少なくなります。
connect要求300回が、3回で済むようになる上、
apache側は、同一connectionでのリクエストは
同じプロセスそのまま再利用して処理するので。

で、クライアント側の待ち時間も、数倍違いが出ます(巡回時)。
正直なところ、個人的には全鯖KeepAliveON(タイムアウトは短くても)にして欲しいところです。

問題は、connectしたまま放置するクライアントの存在ですね。
IEは、force-no-varyに引っかかるので、必ず切断されますが
昔、比較的メジャーなクライアントの実装で
「リクエスト毎にHTTP/1.1コネクションを作成し、そのまま」
というのがあった気がします。

>>340
そうなんですよね。そんな気がして。
live8での実験の最中にKeepAliveをOffにしたわけですが、
少なくとも通常サーバでは、Onのほうがいい気がしたのです。

今はこうですね。このへんのパラメータチューンもしたほうがよさそう。
どうやるのがいいのかな。

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 10

ただ、携帯系では切ったほうがいいかも。
こんなかんじでいいんだっけか。

BrowserMatch "DoCoMo" nokeepalive
BrowserMatch "UP.Browser" nokeepalive
BrowserMatch "J-PHONE" nokeepalive
BrowserMatch "DDIPOCKET" nokeepalive

live8もKeepAliveありにしてみた。

>>341
http://httpd.apache.org/docs-2.0/mod/mod_setenvif.html#browsermatch
BrowserMatch regex [!]env-variable[=value] [[!]env-variable[=value]] ...

書式がかなり違うような（苦笑）
ひとまず、携帯機種には環境変数を設定して、Header を出力すると良いのかな？

BrowserMatch "DoCoMo|UP\.Browser|J-PHONE|DDIPOCKET" Mobile
Header onsuccess set Keep-Alive off Mobile

かなり自信なし（苦笑）
http://httpd.apache.org/docs-2.0/mod/mod_headers.html#header

>>343
あ、クライアントに Keep-Alive: off の返事をするだけはダメですよねm(_ _)m
物理的に切断を指示するのは、VirtualHost ごとなのでかなり難解かも、、、> Keepalive ディレクティブ

なんかスケジュールが巻き戻ってリリース日がかなり伸びてますねぇ

FreeBSD 5.3 Press Release 5 Nov 2004

>>331 続報

さきほどとりあえず ex7 と live8 で、

RLimitNPROC 200

にしてみた。もっと少なくてもいいのかな。

read.cgiにもこの制限当たってきちゃうわけだけど、
まぁ200なら、今のところこんなもんじゃないかなぁと。

夜遅くに乙です。

出先から帰宅。

ex7、天皇賞の後重かった？

馬は見ていないからわからないですが、この辺にはなにもありません。

重い重い重い重い重い重い重い×25＠運用情報
http://qb5.2ch.net/test/read.cgi/operate/1093497512/

ex7が重い重い重い重い重い重い重いtiger503
http://qb5.2ch.net/test/read.cgi/operate/1096837151/

>>350
どうもです。

システム観察的には、LA=80ぐらいになったみたい。 (http://ch2.ath.cx/load/ex7.html)

しかし、内部でとってるApacheのステータスログを見る限り、
システムはまだ余裕たっぷりだったように見えます。
なかなか、たのもしいなと。

http://sv2ch.baila6.jp/server.cgi?server=ex7.2ch.net

負荷量的には昨日のうｐ祭り @ news4vipの方が多かったと(頂上は同じぐらいか)。
つまり、女神降臨 ＞ 天皇賞 だったということかぁ。

でも、両方同時には来ないでほしいなと。

>>352
とりあえず、当面の目標は5.3Rで片肺状態の解消、でしょうなぁ

今度は巻き戻されないことを祈りませう　南無南無

＞でも、両方同時には来ないでほしいなと。
心情的には理解できますけど、
確率的に考えてもそこは想定しない。もしあったら、潔く落ちましょう。という割り切りでいいんじゃないでしょうか？

気を楽にー、気を楽にー♪

死亡確定 @ newsplusは200超えかぁ。
http://sv2ch.baila6.jp/server.cgi?server=news19.2ch.net

>>354
どもです。気楽にやってるですよ。
両方来たらキタで、それもまたイベントかと。

ようやく腰下(OS)が安定になりそう = 気兼ねなく遊べそうになって、
つまり上モノ(システムやApacheの調整とか板セッティングとか)を遠慮なくいろいろといじれそうで、
相当わくわくしていたりして。

＞両方来たらキタで、それもまたイベントかと。
さすがに慣れているというか……。(;^ ^
実社会でもそうですけど、これくらいポジティブシンキングできれば、ストレスも減らせて楽しんで活動できます。


＞ようやく腰下(OS)が安定になりそう = 気兼ねなく遊べそうになって、(ry
ネットワーク周りはPIE移転プロジェクトでほぼ解決して、今度5.3RによってOSが安定して、、、
下位のレイヤーが固まってきていますね。しばらくいじって来なかったところに、メスを入れられそうですね。

地雷が埋っていませんように(‐人‐)

それ以前に
女神スレって削除対象でないの？( ;´Д｀)

うむbbspinkでやるべきだね

>>358

われわれが発掘できれば、立派な社会貢献かと。

live8/ex7を5.3-RC2に更新。

%uname -a
FreeBSD oyster901.maido3.com 5.3-RC2 FreeBSD 5.3-RC2 #1: Sun Oct 31 09:27:19 PST 2004 [email protected]:/usr/obj/usr/src/sys/AMD64_COBRA_53 amd64

というわけでこれの効果が出ると、うれしいなと。

Merge tcp_output:1.104 from HEAD to RELENG_5_3:

date: 2004/10/30 12:02:50; author: rwatson; state: Exp; lines: +2 -2
Correct a bug in TCP SACK that could result in wedging of the TCP stack
under high load: only set function state to loop and continuing sending
if there is no data left to send.

RELENG_5_3 candidate.

Feet provided: Peter Losher <Peter underscore Losher at isc dot org>
Diagnosed by: Aniel Hartmeier <daniel at benzedrine dot cx>
Submitted by: mohan <mohans at yahoo-inc dot com>

Approved by:re (kensmith)

AMD64ではlibcも更新した。
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/amd64/sys/brk.S

Revision 1.12.8.1 / (download) - annotate - [select for diffs], Sat Oct 30 00:08:46 2004 UTC (2 days, 7 hours ago) by peter
Branch: RELENG_5_3
CVS Tags: RELENG_5_3_0_RELEASE
Changes since 1.12: +1 -0 lines
Diff to previous 1.12 (colored) next main 1.13 (colored)

MFC: rev 1.13 fix brk(3) on amd64
(I believe there will be a tag slide for this)

Approved by: re (kensmith)
(中略)
Revision 1.13 / (download) - annotate - [select for diffs], Wed Oct 27 17:11:43 2004 UTC (4 days, 14 hours ago) by peter
Branch: MAIN
CVS Tags: HEAD
Changes since 1.12: +1 -0 lines
Diff to previous 1.12 (colored)

Fix brk(3). The stack was unbalanced when we jumped to cerror. Oops!
This causes nasty things like SEGV or a cpu spin when we return.

Submitted by: "James R. Van Artsalen" <[email protected]>

root氏お疲れ様です。お体のほうはもう大丈夫なのかな？

>>364
ぼちぼちすね。

今週末からまた1週間ばかり※国方面に出張です。
この後ちょっぴり修○すると、無事に50,000ポイントということで。

# ex7はバージョンアップ早々いきなり負荷試験だったようで。

>>365
※イ＊ージでつか＞５万

そーなると5.3Rへのupは帰国後あるいは直前ぐらい？

RLimitNPROC を 200 から 150 にしてみた。< live8, ex7
超高負荷時に瀕死になる比率が下がるといいなと。

きたのかな。

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/conf/newvers.sh.diff?r1=1.62.2.15.2.4&r2=1.62.2.15.2.5

===================================================================
RCS file: /usr/local/www/cvsroot/FreeBSD/src/sys/conf/newvers.sh,v
retrieving revision 1.62.2.15.2.4
retrieving revision 1.62.2.15.2.5
diff -u -p -r1.62.2.15.2.4 -r1.62.2.15.2.5
--- src/sys/conf/newvers.sh2004/10/30 22:07:061.62.2.15.2.4
+++ src/sys/conf/newvers.sh2004/11/04 18:51:301.62.2.15.2.5
@@ -28,11 +28,11 @@
# SUCH DAMAGE.
#
#@(#)newvers.sh8.1 (Berkeley) 4/20/94
-# $FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/conf/newvers.sh,v 1.62.2.15.2.4 2004/10/30 22:07:06 kensmith Exp $
+# $FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/conf/newvers.sh,v 1.62.2.15.2.5 2004/11/04 18:51:30 scottl Exp $

TYPE="FreeBSD"
REVISION="5.3"
-BRANCH="RC2"
+BRANCH="RELEASE"
RELEASE="${REVISION}-${BRANCH}"
VERSION="${TYPE} ${RELEASE}"

reicha.netの#FreeBSDによると来たらしい。

live8とex7で、make buildworldとmake buildkernelぐらいしておくかな。

http://lists.freebsd.org/pipermail/freebsd-announce/2004-November/000964.html
━（ﾟ∀ﾟ）━（ ﾟ∀）━（ 　ﾟ）━（ 　）━（ 　）━（ﾟ 　）━（∀ﾟ ）━（ﾟ∀ﾟ）━━

>>371
お、遂に来ましたか。

ｵｰﾌﾟﾆｬ(ﾟ∀ﾟ)!!

>>371
では早速ex7とlive8を人柱にしてみませう

live8/ex7 バージョンアップ完了。
これで問題なければ、他のサーバにも徐々にってかんじで。

live8
%uname -a
FreeBSD oyster901.maido3.com 5.3-RELEASE FreeBSD 5.3-RELEASE #2: Thu Nov 4 21:52:19 PST 2004 [email protected]:/usr/obj/usr/src/sys/AMD64_COBRA_53 amd64

ex7
%uname -a
FreeBSD tiger503.maido3.com 5.3-RELEASE FreeBSD 5.3-RELEASE #3: Thu Nov 4 21:51:36 PST 2004 [email protected]:/usr/obj/var/src/sys/I386_TIGER_53 i386

今週末ぐらいまで問題発生しなければぼちぼちいけますかね

(ただし見習いさんあたりの号令次第で早まるかも知れんけど)

ごーれー　ごれごれごれー♪

早まりましたな。

何か「どーん」と来ると、仮死状態になるですね。< live8
こんなメッセージとともに。

ex7でも前に起きた(西部警察の時)し。
5.3-BETA2にして以降出ているので、、基本的に同じ癖を持っているみたい。

Limiting icmp unreach response from 667 to 200 packets/sec
Limiting icmp unreach response from 430 to 200 packets/sec
Limiting icmp unreach response from 307 to 200 packets/sec
Limiting icmp unreach response from 485 to 200 packets/sec
Limiting icmp unreach response from 237 to 200 packets/sec
Limiting icmp unreach response from 804 to 200 packets/sec
Limiting icmp unreach response from 667 to 200 packets/sec
Limiting icmp unreach response from 483 to 200 packets/sec
Limiting icmp unreach response from 249 to 200 packets/sec
Limiting icmp unreach response from 228 to 200 packets/sec
Limiting icmp unreach response from 236 to 200 packets/sec
Limiting icmp unreach response from 655 to 200 packets/sec
Limiting icmp unreach response from 1198 to 200 packets/sec

うーん。

2004/11/08 21:30:01 LA= 9:30PM up 1 day, 7:03, 0 users, load averages: 2.67, 2.73, 2.18
2004/11/08 21:40:00 LA= 9:40PM up 1 day, 7:13, 0 users, load averages: 54.95, 69.39, 37.19
2004/11/08 22:00:01 LA=10:00PM up 1 day, 7:33, 0 users, load averages: 1.12, 38.73, 58.44
2004/11/08 22:10:00 LA=10:10PM up 1 day, 7:43, 0 users, load averages: 0.93, 5.89, 29.24
2004/11/08 22:20:01 LA=10:20PM up 1 day, 7:53, 0 users, load averages: 0.61, 1.34, 14.70
2004/11/08 22:30:01 LA=10:30PM up 1 day, 8:03, 0 users, load averages: 8.22, 3.99, 8.94
2004/11/08 23:00:01 LA=11:00PM up 1 day, 8:33, 0 users, load averages: 662.45, 887.33, 840.68
2004/11/08 23:10:01 LA=11:10PM up 1 day, 8:43, 0 users, load averages: 0.66, 125.81, 423.08
2004/11/08 23:20:01 LA=11:20PM up 1 day, 8:53, 0 users, load averages: 0.39, 17.82, 211.69
2004/11/08 23:30:00 LA=11:30PM up 1 day, 9:03, 0 users, load averages: 2.36, 3.58, 104.58
2004/11/08 23:40:01 LA=11:40PM up 1 day, 9:13, 0 users, load averages: 2.52, 2.13, 52.17
2004/11/08 23:50:00 LA=11:50PM up 1 day, 9:23, 0 users, load averages: 0.48, 0.89, 26.29

LAがすごい勢いで上がる(600を超える)
システムが重くなり、無反応になる
そのまま数分〜10分ぐらい、戻ってこない

という状況になりますね。

ちゃんと、

maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).

と出ているので、プロセス数のリミッター(150)は、効いているはずだと思うんだけど。

>>381
live18,飛んでますがね・・・・

live18ってtigerでもcobraでもないけど

5.3Beta2・releaseとbeta1のカーネルのdiffとってみると原因がわかるかもしれないっすね

そもそもカーネルなのかあやしいけど

>>384
んー、5.2.1Rの時はこういう落ち方はなかったような。

httpdの数を減らすというのももちろん手だけど、ちょっといまいちかもなぁ。
でも、やってみるかも。

live8の設定を変えてみた。
最初から用意するhttpdを増やして、最大数を減らす方向で。

<IfModule prefork.c>
StartServers 256
MinSpareServers 5
MaxSpareServers 256
ServerLimit 1536
MaxClients 1536
MaxRequestsPerChild 1000000
</IfModule>

<IfModule prefork.c>
StartServers 512
MinSpareServers 5
MaxSpareServers 512
ServerLimit 768
MaxClients 768
MaxRequestsPerChild 1000000
</IfModule>

ex7も >>386 と同じ設定にした。

以前あった「最初からたくさん待たせたほうがいい」を参考に、
両サーバとも再度設定変更。

# 今いいともに結構きてるみたい。

<IfModule prefork.c>
StartServers 768
MinSpareServers 5
MaxSpareServers 768
ServerLimit 768
MaxClients 768
MaxRequestsPerChild 1000000
</IfModule>

>>387
競馬板だけど、readするのが少しばかり、重たくなりましたねぇ・・・

>>389
うーむ、今の込み具合なら重くなることはないはずなんだけど、、、。
(Apacheのスロットは十分あいているから)

________K_K_______K____._______KK____K___KK________K______K_____
_KK__KKC______KC_____K_K____KK________C_K.K_K._____K_______._KK_
_____________KK.K_.WW_K__W______C__CK__________K___K____W____K__
_KW____K___W___._W__K_K__.___K_K_____K__K___.___KK__________KKKK
___K__K___C_____KK__W__.KK__K______K_____K_____K____K_W.________
_K__K____K___._K__K___K.______KKW__W____K____C_____K____________
_K_____K__________.__K_______K___K_____K_______WW_______KKK____K
__WK________K_WK_.______________CK__W_W______K__W__K________K.__
__K__K_K__K__K________K.__K_______K__._____KW______________K__K_
.________KW__K.W__W_K______K_________K_KKK___W__K__________.____
___K___KK__K___K_K__K_WKK__W_KK___K_K_____K____K______K_._K__K_K
__________K_______K____K______KKC_______._K_K_WK_____._K______K_

突然のLA上昇がOSの問題ではなく、apacheのKeepAliveの設定変更によるという可能性を探ると
考えられるのは、多数のread.cgiがpipeliedで呼び出されているのかもしれないですね。

通常の静的なコンテンツならば、pipelinedでもリクエスト順に１つずつ処理されるはずですが
cgi呼び出しを含む場合、apacheの仕組みとして
どんどん(forkしながら)子プロセスを同時実行して結果を受け取り、
返信する時にリクエスト順に返す、みたいになってるかもしれません(知りませんが)。
もしそうなら、100件のread.cgi呼び出しを含むリクエストが来た時
一瞬のうちに100個のプロセスがアクティブになってしまうので。

REQUEST_URIに.cgiが含まれるものは、NoKeepAliveにしたほうがいいかもしれないです。

携帯から。
>>391
ということは、

<Files ＊.cgi>
なんたら
KeepAlive off
</Files>

のほうがいいと？

よく知らないけど
SetEnvIf Request_URI *\.cgi* NoKeepAlive
みたいな書き方が出来たような。

それと、「read.cgiを多数呼び出すクライアント」として
先読みツールなどの他に、古くからの専用ブラウザで
read.cgiのrawモードを使う(使える)ものが考えられます。

>>391
状況証拠から考えて、ありうるかも。
機を見て、>>393 な設定を入れてみるか。

で、21:40ごろに「ぐわっ」と来た時は、スロットが満杯になって
それ以上の上昇が抑えられた模様。

どっかにも書いたけど、昨日 21:45 の状態。
で、cgi は NoKeepAlive すると、Kが減る可能性があると。

KKCKKKKKKKKKKCKKKKKKCKKKKKKKKCKKKKKKWCKKKKKKKCKKKWKCKKKKKKKKWKKK
KKKKKKKKKKKWKKKKCKKKKWKKKCKKKKKKKKKKKKKKKCCKKKKKKKKCKWKKKKKKKKKK
KKKKKWKKKCKKKKCCKCKWKKKKKKKKKCKKKWKKKKCCKKKKKKKWKKKKCKCKKKWKCKCK
KCKKKKKWKKKKKKCKKKKKKKKKKKKKKKKKWKKKKWKCCKKKKKKKKKCKKKKKKKKKKKKC
KKKWKKKCKKKKWKKWKKKWKKKKWKCKKCKKKKKCKKKKKKWCKKKKKKCKKKKCKKKKKWKK
KKKKKKCKKKKKKKCKKKKKKKKKCKKKKKKKKKKKCKKKKKKKKKKKKKKKKKKKKKKWKKKK
KKKKCKKKKKWKKKKKKCKKKKKKKKKKKKCKKKKKKCKWKKCCKKCKCKCKCKKKKWKKKKWK
KKKKKKKKKKKKKKKKKKWKKKKKKKKCKKKKCKCKKKKKKKKKKKKKKKKKKKCKKKKKKKKK
CCKKKKKKKCKKKKKKCKWKKKKKKWKKKKKWKKKCKKKKCKKKKKKKKKKCWKKKKCKKKKKK
KKCCKKKKKKKCCKWKKKKKKCKKCCKWKKKWKKKKKKKKKKKKKKKKKKKCWCKKCKKKKKCK
CWKKKKKKKKKKCKKWCKKKKKKKWKKCKKKKKKKCKKKKKKKKKKKKKKKCKKKKKKKKCKCK
KKKKKKKKKKKKWCKKCWKKWKKCKKKKKKWWKKKKKKKKKKKKKWKKCCKCKKKKKCWCKKCK

live8 と ex7 にまずは以下を入れてみた。
手で telnet すると、ちゃんと read.cgi の時はセッションが切れているみたい。

#
# Thank you for http://qb5.2ch.net/test/read.cgi/operate/1093068260/391-393
#
SetEnvIf Request_URI ^/test/bbs\.cgi nokeepalive
SetEnvIf Request_URI ^/test/read\.cgi nokeepalive

subbbs.cgi も追加してみた。

#
# Thank you for http://qb5.2ch.net/test/read.cgi/operate/1093068260/391-393
#
SetEnvIf Request_URI ^/test/bbs\.cgi nokeepalive
SetEnvIf Request_URI ^/test/subbbs\.cgi nokeepalive
SetEnvIf Request_URI ^/test/read\.cgi nokeepalive

しかし、全体に21:40ぐらいに段差があるのは、そういうことだったのか。

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

カーネル、ユーザランドとも無事に5.3Rに上げて、リブートテストも通り、
bumpedになったportsを更新して、再度リブートすると、、、
立ち上がってきません。< c-docomo4

謎だ、、、。

とりあえず、リブート要請してみるか。

リブートしてもらったところ、問題なく上がってきました。

チェック後、再度リブートテストを行う予定、、、。

再度リブートテストしました。今度は無事にブートアップ。
システムも異常なしの模様。

cobra2244 = c-docomo4 は FreeBSD 5.3R になりました。

今回の方法を参考に手順を整理できそうなので、
この方法で他のCobra/Tigerサーバのバージョンアップを順次実施する予定。

5.2.1R → 5.3R へのバージョンアップ手順

0) Apacheの停止(外からのアクセスを止める)
1) rm -rf /usr/obj /usr/ports
2) mv /usr/src /usr/src521 # 安全のため/usr/srcは一時的に残す
3) live8 から持ってきた作成済みの /usr/src /usr/ports /usr/obj を展開
　これにより /usr/src/standard-supfile も置き換わる
4) make buildkernel KERNCONF=携帯サーバ用カーネル
5) make installkernel KERNCONF=携帯サーバ用カーネル
　※4) 5)は通常マシンの場合、通常用カーネルを指定
6) /etc/sysctl.conf /boot/loader.conf を 5.3R 用に調整
　(基本的にlive8のを持ってくればよいが、携帯用サーバではccdを使っているのでその設定を直す)
7) リブート
8) ブートアップ確認後、dmesg をチェック、保存
9) cd /usr/src/usr.sbin/mergemaster; make -m /usr/src/share/mk all install
10) mergemaster -p
11) make installworld
12) mv /etc/rc.d /etc/rc.d.521; mkdir /etc/rc.d
13) mergemaster -i
　/etc/passwd /etc/group /etc/aliases 等をはじめとするいくつかのファイルはmergemasterで
　対話的に調整する必要あり
14) リブート
15) ブートアップ確認後 rm -rf /etc/rc.d.521 /usr/src521
16) libm 等がバージョンアップしたことによる、ports の更新
　# これがめんどくさい

portsの消し方

c-docomo4では以下の手順が必要であった

pkg_delete analog-5.32_1,1
pkg_delete cvsup-without-gui-16.1h
pkg_delete gd-2.0.15_1,1
pkg_delete help2man-1.33.1
pkg_delete p5-gettext-1.01_4
pkg_delete gmake-3.80_2
pkg_delete bison-1.75_2
pkg_delete wget-devel-1.9.1_1
pkg_delete php4-extensions-1.0
pkg_delete php4-gettext-4.3.8_2
pkg_delete gettext-0.13.1_1

pkg_delete pear-APC-2.0.4 pear-PEAR-1.3.1 pear-XML_RPC-1.1.0 pear-Console_Getopt-1.2 pear-Archive_Tar-1.2 php4-pear-4.3.8_2 php4-zlib-4.3.8_2 pecl-zip-1.0 php4-xml-4.3.8_2 php4-tokenizer-4.3.8_2 php4-sysvshm-4.3.8_2 php4-sysvsem-4.3.8_2 php4-sysvmsg-4.3.8_2 php4-shmop-4.3.8_2 php4-session-4.3.8_2 php4-readline-4.3.8_2 php4-posix-4.3.8_2 php4-pcre-4.3.8_2 php4-overload-4.3.8_2 php4-openssl-4.3.8_2 php4-mysql-4.3.8_2 php4-mbstring-4.3.8_2 php4-iconv-4.3.8_2 php4-gd-4.3.8_2 php4-ftp-4.3.8_2 pecl-fileinfo-0.2 php4-dba-4.3.8_2 php4-curl-4.3.8_2 php4-ctype-4.3.8_2 php4-bz2-4.3.8_2 php4-bcmath-4.3.8_2 php4-4.3.8_2

pkg_delete apache-2.0.50_3
pkg_delete mysql-client-4.0.18_1
pkg_delete net-snmp-5.1.1_1

pkg_delete png-1.2.5_2
pkg_delete squid-2.5.6_6

pkg_delete t1lib-5.0.1,1

pkg_delete automake-1.5_2,1

pkg_delete autoconf-2.53_3
pkg_delete autoconf-2.59_1
pkg_delete autoconf-2.13.000227_5
pkg_delete autoconf-2.53_1
pkg_delete autoconf-2.57_1
pkg_delete p5-Net-DNS-0.42
pkg_delete p5-Digest-HMAC-1.01
pkg_delete p5-Digest-SHA1-2.06
pkg_delete p5-libwww-5.75
pkg_delete p5-Net-1.17,1
pkg_delete p5-HTML-Parser-3.34
pkg_delete p5-HTML-Tagset-3.03
pkg_delete p5-URI-1.27
pkg_delete p5-Authen-SASL-2.06
pkg_delete p5-MIME-Base64-2.21
pkg_delete p5-Digest-1.02
pkg_delete p5-Digest-MD5-2.30

pkg_delete perl-5.6.1_15

pkg_delete jpeg-6b_1
pkg_delete freetype2-2.1.5_1

pkg_delete libiconv-1.9.1_3
pkg_delete expat-1.95.7

○ports の再導入

pkg_add -r perl

ここで /etc/make.conf を修正 (Perl のバージョンが上がったため)

pkg_add -r cvsup-without-gui
pkg_add -r p5-Digest-MD5
pkg_add -r p5-libwww
pkg_add -r p5-Net-DNS
pkg_add -r analog
pkg_add -r wget-devel

○大物パッケージをportsから入れ直し

net-snmp入れ直し

apache入れ直し
php4入れ直し
php4-extensions入れ直し
pear-APC入れ直し

17) 以上終了後、最終リブートテスト
18) ブートアップ確認後、Apache の自動起動を復活(/etc/rc.conf)

以上。
これだと、1日に1台〜2台ぐらいってかんじかなぁ。

こっちは夜の10時をまわりました。
本日はここまで、、、。

手順に問題とかある場合、指摘おながいします。

んで、スタンドアロンなマシンをバージョンアップする場合は、

1) rm -rf /usr/obj /usr/ports
2) mv /usr/src /usr/src521 # 安全のため/usr/srcは一時的に残す
3) live8 から持ってきた作成済みの /usr/src /usr/ports /usr/obj を展開

が、

standard-supfile の RELENG_5_2 を RELENG_5_3 に更新
make update
make -j 適当な数字 buildworld
make -j 適当な数字 buildkernel

てな感じになるです。

>>405
pkg_deleteの山がすごすぎですなあ・・・
apt for rpmみたいに依存で一気にremoveできるといいんですけどねぇ

今回はlibcの更新があるから仕方なさそうですが・・・

消したいのをリストアップして -f 付けて消すとか言って混乱させてみるペスト。

うひゃ〜　これ全部お一人でやるんですか・・・がむばってください
温かいお茶用意して待っとります。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　かしこ

お手伝いできることあればやりますよー

>>407
依存関係はそれなりなツール使えばたぶんいけると思うのですが、
今回は手でやってみたと。

で、libcはバージョン上がってないはず(上がってたらもっと大変)。

>>408
それでもたぶん問題ないような気がしますが、
何かあった時に困るし、今後中の人が増えたりした時に
情報共有するの大変だし。

だから、普通にコンパイルすれば入るものでも、
できるだけports/packages使うようにしていたり。

ということで概ね問題なさそうなので、
今度は live16 live17 あたりをやってみようかと。

>>410
おぉ、

残りのc系サーバとか、とか。

>>412

>>401-404に書いてある手順通りでいいんですよね。

>>401の3)はlive8のアクセス権ないので、それ以降は大丈夫なはずです。

/usr/src/* /usr/obj/* /usr/ports/*
/etc/make.conf /etc/sysctl.conf /boot/loader.conf とかは
c-docomo4 から持ってくればいけるはずと。

ports / packages のバージョンとかは、若干違うかもと。

c-au / c-others 系もたぶんやったほうがいいと。

で、c-docomo の代表をバージョンアップする間は、
DoCoMoの携帯からはc系を利用できなくなると。
これはauやothersをやるときも同じりくつで。

で、自分的には、pkg_delete するところを shell script にでもしとこうかと。

そっか、c-docomo4から持ってくればよいのね。

http://pcweb.mycom.co.jp/news/2004/11/10/007.html
2chには関係ないかもしれませんが.....


ってスレ違いですね 失礼しました

>ISC
> BIND (all versions) are not affected by this vulnerability.
だから心配するな。
dnscacheについてまだ書かれていないけど、ちら見した感じだと平気そう。

libm.soとかとリンクしているportsをリストアップする奴。
前スレでも話題になったかもしれないけど。
http://www.maxlor.com/freebsd/files/findlibusers.py

portupgrade -PP -arとかするよりは無駄が無いと思う。

>>411
すいません、たしかにかわっていなかったっすね＞libc

a

AP #3 (PHY# 7) failed!
panic y/n? [y]

がいきなり表示、、、。で、ハングアップ。

リブート、要請します。ううむ。

と、誤爆か。

リブート職人さんにリブートしていただきました。
作業継続中。

ユニプロセッサなカーネルを作って、再挑戦中。

(・∀・)ﾆﾔﾆﾔ▲増えない様に用心してね

i386なマシンではperlccが通らない模様。

茴 at /usr/local/lib/perl5/5.8.5/mach/B/C.pm line 476.
CHECK failed--call queue aborted.

( cd ..; tar czf bbs.cgi.tar.gz bbs.cgi )
%

とりあえず、perl版を入れておこう。

> ( cd ..; tar czf bbs.cgi.tar.gz bbs.cgi )
> %

こいつはゴミっす。上2行が不可解なエラー。

今回わかった問題:

・i386の場合、バージョンアップ途中の作業はSMPとapicなし(シングルCPUモード)の
　カーネルで行わなければならない。
　そうしないと立ち上がる途中でpanicを起こし、ハングアップしてしまう。
　たぶん、device.hintsが5.2系と5.3系で変わるせい
　(途中の段階で 5.3カーネル、5.2ファイル、という状態を経由し、それが通らない)
　だと思われる(未確認)。

=> シングルCPUの5.3カーネルなら問題ないので、シングルCPUのカーネルで
　　バージョンアップ作業を実施し、最後にマルチCPUにすれば回避可能(既に実施済み)

・Perlのバージョンが上がるので、Perl 5.6.1ベースのbbs.cgiは当然perl 5.8.5ベースでは動かない。
　read.cgi は 5.2.1 のものがそのまま動くが、ベンチマークのため ex7 のものとともに、
　5.3 上で再度コンパイルを実施した。

・i386の場合、amd64で通ったbbs.cgiのperlccによるコンパイルが通らない。(>>427)
　とりあえず、ex7と同じPerl版を動かすことにした。

Apacheのセッティングは、とりあえずex7と同じにしてあります。

最初に実力が試されるのは、土曜の夕方？

>>428 補足
> ・Perlのバージョンが上がるので、Perl 5.6.1ベースのbbs.cgiは当然perl 5.8.5ベースでは動かない。

「バイナリ版bbs.cgi」が正しいです。
Perlなら、5.6.1/5.8.5どちらでも問題なく動作しました。

perl5.8.5 自体をリコンパイルしなきゃかもですです、、、
でもってもしかするとportsから外して１からコンパイルした方が楽かも(^-^;;)

>>430
うーむ、i386でもamd64でも同じようにpkg_add -r perl ってやったんだけどなぁ。
つまり、私はコンパイルしていません。

うっしっしっし。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/traffic/live17traf.html

どこら辺が牛なのか判らないよ、ﾏﾏﾝ

今日のLive17はホント強かったです。これなら土曜日の実況で落ちることも無さそうです。

問題は放送終了後のex5('A`)
http://users72.psychedance.com/logview.cgi?srv=ex5.2ch.net

地道にLive17で続けてもらう方向でがんばってみます・・・

とりあえずの課題は、超高負荷時の仮死状態対策か。

ex7/live8が上がったら、

・syslogをどこか別のマシンに飛ばすようにする

を、とりあえずやってみるか。

リミッター切ってもLA=400以上になっちゃうのは、、、。

もう live8 にはつながらない状態なのに、

maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
maxproc limit exceeded by uid 2001, please see tuning(7) and login.conf(5).
...

が、延々と出続けてる、、、。

とりあえず、ここに記録しとこう。

仮死状態になるのは、何とかしたいなと。

【実況板】 live15/16/17 鯖 Part1
http://qb5.2ch.net/test/read.cgi/operate/1097931665/414-461

転記。

687 名前： ◆MUMUMUhnYI [sage] 投稿日：04/11/15 00:08:19
>>686
でも、defleteのせいとはちょっと思いにくいんですよね。
それより先に、syslog系を見直すとかbbs.cgiの起動制限をうまくやるとか、
そっちをやってみようかと。

うんうん

syslog鯖ですか
セキュリティやログ消失問題から標準syslogdではよくなさそうでつ
syslog-ng使えるようならそっちがよろしいかと
portsでも提供されているようですし

参考：ttp://www.atmarkit.co.jp/fsecurity/rensai/unix_sec09/unix_sec01.html

　465 ：▲ 某ソレ511 ：04/11/15 06:25:30 ID:Q7Whv+GJ
　いちお、こっちにも書いておこーっと。

　たぶん、負荷多すぎでbbs.2ch.netがちゃんと動いてなかったんだと思う、
　kawasemi-m見てるとしょっしゅうありますからね。
　じっさい、そのあたりで10分間くらい数字が増えてなかったりような部分がありましたし。。
　たしかあれってkawasemi-m見てるんですよね、

ということもあるし、bbsはbananaだとつらすぎ？

バーボン機能を入れてアレになったのかのう。。

こないだの大根が腐ったりした原因もこれかすら？

>>442
バーボン入ってない時も同じようなこと起こってたけどね。
例えば27時間テレビの時とか、
そのレスで負荷が、って書いたけど、なんとなく
負荷が原因というより、集中してあれれ、という感じかなぁ、

game10@tiger504 の土地造成お願いしますー

>rootさん

● 質問・雑談スレ77＠運用情報板
http://qb5.2ch.net/test/read.cgi/operate/1100474722/121

>>444
roger。時間とれた時点で。
で、11月26日までにFreeBSD 5.3R化必要かしら。< tiger504

# そろそろ、各サーバのバージョンアップスケジュールを出さなきゃ。

## tiger x 2ですね。< game系
## gameな人たちには以前相当ご迷惑をかけたんで、私的には罪ほろぼしの意味もある、、、かも。

>>445
そっすねぇ　< 5.3R

ジンギスカン準備工事もよろしくです

tigerサーバ(掲示板用)バージョンアップスケジュール & 進捗状況 雛形

tiger503 ex7 済み
tiger504 live13→game10
tiger505 news18
tiger506 game9
tiger507 live16
tiger508 live17 済み
tiger509 news19
tiger510 hobby7

ということで、

tiger503 ex7 済み
tiger504 live13→game10 来週早々
tiger505 news18 今週中
tiger506 game9 来週中
tiger507 live16 今日明日にでも
tiger508 live17 済み
tiger509 news19 今週中
tiger510 hobby7 来週中

といったあたりかなと。

久しぶりに儀式します。

+game10.2ch.net:206.223.150.115

を、DNSに追加お願いします。

例の mod_dosevasive を、bbs.cgi 起動数リミッターに利用できないか、
ちょっと考えてみようかと。

ん、もうDNS引ける？

>>449
done

game10 は
もう使い始めてもokですか?

>>453
OKです。
アカウント情報をメールしなきゃ。

ほほーい

>>446
ジンギスカン準備工事がまだでした。
やっておくです。

りょうかいですー

>>456
準備工事終了。
これで今やることは終了です。

単独スレによる告知

game8 の板たちは一時間くらい止まります
http://qb5.2ch.net/test/read.cgi/operate/1100511730/

>>447 のうち、こんな感じで単独スレ立てないといけなそうなのは、、、。

…基本的に全部、これでいくかな。
めったにあることじゃないし。

live16はだいじょぶだと思う。hobby7も他よりはましかなぁ。
あとは、、だめそうだなぁ。

メモリディスクがかなりぎりぎりだなぁ。

%df /md
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/md0 38124 31220 3856 89% /md

不安なので、1度rebootしてメモリディスクを大きくして設定変えてよかですか?
5分ぐらいでできると思われ。

いったんバックアップしてからrebootするので、
板復帰はいらないはず。

>>461
増やしたです。

%df /md
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/md0 76524 31328 39076 44% /md

来週はじめあたりに、OSのバージョンアップ&設定強化をしようかと。< game10

http://game10.2ch.net/
IPアドレス： http://206.223.150.115/~ch2game10/
バーチャルホスト変換前： http://tiger504.maido3.com/~ch2game10/

>>463
おぉ、おつです。

http://live19.2ch.net/
IPアドレス： http://206.223.151.130/~ch2live19/
バーチャルホスト変換前： http://banana226.maido3.com/~ch2live19/

両方ともアクセスできます。＠J-COM

live17 と ex7 の RLimitNPROC 150 をはずした。
つまり、プロセス数のリミッターなしに。

リミッターにかかると「リミッターにかかった」ということがどばっと行くため、
システム全体がもろくなる模様。(今のlive8)

症状は、例のメッセージがコンソールに出まくりという、昨日と同じ状態。

game（PCゲーム）だけはgame8@banana226に居残りなんですね。

>>467
game10に移転してるはず。

tiger503 ex7 済み
tiger504 live13→game10 来週早々
tiger505 news18 火曜〜水曜夜あたりにでも
tiger506 game9 来週中
tiger507 live16 済み
tiger508 live17 済み
tiger509 news19 水曜〜木曜あたりにでも
tiger510 hobby7 来週中

http://qb5.2ch.net/test/read.cgi/operate/1097921896/848-850n
こちらに話を振ります．>>381 のようなメッセージが出てくる状況は
まずいということですね？ では......やや変則的ですが，mod_cgi の
代わりに mod_cgid を使ってはどうでしょうか．cgid ソケットの
backlog 数がリミッタとして作用するかと思います．オリジナルの
mod_cgid ではこの数値は固定されていますが，以下のパッチにより
httpd.conf 中の ScriptsockBacklog ディレクティブで指定可能になります．

(bzip2+base64)

QlpoOTFBWSZTWUq4iQIAAdd/gGIxkEBZ////f6/+qv/v//pQBXhe6wzaHbZFAUpC
SRqCap+pPypjJqZPSegCD1PTCJppgBGjGgTI0GpkynqanqT1HpANNBowgDTJkGgA
ANNAAJEQiT1TaQ9T1P1R6TyhoAAAyGgAAAA9Q4aGTTQ0yNDTIyDIyNDIDE0ZNAGT
IxDCSIINAEmmIaKP1ID1NMgANAB6mgepk0NMiQjzm5rZK9evFM6RWIrRkcuEVLuj
aSjLnomZQ6cShDHuRZl2gvWSgoaL71CC/VWUCVlFTMr5oyiwh7EFnMQqWlViha1y
EksNLG22xttMY2NjY7wUENsbcKJPD+PfU90DMyKfD9RJmgopjxWcETZ+Rezwqzb5
85XnvT/6sp/LN7DrYzDViEM/ewx6uoZq2HNv9OiDjfsQFreEVkNuKhWE4l0QpkBI
QhapKzsAkA/UiCiw0qpiC+7oThQZBJQNBl2aD3av5yzPyjza2ZqOlgMRjLkWpUJE
I0mrGZoyEo0qulc77nc8XeHg9WXDFuoxCMdJRVvIoewrmEskXFaLRM9g1of140vz
+4cN8pMaDQyp9F3hViYQrgJag0AZIkXOw07Ku44fjU8h5vfNDpR2Rt4Mj2damkso
ZQnumC+29t4c4Avje2gZaorsYVjEgGqSviKoYaawAugxXDBg+Yin8HCcddqgRUq0
FUyEuTKbBXSUUVkohHXhMHvBQibICOD1U40AiTMmVey69Ssd/k3b4N52zOqr142y
jS6FItZVGyEOAg1QvoAcPUD8zwojh4g2urxwIOwgW4s27bcsZDqIi+OFGCpBkNxH
ryINVUWOEiSLEHeXB/KY0K0dZUiHXTJFYTQVFiRQc7yCDX1lMlhoMYYo0Q0UHcZF
YsBXmJM3OihnWi8jGaNXCUiaJXF5zI+39aywsRbA8wYX45ILkcTVIkgugHI85cix
DcKI6CBOBCWk0eA5yZ1BDUE77c6nVENQQQOjR4qCJCMnkq/OjRR5mawUHSXjKEQJ
e5g2V39AtjlfMpsmxK/UpsI4IpocmZr/QVkaB8RuIgzs32EQqGO5LeO2gy5DMVgw
GNfqM5cmQBeC+aTWE0uITFLItqlKSR95myWLB1U0MY/6qbIniVMeCNIwGE/EcRQV
a9EInCUypF9npIhVxLmAgYM4eUpBV85wiZnqgwFP+qUQibytaysLF42yK0dWDMAX
mD7Fwv2bEA4FBg2Bp1l7NlUK2CU4YrKlijjJihKocIZCKM7uRWJYyoyAuTdjs7oT
/wZzOQIvJhWjIURMJWkiUEpOKAgsy4mKPMjsDpIUJ1lRDsZ7i1AbV6YGG0MhIyW0
0Ci1cfQ0LjnIgwXM1TQ8AwxvMy1F0ugZGCLhFUlPcULXMTXei4qgQBgiz1nPEchz
mZindsCZLmcqSCCGHRaPamAiLRbipbDaksUsEFCIuphMMCr6RUWe1V32kEgrGgyX
FYmIMoFC08e7gMMNsDepnejGCiK9AaopKWwEtMvaRlQ0NknALxXDGGDNvSzpkULM
rEBDelBWjKSVDJUggN/M4ZJgxYrGDaUrRRKZB+phGchxgsbBgvRNOpOSvSoHcei6
Ii7OoVZVjkJcUNcqjrXOmQFk4zkCmQHxHUNwKnFHIReFQFrFSgnWhYoo9golKeGb
57lPxI8IeJka9COlDdr25gNnSnMOgLJJQyFXejAFQNqybe1De2Sc3k0KzSG/+LuS
KcKEglXESBA=

live8 の RLimitNPROC のリミッターをはずした。

>>470
おっ。
いれてみるか。

あと、すぐに思いつくこととして、

・Apacheをch2xxxxとかの権限で動かしてSuExecをやめる
=> suexec のオーバーヘッドがなくなる

があるけど、効果あるのかしら。

これはそんなに面倒なく試せるので、そのうちどこかで。

きたく。つかれた。

これ、はっとこう。

● 質問・雑談スレ77＠運用情報板
http://qb5.2ch.net/test/read.cgi/operate/1100474722/549
549 名前：FOX ★[] 投稿日：04/11/16 19:15:23 ID:???
1) ある板を別の板にリダイレクトする仕組み(手動)
2) サーバの負荷が上がったら 1) を実行する仕組み
3) 1)のある板を自動的に選択する仕組み
4) リダイレクト先を自動的に選ぶ仕組み
5) ぐちゃぐちゃにならないようにする仕組み

が全部出来れば全自動洗濯機の完成だー

>>473
あっちは未読の山なのでこっちに♪
なんだかうっとこ（2ch 鯖監視係。）で実験が出来そうな悪寒だよなぁ（汗）
それとも引越すとか？

>>474
でもよーく考えてみると、その「歩いた」が Timeout(http) するようになると、なぁーんも出来なくなる悪寒（汗）

tiger503 ex7 済み
tiger504 live13→game10 来週早々
tiger505 news18 済み
tiger506 game9 来週中
tiger507 live16 済み
tiger508 live17 済み
tiger509 news19 水曜〜木曜あたりにでも
tiger510 hobby7 来週中

>>473
＞ある板を別の板にリダイレクトする仕組み(手動)

これは各板の.httaccessで

Redirect seeother index.html リダイレクト先URL

でいけますな。LAの値によってリダイレクト実行はひねくれた方法がいるかも。

肝心のリダイレクタがパニクリそうな悪寒

tigerはemだったりする(Cobraはbgeだったり)。

対応、必要かも。
http://home.jp.freebsd.org/cgi-bin/showmail/FreeBSD-users-jp/81810

>>479
これか。
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/em/if_em.c?rev=1.53&content-type=text/x-cvsweb-markup
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/em/if_em.c.diff?r1=1.52&r2=1.53

問題なければ11月19日にMFCする予定って書いてあるから、
早晩、パッチが出るってことすね。

全部bgeかと思っていましたわん。

cobra bge
tiger em
banana vr
携帯banana fxp

やっぱ、どー考えても新スレ立てがサーバ負荷を急激に上げたに違いないなと。

1100695651.dat<>[フジ]高橋は神 (2)
1100695555.dat<>[フジ]お前ら何さわいでんの？ (2)
1100695549.dat<>[フジ]高橋克己の光臨を待ちわびるスレ (2)
1100695538.dat<>[フジ]生首オチ (2)
1100695529.dat<>[フジ]水10！〜ﾜﾝﾅｲ→ココリコミラクルタイプ〜 Part.1 (2)
1100695504.dat<>[フジ]高　橋　克　己 (2)
1100695482.dat<>[フジ]トリビアの泉　part7　〜満開激しくキボンヌ (2)
1100695468.dat<>[フジ]さくらたんのエロ画像きぼんぬ (2)
1100695454.dat<>[フジ]コマンドーがきぼんぬと発言した件について (2)
1100695417.dat<>[フジ]滝川クリステルだけど実況するスレ Part222 (2)
1100695398.dat<>[フジ]タモリ八島しらばっくれんじゃねぇ喪前らも2ち(ry (2)
1100695296.dat<>[フジ]高橋にちゃんねらー (2)
1100695283.dat<>[フジ]妹うｐマダー (2)
1100695145.dat<>[フジ]データ取得できませんでした (2)
1100695100.dat<>[フジ]データ取得できませんでした (2)
1100695178.dat<>[祭り]高橋克実、ｷﾀｰ 満開禿しくｷﾎﾞﾝﾇ (2)
1100695077.dat<>[フジ]キボンヌ！！！！！！！ (2)
1100695079.dat<>[フジ]ｷﾀｰ (2)
1100695074.dat<>[フジ]高橋克実が2ちゃんねらーである件について (2)
1100695073.dat<>[フジ]キャプチャのうｐ激しくキボンヌ (2)
1100694989.dat<>[フジ]高橋克己が「キター激しくきぼんぬ」発言した件 (2)
1100694951.dat<>[フジ]高橋がキボンヌと言った件について (2)
1100695072.dat<>[祭り]満開はげしくキボンヌ (2)
1100694942.dat<>[フジ]高橋克実は２ちゃんねらー (2)
1100694937.dat<>[フジ]満開激しくｷﾎﾞﾝﾇ (2)
1100695010.dat<>[実況]高橋克己が「キター激しくきぼんぬ」発言した件 (2)
1100694927.dat<>[フジ]満開禿しくｷﾎﾞﾝﾇ！！ (2)
1100694916.dat<>[フジ]高橋がアレな件について (2)
1100694895.dat<>[フジ]２ちゃんねらーｷﾀｰ (2)
1100694862.dat<>[フジ]毎回はげしくｷﾎﾞﾝﾇ (2)

rootさん、こんばんはヾ('-')ﾉ
忙しそうですねー

ところで、2chもいずれ巨大化してこんなのに似た
分散システムになっていったりするのでしょうか・・・ﾌﾞﾙﾌﾞﾙ

ttp://internet.watch.impress.co.jp/cda/event/2004/11/16/5430.html

disklessブートで、フロントエンドのApacheが立ち上がって。
データはバックエンドのMySQLに入っている。
というような仕組みになれば非現実的ではない。

でもHDDレスのブレードサーバーをJimさんに引っこ抜いてもらったりするメンテの手間はかかるな。

妄想ﾚﾍﾞﾙで想像してみた。
データを小分けにしそれを1単位として2台のPCでデータをミラーリング。
バックアップPCを何台か用意し,1台に障害が発生したらミラーマシンからバックアップの1台に
データ転送。リンクを繋ぎ変え。障害発生PCは改修後バックアップとして復帰。
こんな感じかなあ。

>>484
こんばんは。

本文より:
> 　ハードウェア、システムを解説したSilverstein氏は最後に、Googleにおける仕事の考え方を紹介。
> 「エキサイティングな問題に対して仕事をする」「世界中のみんなに影響を与える」
> 「可能な限りアルゴリズムで問題を解決する」「新しいことへのチャレンジを恐れない」などを列挙し、
> 「もし気に入ったなら、一緒に働きましょう」と会場へ呼びかけて講演を締めくくった。

日々エキサイティングという意味では、ここだって負けてないし。

つまり、
「もし気に入ったなら、一緒に泥沼にはまりましょう」
と。

tiger503 ex7 済み
tiger504 game10 来週早々
tiger505 news18 済み
tiger506 game9 来週中
tiger507 live16 済み
tiger508 live17 済み
tiger509 news19 済み
tiger510 hobby7 来週中

>>488
それはもう。

何気に、5.3 RELEASE-p1になっているね。
>>480対応じゃなさそうだな。。。

Edit src/UPDATING
Add delta 1.342.2.13.2.4 2004.11.18.12.03.04 cperciva
Edit src/sys/conf/newvers.sh
Add delta 1.62.2.15.2.6 2004.11.18.12.03.04 cperciva
Edit src/usr.bin/fetch/fetch.c
Add delta 1.72.2.1.2.1 2004.11.18.12.03.05 cperciva

>490
FreeBSD-SA-04:16.fetch.asc参照

tigerサーバにアニメ系の板を移転するという風の噂を聞いたけど、
ひょっとしてバーチャルホストの追加作成とかの必要があるのかしら。

news18(tiger505) はジンギスカン準備工事は成されていますか?

うわっ

ほぼどーじ

で、そのサーバがもし強化されてなかったら、
本日夜緊急にパワーアップ工事する運びになりそう。

ちなみに現状は >>489

愛ってすばらしい

>>493
おぉ。

確認します。

ジンギスカン準備工事はパワーアップ時に済んでました。
news18に入れるなら、いますぐにでもOKかと。

>>496
語らずとも伝わる愛。

んで　hobby7(tiger510) にも片方入れます、

もしお時間が御ありでしたら・・・
power up & RAM 工事をお願いいたします。

既存のにとりあえず寄生ってことみたいすね。
で、news18と。

ジンギスカンなしの今の状態でも、
こないだの中国敗退で微動だにしなかったんで、
負荷的にはいけるかなと。

>>499
hobby7 工事します。
一回 reboot 必要。
これは、この後でやります。

そのうえで今夜、5.3Rへの緊急パワーアップ工事も実施します。

どもです

ジンギスカン化は
今週末の様子を見てからと思っていますが、
気が変わるかも知れず・・・　ということで、

hobby7 のジンギスカン準備工事、完了。
てなわけで、ready to moveかと。

ここに転載しておこう

新設板・板移動情報・３＠運用情報
http://qb5.2ch.net/test/read.cgi/operate/1085230456/957

957 名前：FOX ★[sage] 投稿日：04/11/19 15:35:16 ID:???
アニメ系は将来サーバ名も anime.2ch.net にする予定(一年以内にはなんとか)
カテゴリも「アニメ」を作ったほうがいいと思ったりして(願望)
アニメ板(anime) の略板名(←bbsmenu上)はアニメのままでよろしくです(お願い)
なぜなら、突発的な負荷をアニメ板で受け止めるようなサーバ配置で行くからです。

アニメ板でも当然「実況はご遠慮ください」です。

>>504
ひょっとしたら最悪cobra/peko投入になるんでしょうかね・・・

アニメ系は2chリソースにとってきわめて凶悪なものといっても過言ではないわけで、
tigerでも捌ききれていない悪寒

read.cgiコールが圧倒的に多いならばcobra1台でも捌けるだろうけど(tiger1台では無理と思われ)、
bbs.cgiコールが圧倒的に多いならばtiger2台のほうがいいかもしれないと勘ぐってみる

>>505
今の大敵は「スレ立て攻撃」かなと。
超短時間の間にぼこすかといっぺんにスレ立てされるのが、
一番システムのダメージが大きいみたい。

感情にまかせたレスはそういうもんだと思うことにして、
感情にまかせたスレ立て(例: >>483)って、どうにかならんもんなのかな。

>>506
サーバ毎に(or 板毎に) 最小間隔チェックでも考えますかねぇ
bbs.cgi のなるべく最初のほうでチェックするようにして、

来年になるとは思いますが、、、

ちと仕事でコードばしばし書いているので
コード書きに食傷ぎみな年の暮れ

>>507
そうすね。

コードすか、、、。書けるひとのことはまじ、尊敬するです。(素)
私はセッティングとかチューニング方面の人なんで。

そういえば、動的に変えるってやつがあったんだった。

短時間で(あるいは問い合わせ内容に応じて)ダイナミックにDNS応答を変えるってのは、
意外とめんどうだったり、するかも。

>>506-507
確かにスレ立てはディスクIOの負荷が一番大きいですからね。

・datファイル生成、この重さは追記やchmod操作より重いはず
・subbackやindex等の更新

そのようなじゅうたん爆撃をされてはかなりきついのは当然でしょうね。
いっそ全板スレ立てチェックシステムがあるといいかも。仮にbbtシステムとして、

　リモートIP.dat.板名.鯖名.CGI名.bbt.2ch.net

をコールして板または鯖ごとに設定された何かの数を返すようにすればいいかと

サーバまたぐ必要ないし
局所的に聞けばいいんで
サーバ内(or 板毎) にファイル一個持てばokな感じ

スレ立ったら　touch して　スレ立て来たら stats でタイムスタンプ読んで
みたいな、

お茶飲め、餅搗けのすれたて版ですか

mnewsplus もジンギスカン化するので
ちょっとと止まります

ほい。

完了。

おつおつですー。

>>510
局所的なのはそれでもいいかもですが、
板や鯖をまたいだスレ立て爆撃に対応できますか？

もっとも既存の別システムで撥ねれば済む話かもしれませんが

>>516
それはバーボンハウスでかなりいけてるんじゃないですかね。
今問題になってるのは、長短時間の間での同じサーバでのスレ立てなんで。

長→超

次の目標ができたということで（ｒｙ

要するにファイル作成のコストが大きい、つまりbbs.cgi自体の起動は問題ないわけですね。
だから、bbs.cgiで、超短時間での同じサーバーでのスレタテが起きたときに「しばらくしたら立ててね」みたいなエラーメッセージを表示すればOKじゃん？

>>520
それが >>510 っていう話かなと。

スレ立てn秒規制ですか
DDoSを利用したスレ立て爆撃、みたいな未来の攻撃にも備えられますな

というか、実況板のスレ立て爆撃は事実上DDoSと同じことかｗ

風物詩がなくなる寂しさとの天秤ですなぁ

>>523
そうっすよね。
live系にたまに立つ単独スレのスレタイって、結構物事の核心を突いている場合が多い。

こんな感じですかね．

my ($now, $mtime) = (time(), (stat($CHECKFILE))[9] || 0);
if ($now - $mtime < $INTERVAL_TO_DENY) {
    /* 廊下に立ってなさい */
}
else {
    utime($now, $now, $CHECKFILE);
}

金曜ロードショーのガイドライン2
http://that3.2ch.net/test/read.cgi/gline/1097480104/

たしかに寂しいですねえｗ

>>526
そこのは全然風物詩、ってわけでもないでしょ。
むしろはっきりいってただの運営妨害だ。

あまりにもののけ姫スレが立ってるので流れ流れてここに来ました。
技術的な事はわからないけど「もののけ姫」とか同じ単語がつくスレは何スレまでとか
規制をつけると、その時あるスレを使う訳だし乱立にもならないのではとか思いました。

ここはもう実況はどうなっても構わないの心意気で、
live系のセッティングだけ甘くしておくとか…

もしくはex系だけ（ｒｙ

そのアイデアは散々既出ですから！
残念！！

>>留守番 ★さん、root ★さん、
＞超短時間の間にぼこすかといっぺんにスレ立てされる
確認してみたのですが、
bbs.cgiでのお茶飲め規制（LA規制）が機能してないようです、、、
これを再度機能させて様子見てみて良いですか？

>>531
お茶はFreeBSDなマシンではわざわざはずしてるんですよね、、、。
正直、あまり意味がないんで。

LAが高くても下がり目の時は大丈夫だし、
低くても「どば」が来ればだめです。

そもそもお茶が出るときはみんながいらいらしてbbs.cgiを上げるから、
いつまでたってもLA下がらないし。

なるほど。。。
了解です。

今のtigerサーバにはリモートコンソール(シリアル)があるわけだから、
強制的にDDBにいけるようにしてみるというのは、手なのかも。

【実況板】 live15/16/17 鯖 Part1
http://qb5.2ch.net/test/read.cgi/operate/1097931665/666-678

ということで、live8 live16 live17 ex7 で、

net.inet.icmp.icmplim=3000
net.inet.icmp.icmplim_output=0

を /etc/sysctl.conf に追加し、sysctl で設定した。

>>535
おつです。
ぐぐってみると結構でてましたね。。。。＜icmplim

次の祭りはいつでしょうかね

http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/networking.html#ICMP-RESPONSE-BW-LIMIT
UDPで接続できなかった場合にも出るのか
つーとやっぱsyslogか

そのうちTV局に金渡して鯖飛ばし依頼とか出たりして

hobby7にも、>>535 の設定を入れてみた。

Nov 19 13:14:09 <3.1> tiger503 savecore: reboot after panic: lockmgr: thread 0xc49b24b0, not exclusive lock holder 0xc3565640 unlocking
Nov 19 13:14:09 <3.5> tiger503 savecore: writing core to vmcore.2

だそうで。< ex7

vmcoreはちゃんととれてるっぽいんで、後で見てみます。
搭乗時間が迫ってるんで、とりあえずまた。

news18 news19 にも >>535 の設定を入れた。

>>540
(kgdb) where
#0 0xc0507ca2 in doadump ()
#1 0xc050829b in boot ()
#2 0xc05085c1 in panic ()
#3 0xc04fcd29 in lockmgr ()
#4 0xc0553b83 in vop_stdunlock ()
#5 0xc0553a33 in vop_defaultop ()
#6 0xc061dc67 in ufs_vnoperate ()
#7 0xc0616947 in ufs_inactive ()
#8 0xc061dc67 in ufs_vnoperate ()
#9 0xc055c2f0 in vrele ()
#10 0xc061a3cb in ufs_close ()
#11 0xc061dc67 in ufs_vnoperate ()
#12 0xc05666b0 in vn_close ()
#13 0xc05675a2 in vn_closefile ()
#14 0xc04ea014 in fdrop_locked ()
#15 0xc04e8e61 in fdrop ()
#16 0xc04e8e17 in closef ()
#17 0xc04e861f in fdfree ()
#18 0xc04f01c8 in exit1 ()
#19 0xc04efcf4 in sys_exit ()
#20 0xc066b9ff in syscall ()
#21 0xc06593af in Xint0x80_syscall ()

うーん、難しいなぁ。

mod_perl化って、言われているほど簡単じゃなさそうだ。

なるほど、mod_perlすると最初のディレクトリが / になるんか、、、。

導入されたですか?

悪戦苦闘中、、、。

ほとんどの障害はクリアできそうなんですが、
親元のcgi側で、

require "本体.cgi";

ってやって、
そっちで exit; ってやると(ごぞんじのようにbbs.cgiはそうやっている)、

[Sun Nov 21 10:17:31 2004] [error] ModPerl::Util::exit: (120000) exit was called at 本体.cgi line exitがある行Compilation failed in
require at 親元.cgi line requireの行.\n

ってなって、500 Internal Server Error になるです。

最近のmod_perlは、exit; を使ってもいいように改良されているのですが、
requireした先で exit するのは許してないのかも。

あるいは mod_perl そのもののバグなのかどっちなのかは、現在調査中です。

つまり、>>546 を簡単にいうと、

A.cgi
--------------
#! /usr/bin/perl
...
require "B.cgi";
--------------

B.cgi
--------------
exit;
--------------

ってのが、ちゃんとうごかんわけです。

個人的には、mod_perlのバグのような気がするなぁ。

いままでにクリアした障害:

1)SuExecと相性が悪い

UserとGroupをch2ex7/ch2に設定

2)カレントディレクトリがcgiを置いてあるディレクトリにならない

とりあえず明示的に最初のほうでchdir()する

3)bbs.cgi以外のcgiに影響をおよぼして欲しくない

<Files bbs.cgi>
</Files>

で囲む

試しに require をやめて、親元の下に本体をくっつけてみると、mod_perl配下でちゃんと動きました。
うーーーむ、、、。

exit;
を
Apache::exit;
にしてみるとか。

>>551
それはもうやったんすよ。

ちなみに、Apache2だからmod_perl2なんで、
Apache::exit; じゃなくて ModPerl::Util::exit; にしないとだめです。

で、結果は同じでした。
ちゃんとModPerl::Util::exitはexit;だけで呼ばれるみたい。

む、、、止まったか。< ex7

gotoで最後に飛ばすとか。。。

http://www.google.co.jp/search?hl=ja&c2coff=1&q=mod_perl+exit+goto&lr=lang_ja

bbs.cgi をとりあえず動く状態 (>>550) にして少し動かし続けたところ、突然反応がなくなりました。
pingはかかる、、、。

メモリリークとかが起こった予感。

ex7はリブート要請しました。

みんなが何年もの間言っていたほど簡単には、mod_perl化はできないとわかった、、、。

いっそbbs.cgiを1から書き直すとか……。

誰がやるんだとか言う突っ込みはなしの方向で一つ。

俺も一から書き直したが早い気がする。

言い出しっぺの法則で>>558が（りゃ

やっぱbbs.cgiが（りゃ だからか、、

ここでテストしてましたが、mod_perl配下だとTZ環境変数もおかしくなるみたい。

鯖が不安定なんだけど
http://ex7.2ch.net/test/read.cgi/morningcoffee/1101034399/

少なくとも今日のところは、撤退せざるを得ないなと。

で、SuExecをやめたぶん、ほんのちょっぴりパフォーマンスがよくなったのかも。
これについては、要経過観察で。

今後やるとしても、まずは、基礎研究とじっくりとした調査が必要そうですね。
環境変数とか、動作の違いとか。

で、世の中の解説やWebにあるページとかを見ても、
mod_perlの2系(with Apache2)は、実はあまり多く解説されていないように見えます。
つまり、練りが足りないということがじゅうぶん考えられる。

もちろん、じっけん！じっけん！(AA略 して、
ここで練るというのもありですが、
そうするにしてもまずは事前準備をじっくりやって、勝ち目が出てきてからってことになるかなと。

ということで今日のところは、負け&撤退ということで。

寝る前に、試みた設定をダンプしておこう。
何か、設定に間違いがあったのかもしれない。

・mod_perlはportsからインストール(www/mod_perl2)

・httpd.conf

LoadModule perl_module libexec/apache2/mod_perl.so
<IfModule mod_perl.c>
PerlModule Apache2
</IfModule>
(略)
<Directory "/home/ch2ex7/public_html">
(略)
<IfModule mod_perl.c>
<Files bbs.cgi>
SetHandler perl-script
PerlResponseHandler ModPerl::PerlRun
PerlOptions +ParseHeaders
</Files>
</IfModule>
</Directory>

# 以下は動作確認の際のみ入れた設定
# mod_perl status
<IfModule mod_perl.c>
<Location /perl-status>
SetHandler perl-script
PerlResponseHandler Apache::Status
</Location>
</IfModule>

これで、有効にした後でエラーなくカキコできたことは確認。(>>561 のスレの最後のほう2つ)
しかしその後、リモートログイン窓の反応なくなる。

リモードコンソールのlogin:も出なくなった(エコーバックはあった)

メモリがめいっぱいになった時と同様の動作であったため、
メモリリーク? が起こったのかもしれない。
ただしsyslogには、そのようなメッセージはなし。

<Files *.cgi>
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
</Files>
Perlrequire "〜/startup.pl"

===startup.pl================================
use Apache2 ();
use subs qw(exit);
*exit = \&ModPerl::Util::exit;

1;
============================================

#!/usr/local/bin/perl

use strict;
use warnings;

if (exists $ENV{MOD_PERL}) {
my $path = $ENV{SCRIPT_FILENAME};
$path =~ s|/[^/]*$||;
chdir($path);
}

>>565
自分の環境でやってみました。
>>546 なパターンのプログラムの場合、同じ結果ですね。

で、ModPerl::Util::exit に変えても同じ。

[error] ModPerl::Util::exit: (120000) exit was called at ./test2.cgi line 1Compilation failed in require at /home/hoge/public_html/test/mod_perl/mod_perl_test.cgi line 33.\n

つまり、requireした先でModPerl::Util::exit; は呼んではいけないらしい。

use Apache::compat; を startup.pl に入れてみたけど、結果は同じ。
この問題が解決できないと、メンテナンス性という意味でつらいかも。

ということで、とりあえずここまで。
しばらく本業します。

bbs.cgiをPerl5.8.5以降専用に大幅にリファクタリング。
mod_perl2でバグるところは書き方がしくじっている可能性が高い。

土曜の日テレの「ｷﾀｰ」と、
さっきのCXの「ドーン」を無事にクリアできたということは、
やはり >>535 が効果を発揮したのか。

21:00からのTVタックル@liveanbでどうなるか

やっぱPerlのような物に拘るのはもう限界じゃない？
preg_hogehoge()も付いてるあれの方がまだ安全というか、なんというか。

>>571
ひ(ryがいぢれないものはだめなのでわ？

PHPならひ（ｒｙのひともいじれるんじゃ？

夜○さんが弄れない予感。

で、その夜○さんとやらはmod_perl2用のPerlが弄れるのか？

たぶん　たぶん
2001年8月の２ちゃんねるの規模は、、、
現 tiger 2台とみた、

北ネット弱えええ！！！

それは・・・（びっくり

そりゃあ色々変わっていくのが自然だよなぁとオモタ。

>>576
今一番働いているtiger = tiger503 = ex7の最大転送量が、
圧縮して14〜15Mbpsぐらい。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/traffic/ex7traf.html

2台だと、圧縮して30Mbpsぐらいはさばけると。

この頃って、もう圧縮してた(mod_gzip)はずだから、
http://web.archive.org/web/20011127064159/http://www.yakin.cc/

tiger4台分ぐらいなんじゃないかしら。

てことはなにかい。

4 x (morningcoffee + news4vip + entrance + keiba + base) = 2001年8月の２ちゃんねる

っていうことなのか。

8月の閉鎖騒動の時は圧縮してなかったんでわ？

>>581
そっすね。
圧縮前の転送量ベースなら、ほぼぴったりか。

>>580
狼とVIPの書き込みの多さはただごとじゃないからのう
野球と競馬もROMが半端なく多いからのう

つまり、圧縮して30Mbpsくらいだったのかぁ。
2001年8月の２ちゃんねる
= 2 x ex7鯖
= ex7鯖 + news18鯖 + news19鯖 x 2
= morningcoffee + news4vip + entrance + keiba + base + anime + mnewsplus + newsplus x 2
(trafiicinfoは各種データがmnewsplusの2%くらいなのではずした)

(ﾉ∀`)ｱﾁｬｰ

すげー

あらゆる意味で・・・

もしかして、bbs.cgi内で開いたファイルで
明示的にcloseしてないのがあって
それがmod_perlで動作させようとしたときに影響してる、
なんてことはないですかね。

いや、mod_perlでexitした時の動作とか全然知らないし
メモリ不足が原因なら、全然関係ないんですが。

exitの代わりにreturnで戻すのはだめ？
常駐してんだから終了させんじゃなくapacheに戻してやる。
exitするとデータがクリアしたのに、他のプロセスで同じモジュールが動き続けて馬鹿になってゾンビが出る。
dieは？こいつも同じ原因を作る。

mod_perlからはとりあえず一時撤退するとして、
SpeedyCGIを使ってみるというのは、どうなんだろう。

Perl側を変えないとすると、こうかな。
# まだ入れてない。

LoadModule speedycgi_module libexec/apache2/mod_speedycgi.so

# まずは安全のため、機を見てコメントアウトとか数字を増やすとか
<IfModule mod_speedycgi.c>
MaxRuns 0
</IfModule>

# bbs.cgiだけSpeedyCGIにしてみる
<IfModule mod_speedycgi.c>
<Files bbs.cgi>
SetHandler speedycgi-script
</Files>
</IfModule>

きたく。ねむい。

>>589は、明日昼間あたりに入れてみるか。

これは何がどうなってどうなると予想されるものなんですか?
現状の２ちゃんねるにおいての話しとして、

>>591
これが、一番まとまっていると思います(原文の翻訳かな)
http://perldoc.jp/docs/modules/CGI-SpeedyCGI-2.21/SpeedyCGI.pod

つまりうまくいけば、Perl CGIの実行パフォーマンスが数倍になると。
で、こいつはmod_perlよりお手軽で、
mod_perlほど元プログラムをいじらなくても導入できる見込みがあると。

かつ、suexecとも仲が悪くないらしいし、
root権限なくても動かせるというのも、魅力的すね。

mod_perlにしてもそうですが、
基本路線としては、c系(PHP)を高速化した路線と大同小異です。

つまり、毎回でっかいPerlインタプリタを起動するコストを下げたいと。

LA を下げるのに寄与するって考えればいいのかな?
処理が比較して短い時間で終るからどんどん捌けるという路線?

てなわけで、

if 成功
bbs.cgi のすばらしい高速化が実現し、負荷耐性が上がるかもしれない
else
歓迎せざる、予期せぬ結果を招くかもしれない
endif

ということになります。

いろいろ調べていて、それなりに高速化の成功例も報告されているようなので、
まずは実験してみようかなと。

>>594
そですね。短い時間というか、
1つのbbs.cgi起動・実行をより少ない資源で済むようにすると。

仕込みはしてあるので、
万一「あっちゃー」が起こった時にリブートしていただけるんでしたら、
今やってもいいかなぁ、とか思っていたりして。して。

　 _ 　∩
(　ﾟ∀ﾟ)彡　じっけん！じっけん！
　⊂彡

i am ready

>>598
どもです。
んでは、やってみますね。

入れた。まずは、

<IfModule mod_speedycgi.c>
MaxRuns 0
</IfModule>

入り。

#<IfModule mod_speedycgi.c>
#MaxRuns 0
#</IfModule>


をコメントアウトした。

tiger503 (ex7) ですか?

ちょっと様子見、、、。

>>602
そうです。

ひょっとすると、設定間違ってて、
bbs.cgiの1行目を直さないといけない、、のかも。

bbs.cgiの1行目を、

#!/usr/local/bin/speedy

に変更した。

>>606 はだめすね。
/usr/bin/perl に戻しました。
効いてない、、、。のかも。

どんどん　LAが・・・

うまく効いてないかな？
500 エラーになるすね。>>606

この状態でしばらく動かしてみるです。

>>608
LAは、この時間のex7だといつもこんなかんじすね。

つまり、LA=30とか50とかでは、どってことないってころです。< この時間のex7

>>606 の直後にどんどん上昇し始めて
>>607 の直後から元にもどり始めた

ということです。

mod_perl化のための一歩
・exit()をApache::exit()でオーバーライド

ですね。500エラーの原因をつかむ必要がありそう。

今Apache起動しなおしました。LAが一時的に上がるです。

ふむ、やはり500エラーになるですね。

(>>606を>>600入りでやってみた)

[Thu Nov 25 07:14:22 2004] [error] [client 219.197.196.67] Premature end of script headers: bbs.cgi, referer: http://ex7.2ch.net/test/read.cgi/morningcoffee/1101308600/l50

って言うなぁ。< speedyに食わせると

ちょっと、簡単なスクリプトで試してみるです。

http://ex7.2ch.net/test/mod_speedycgi/mod_perl_test.cgi

動くみたいだなぁ。
(mod_perl_testとなってますが、speedycgiで実行してます)

>>617
use CGI::Carp qw(fatalsToBrowser);

を入れると、エラーの実態が表示されるので参考になるかと。
ただし、その部分のソースコードも表示されるのでｺﾞﾆｮｺﾞﾆｮ

>>620
うーむ、それわ、、、。

>>621
とりあえず、正しいhttpdレスポンスを吐き出していないかと思いますです（苦笑）＞ぷりめちゃーなんたら

#!/usr/bin/speedy -r10000

use strict;

use warnings;

use sigtrap;


...

<IfModule mod_speedycgi.c>
<IfModule>

で囲んじゃ、だめとわかたです。
囲まなければ、1行目を変えなくてもspeedyで起動する(で、500エラー)。

MaxRuns 0
ではなくて、
SpeedyMaxRuns 0
だったとわかったです。

ちなみに上記でも500エラー。

あとは、500エラーの原因は何か、と。

んぢゃ、cp bbs.cgi ナンタラbbs.cgi で複製を作って、 use CGI::Carp qw(fatalsToBrowser); 入れちゃうとか(^-^;)

でもってそろそろ眠m(_ _)m

で、さらに、
<IfModule mod_speedycgi.c>
ではなくて、
<IfModule mod_speedycgi2.c>
だとわかった。

あとは、500エラーの原因さえわかれば。

exit使ったらだめとか

順番にやっていけばいいかと
前提：perlccによる実行形式を削除
1) １行目を変えるのみ＆MaxRunsを1にする（-- -r1）
2) MaxRunsを指定しない
3) mod_speedycgiを使ってみる

-- -r1 があたりのもより。

動いたもより。

今の設定

LoadModule speedycgi_module libexec/apache2/mod_speedycgi.so
<IfModule mod_speedycgi2.c>
SpeedyMaxRuns 1
</IfModule>

で、
<IfModule mod_speedycgi2.c>
<Files bbs.cgi>
SetHandler speedycgi-script
</Files>
</IfModule>

に設定。

これで、元bbs.cgiをいじることなく、bbs.cgiだけspeedycgi配下に。

みるみるLAがさかってゆく、、、。< ex7

うそみたいに軽くなった。

これで、しばらくようすをみてみよう。

でもこれだと、毎回起動はしてる、、、だよなぁ、たぶん。

どのくらい効果があるかは、しばらく観察ということで、

ごはんたべてきます。

从o＾ー＾从御飯喰
http://ex7.2ch.net/test/read.cgi/morningcoffee/1101210350/

たとえ-r1だとしても、バイトコンパイルのキャッシュが効くとか？

>>635
静かに楽しそうでなんかうれしいよ

もしかして$ENV{'QUERY_STRING'}でパラメータを渡しているところが初期化ルーチンの最初だけとかじゃ無い？

環境変数を渡すタイミングが初期化時だけだとハマりどころかも。

あとexit前に
%Hoge = ();
みたいな感じで消去しとかないと-r1じゃないと動かないスクリプトになるという肝。

>>638-639
たぶん、備後の予感。
しかしわたしわ、Perlかけないし。

よかったよかった

>>640
ｶﾞﾝｶﾞﾚｰ｡

speedy_backendのゴミプロセスが残っていたようなので、それらをkillして、

SpeedyTimeout 60

を追加して、httpdを立ち上げなおした。

emの問題の続き

stable(RELENG_5)には、対応するするbugfix入りました。
Tue Nov 23 22:28:40 2004 UTC (2 days, 5 hours ago) by rwatson
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/em/if_em.c?rev=1.44.2.4&content-type=text/x-cvsweb-markup

今度の RELENG_5_3 candidate は反映されるのかな。

お、するするって。
ま、いっか。

>>632 の設定する場合、
いうまでもなく、SuExecをやめないとだめでした。

つまり、

User ch2live16
Group ch2

とかにしないとだめ。

# いきなり(たぶん)ファイルロックかからなくって、ぐわわと重くなり、リブート、、、。

で、1行目を変える方法(#!/usr/bin/perl → #!/usr/local/bin/speedy -- -r1 -t60)なら、
SuExec配下になるので、従来どおりで問題ないと。

あ、もちろんその場合は、

#SuexecUserGroup ch2live16 ch2

は、上記のようにコメントアウトで。

ex7見ると、、、。

56485 ch2ex7 131 0 4320K 3680K RUN 0 69:32 68.70% 68.70% speedy_back
96829 ch2ex7 131 0 4316K 3680K RUN 2 184:26 67.48% 67.48% speedy_back
59449 ch2ex7 131 0 4320K 3684K RUN 0 64:19 66.99% 66.99% speedy_back

なんか、ぼそってるすね。例のbbs.cgiぼそり現象がそのままきてるのか。
うーん。

そっか、RLimitCPUとか、moduleにすると効かなくなるのね。

Apache側でlimitかけてやらんと、だめなわけね。
設定しよう。

しかし、実際に動かしてみないと、わからんことばかり。

apache2limits_enable="YES"
apache2limits_args="-e -t 60"

を/etc/rc.confに入れて、Apache再起動でいいのかな。
とりあえず、ex7にて。

>>650 を ex7 live16 live17 に入れた。

やっぱ、ぼそるすね。

16551 ch2ex7 127 0 4320K 3688K CPU2 1 9:37 96.14% 96.14% speedy_back

しかたないすね、、、。/etc/login.conf をいじろう。

~/.login_conf でいいのかな。

>>653
だめすね。login(1) でしか参照しないのか。

/etc/login.confに、

# for limiting www user
www:\
<TAB>:cputime=60:\
<TAB>:tc=default:

を足して、

cap_mkdb /etc/login.conf

を実行し、

apache2limits_enable="YES"
apache2limits_args="-e -C www"

を/etc/rc.confに設定して、apacheをrestartした。

うーむ。>>655 でも再発。

で、/etc/master.passwd のクラスのところに www と書いてもだめ。
さて、どうすべか。

rc.confとかって再起動しないと有効にならないとか？

portsからapahce2を入れていれば
/usr/local/etc/rc.d/apache2.shを読めばわかるが、
上記スクリプトapahce2.shからrc.confを舐めることになっている。

PORTNAME= apache
PORTVERSION= 2.0.52
PORTREVISION= 3

リミッターが効かないことでex7の怪我が大きくなったので、
リミッターが効く方法(CGI経由での呼び出し)にスイッチ。

具体的には、ex7のbbs.cgiの1行目を、

#!/usr/bin/perl

から、

#!/usr/local/bin/speedy -- -r1 -t60

に変更。

live16/live17 も >>659 と同様の変更を実施。

live8は、SuExecをやめる工事だけ実施。
bbs.cgiは、perlccもの。

tiger503 ex7 済み
tiger504 game10 済み
tiger505 news18 済み
tiger506 game9 済み
tiger507 live16 済み
tiger508 live17 済み
tiger509 news19 済み
tiger510 hobby7 済み

というわけで、掲示板のあるtigerはすべてバージョンアップ完了しました。

あとはぼちぼち、blackgoatをやるかな。
すいてる時間にかたっぽずつやれば、たぶんサービス止めないでいけるかと。

ex7 の様子を見る限りでは、>>659-660 の方法でも、それなりに効果あるのかも。
今日はちょっと夜11時前に事件があったんで、明日にはわかるのかなと。

いいお湯でしたか！少しは疲れがとれましたか？
いつもお疲れ様です。
孤独な作業、そして皆が2ちゃんを気持ち良く利用できるように日々努力していただき、ありがとうございます。
がんばってください。
何も出来ないけど、応援しています。

>>664
いえいえ

>>665
>>665

ああっ、FOX ★さんがっ（；　･`д･´）

>>665
>>664は、root▲ ★さんへの励ましでした。誤解させてすみません。

い
い
孤　　　　　　　←　　「　狐　」　じゃないぞ
が
何

http://server.maido3.com/pie/
ここの画像読み込めないの漏れだけ？

>>665
でも、FOX ★さんのあちらこちらでの縦横無尽のご活躍も凄いって思っています。
無理なさらないでください。
皆さんのこうした努力があって、この2ちゃんが快適に楽しめるんですね。
ありがとうございます。

FOXさんは、私の何倍も、何十倍も、すごい人ですから。（す）

>>672 root▲ ★さん
そうなんですか、知りませんでした。
それと、大切な専用メモを荒らしちゃったみたいですみません。
黙って見ています。ありがとうございました。

root▲さんの俺様メモを見ていると昔EWSの管理者だった頃の事を思い出す。。。
campas noteを何冊埋めたことか・・・

ここをROMってlogとって、経過を読むと実地の鯖運用記録として使えます。
本にならないかなぁ。

FOX＆root▲ ★の、動け動けウゴウゴServer構築運営管理ガイド。

萌え萌えUnixネットワーク管理ガイド風に、お二方をキャラ化して、David氏が黒いメガネ…
　　　　　　　　　　　　　　　　　　

>>675
(･∀･)ｲｲ!
おもしろそ。実現ｷﾎﾞﾝﾇ

>>676
ダメダメ
ここで実現ｷﾎﾞﾝﾇなんて言ってもダメだ


実装ｷﾎﾞﾝﾇ

rootくんが2chの鯖管理で培って来た技術を本にして皆に広めてもらいたい
1年毎くらいで毎年発行とかで

>>678
今まで2ch本なんか買わなかったけど、この本なら多少高くても買うぜ！
3000円ぐらいでお願い。

形式は電車男みたいな感じにすれば、校正の手間とかも掛からないのでは。

なんで買ってもないのに、電車男の形式という発言が出てくるんだ？

電車男は本買わなくてもまとめサイトで読めるよ。

ほとんどそのまま、まとめサイトをそのまま紙面に移しただけ、
ですもんね。＞電車男

いや、それは知っていたけど、実物見ずに発言したということか。
スレ汚しすまそですた。

3,800円でも売れそうだ。

こいつあやしいなっていう解説本が出るかもしれないし、
出ないかもしれないってだけのことだろ。

>>682
ネットでただで手に入るがインストールCDも売っているFreeBSDと同じなわけかw

厳密には、ネットだと通信費かかるけどな〜。

今は定額制が主流になってきたので、あまり意識しなくなったけど。

本すか。

流れのままに、って感じすかね。
何らかの方法で何かを残したいな、とは思ったりするです。

しかし、実際に出すとなるとなかなか大変だったり。

# ジャパンカップダート @ ex7は微風だった模様。

すべてのtigerサーバに、
ex7/live16/live17と同じ呪文を入れた。

・SuExecを無効化し、直接ch2XXXXユーザでhttpdを起動 => CGI起動を少しでも軽く
・bbs.cgiをSpeedyCGI化

現状のまとめ

cobra (oyster901 = live8)
・SuExecなし、httpdを掲示板オーナのUIDで直接起動
・perlcc版bbs.cgi
・httpd数896
・httpdはアイドル時も全数待機

tiger (tiger503 - tiger510 = ex7 game10 news18 game9 live16 live17 news19 hobby7)
・SuExecなし、httpdを掲示板オーナのUIDで直接起動
・SpeedyCGI版bbs.cgi
・SpeedyCGIは#!/usr/local/bin/speedy -- -r1 -t60 で起動
・httpd数784
・httpdはアイドル時も全数待機

質問です

1) SpeedyCGIはPerlを高速化するものですか?
2) bbs.cgi or bbs.cgi がrequire しているファイルが更新されたとき
　　何かしなければいけませんか?

1)Perlのプロセス起動をへらすので結果的に
2)再読み込みが必要なのでapachectl graceful

>>691
ちと長くなるので、別々に答えます。
まず結論から。

1) Yes

動作原理は後述します。

2) 現在の2chの運用形態なら、bbs.cgiの配布・保守形態は現在のままでよい

2-1)親bbs.cgiがrequireしているファイル、
例えばbbs.cgi主処理部(頻繁に変更される方)が
更新された場合は、特に何もする必要はありません。

なぜかというと、現在の２ちゃんねるでのSpeedyCGIの運用形態が
「バックエンドエンジン毎回起動モード(-r1)」だからです。
理由は後述します。

2-2)親bbs.cgiそのものが更新された場合は、>>659にあるように、
bbs.cgiの1行目を#!/usr/bin/perlから
#!/usr/local/bin/speedy -- -r1 -t60に変更する必要があります。

ただし、急いで変更しなくてもSpeedyCGIのパフォーマンスにならないだけで、
従来のPerlのパフォーマンスで動き続けるため、運用にすぐに支障が出るわけではありません。

現状、親bbs.cgiにはめったに更新がかからないため、
親bbs.cgiに変更がかかったのを私が知ったら、その都度作業するというポリシーで、
当面はいけると考えています。

# というか、想定質問っす(w。

## 後述は、めしくってから書きます。

ちなみに、bbs.cgi主処理部が更新された場合に
ちゃんとそれが即座に反映されることは、実地に確認してありますです。はい。

bbs.cgi がこれによってかなり美味い具合になってきたとすると、
もう一つほとんど更新されないcgiがあるわけですが、
そっちはどのような方針がいいんですかね?

1) Perl にして同様にSpeedy化する。
2) C のまま、Apache のモジュール化する。

2) の方が効果があると思ってはいますが、
実は 1) でも 2) の90% くらいの効果が望めるので 2) にするとか?

read.cgi ですが、

今既にCで書いてあるもので、かつコンパクトなプログラムなので、
私は 2) がよいと考えていますです。
めざす方向は、mod_readがいいなと。

1)にして効果を上げる(SpeedyCGIの本来のパワーを発揮させる)ためには、
それなりにきちんと(Per作法l的に)プログラミングする必要があるようです。

今のbbs.cgiはいわば「SpeedyCGIを使ううまみの1割も使っていない」状況です。
それも、あわせて後述を。

んじゃ　若さの暴走ということで
mod_read に挑戦してみますかー

と、

以下はにわか勉強なので、間違い・不足な点はご指摘いただけるとたすかります ]

・SpeedyCGIの動作原理

SpeedyCGIは、フロントエンド部とバックエンドエンジンに分かれています。
フロントエンドは、ApacheモジュールまたはCGIプログラム(/usr/local/bin/speedy)として呼ばれます。

フロントエンドはバックエンドエンジンがいなければ起動し、Perlプログラムをプロセス間通信で
バックエンドエンジンに渡します。

バックエンドエンジンはPerlプログラムを＊実行前に＊コンパイルし、できた中間コードをメモリ上に展開し、
それを実行します。

つまり、Perlをインタプリタで実行せず、コンパイル後のバイナリを実行するようになるため、
その分実行が高速になります(効果1)。

その後、デフォルトではバックエンドエンジン側の処理が終わっても、
コンパイル後のバイナリコードは開放されることなくバックエンドプロセスのメモリ上に残り、
次に同じプログラムのリクエストをフロントエンドから受けた場合、
cgiプログラムが更新されていなければ
(ここで本体cgiの時間をチェックし、更新されていれば自動的に再読み込み&再コンパイル)、
同じバイナリコードを、そのまま再利用します。

つまりデフォルトでは、2回目以降はバックエンドエンジンの再起動なし、
再コンパイルなしでそのままバイナリコードが動きます。
ということで、動作がとても高速になります(効果2)。

しかし、この場合Perl側でコードの再利用(主に変数関連)を考慮した、
行儀の良いコードを書く必要があるため、
場合によっては、Perlプログラム側を行儀の良い形に書き直す必要が出てきます。

で、bbs.cgiは残念ながらこれに該当したため、デフォルトの状態では動かなかった。

(続く)

(続き)

これを避けるために、SpeedyCGIのオプションとして、
バックエンドエンジンの再起動インターバルを指定することができるようになっています。
これが、#!/usr/local/bin/speedy -- -r1 -t60 の -r1 のところです。

ここで1を指定してあるため、1回ごと(つまりフロントエンドが起動されるたびに、毎回)、
バックエンドエンジンを起動しなおすことになります。
つまり、上記の(効果2)を捨てることになるわけです。

といったところが、SpeedyCGIの私の理解です。

で、量産型bananaにもSpeedyCGIを入れていただけると、
全部のマシンのbbs.cgiを
#!/usr/local/bin/speedy -- -r1 -t60

にできるので、bbs.cgiの管理が楽になったりするです。



>>697
おおっっ。

もったいなかと、

なお、デフォルトのモードの場合、requireしているほうの子供Perlプログラムが更新された場合には、
自動的には更新を検知できないため、
その場合には >>692 にあるようにApacheをリセットするか、
親cgiをtouchする必要があります。

# ２ちゃんねるの場合「毎回起動モード」なので、たまたましなくてもいいと。

>>701
ですよ(ο･д･)(･д･`ο)ﾈｰ

bbs.cgiを、具体的にはどう改良すればいいんだろうか。
>>638-639 あたりが答えの一部?

>>703

気分が盛り上がっているので
先に　read.cgi に挑戦したいなと、


read.cgi再開発スレ
http://qb5.2ch.net/test/read.cgi/operate/1087199303/

>>704
てなわけで、今日はなんだか記念日みたいです。

bbs.cgi の speedy化の効果２をねらう改造の為に
サブドメインが必要な気がしまーす
read.cgi も一緒にやるか、

やっぱ明日、tiger に一個サブドメイン増やそうぜ

>>706
了解です。

今日は、いい気分で寝られそうな気がするですよ。

電子雑誌だったらできそうな悪寒＞ここのスレのログっぽいの

＞697 ：FOX ★ sage ：04/11/29 01:00:06 ID:???
＞んじゃ　若さの暴走ということで
＞mod_read に挑戦してみますかー
↑これ、笑うところ？

質問・雑談スレ81＠運用情報板
http://qb5.2ch.net/test/read.cgi/operate/1101642955/79-82 を前に、
live8 の bbs.cgi を perlcc 版から SpeedyCGI 版に変えてみた。

昨日の座頭市の時のLAの上がり方から考えて、
毎回起動モードでも、SpeedyCGIの方がいい気がするんで。

live8 だけ、read.cgi の時も KeepAlive を有効にした。

今の設定:

#
# Thank you for http://qb5.2ch.net/test/read.cgi/operate/1093068260/391-393
#
SetEnvIf Request_URI ^/test/bbs\.cgi nokeepalive
SetEnvIf Request_URI ^/test/subbbs\.cgi nokeepalive
#SetEnvIf Request_URI ^/test/read\.cgi nokeepalive <= ここをコメントアウト

たのしみ　たのしみ

いろんな意味でワクワク……。

ついでに鯖争奪戦論争も電子ブック化して（ry

サブタイトル募集ちう

プロジェクトＸあたりでやって欲しいよね。

サーバ争奪戦は04/08/15（tiger509,510）からはやってないですな

争奪戦なんかちゃねらーの一部しか読まないだろ・・・

バナナしかよこさないからだろ

あと雑談するなや
質問・雑談スレ81＠運用情報板
http://qb5.2ch.net/test/read.cgi/operate/1101642955/

>>659 SpeedyCGI導入以降のex7のLAのようす:
http://mumumu.mu/mrtglog/2004/11/30/load/ex7load.html

WeeklyとMonthlyを見る限り、効果はかなりあるみたい。

兄貴、かっこいいぜ兄貴。

>>719 金曜日深夜域を見ると一目瞭然で砂。
勝ち組宣言楽しみにしてます(素

bbs.cgi改造するなら、そろそろ古い機能はとっぱらっても良いような。
>>の数チェックとかはもういらないような。

むしろ、>>nnでリンクする機能を、.datに直接書き込むのではなく
read.cgi/r.i及び、bbs.cgiでhtml/*.htmlを作成時に変更したら良いのでは。

以前実際の各種板の全.datから計算したら、
通常の板でおよそ10%程度、AA系の板で3%程度、.datのサイズが小さくなるはず。
実況系はその間くらいかな。

専用ブラウザの対応は問題ないはず。
というのは、外部実況板などで>>nnのリンクは.datに入ってないところも多々あるから。

少しでもdatを小さくしようと、あえて>を１個にしてる人もいるよね。
2chブラウザなら全く問題ないし。
# 2chブラウザへの移行を促す効果も（Webブラウザだと不便に）
# いわゆるh抜きも同様の効果があるかな、と。

質問・雑談スレ81＠運用情報板
http://qb5.2ch.net/test/read.cgi/operate/1101642955/371-402

★☆★【娘。】モー狼板運用情報【狼】2☆★☆
http://qb5.2ch.net/test/read.cgi/operate/1099581556/735-759

というわけで、SppedyCGIの-M32オプションをex7で実験中。
live8/16/17にも同じのを入れてみることにしよう。

>>724

最小は＞724らしい。
>は実体参照に書き換えられて格納されるとか。

全角打ち込むのマンドクセ

流れ的にスレ違いだぞ
read.cgiかbbs.cgiのスレでやれ

>>724
＞# 2chブラウザへの移行を促す効果も（Webブラウザだと不便に）
＞# いわゆるh抜きも同様の効果があるかな、と。

ここにレスするのも何だけど、そういうのはProxomitronで簡単にフォローできるから
初心者以外は促せないかなぁ…

cgiの開発･実験用のバーチャルホストですが、さてどこに作りますかね。

特に問題なければ、game9 = tiger506 あたりにしようかなと。
名前は dso.2ch.net でいいのかな。

ほいほい

では作業行ってきます。
出来次第、儀式→掲示板システム入れ込みへと。

すんませーん、SpeedyCGIを入れたところはLoad Averageが低くなるけど、
LAがサーバーの実際の負荷と比べて恐ろしく低く表示されるから、
LAが低くても安心できないって事ですか？

>>733
書き込み(bbs.cgi起動)の同時起動が抑制されるので、負荷が低くなる、ってことです。
つまり、bbs.cgiを産児制限することになるから、本当に負荷が低くなると。

# 特にlive系などは、負荷の8割が書き込みだと思われ。

つまり、システム的には落ちなくなるけど、
もう少し書き込みパフォーマンスが出せるようにしたいなと。

では、儀式行きます。

+dso.2ch.net:206.223.152.30

を、DNSに追加お願いします。

これから、mod_cgidsoを入れる工事に入ります。
(DNSには登録いただいてOKです)

UA が上がりっぱなしの時はどうすればいいのか・・・

>>737
UAってなんでしょ。

すみません、
Uric Acid です

http://www.google.co.jp/search?hl=ja&c2coff=1&q=%E5%B0%BF%E9%85%B8%E5%80%A4%E3%81%8C%E9%AB%98%E3%81%84&lr=

>>736 の仕込み終わりました。
dsoのユーザのread.cgiと.so拡張子が、DSOの対象となります。

SpeedyCGIは既に導入済み。

>>735
どーん

http://dso.2ch.net/
IPアドレス： http://206.223.152.30/~ch2dso/
バーチャルホスト変換前： http://tiger506.maido3.com/~ch2dso/

dso.2ch.net に板を作るべくいろいろ転送中。。。

Perl CGI が　500error になるっす

http://dso.2ch.net/test/check.cgi

>>745
む、ちと確認します。

read.cgi (DSO味)はうまく動いているもよん

http://dso.2ch.net/test/read.cgi

直ったはず。

同一ホストに2個以上バーチャルホストを切ると、
UIDの都合によりそのままではSuExecなしにはできないみたい。

ということで、game9もSuExecありにしました(運用上は問題ないです)。

>>747
こっちは、SuExecじゃないモード(httpdのオーナー)で動きますんで。

というかこれで、i386/amd64の両方で動くことが確認できたと。
まずはめでたいです。>>747

http://dso.2ch.net/


↓作業用板名案だし

dso攻撃

なんとなく myanmar にしてみる。

運金を移転させればいい

安直にoperate3
もっと安直にdso

ミャンマーすか、、、。そのこころは。>>753

http://dso.2ch.net/myanmar/

じゃじゃーん

dso、土葬・・・・・。縁起でもない・・

なぜミャンマー？

むしろ、どぞー．にちゃんねっと、

>>757
ぶっ


相変わらず面白いのぅ

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

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