2ch特化型サーバ・ロケーション構築作戦 Part21

サーバダウン(鯖落ち）情報　part103
http://qb5.2ch.net/test/read.cgi/operate/1147529669/810

comic6 がうーむな状況らしい。
別途、対応で。

>>682 mogera が図らずもウィルスによるカキコをブロックしてる形なんですかね．
しかしそれが DoS になってしまうのは......バーボンがうまく効いてない？

>>683
きっとウイルスのコードが、そういうつくりなんでしょう。
つまり、異常終了すると無限ループになっちゃうとか。

>>684 バーボンは効いて httpd の段階で Deny できてるんですかね？
それなら仕方ない，っていうかそれに対処するとなると ipf レベルでって話になっちゃいますが．

>>685
たぶんね、まずは mod_authz_iplist あたりだと思うんですよ。

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

別途対応で。

CGI.pmって重くないですか？

書き込みバーボン(レス)は BBS を使ってるから、書き込みが成功しないと
読み込みバーボンまでDenyにならないといううわさがあるんですが、あれって改選したんですかね

△読み込みバーボンまで
○読み込みバーボンが発動するまで

>>688
comic6 と tmp6 は、両方とも今回の件で
ウイルスがバグってループになったっぽい気がしますね。
bbs.cgi 叩かれまくりか。

新しい環境でも書けているウイルスは存在するのかしら。

アンカーミスりました。>>688

>>688 については、CGI..pm は bbs.cgi の他の部分で既にロードして
使っていたりして。

>>691
>bbs.cgi 叩かれまくりか。

ってことは >>689 のように httpd 段階で Deny されてないってことですか．
まずはバーボン改良ですかね．

http://sabo2.kakiko.com/pageview/hourdata.cgi?date=20060527&server=comic6.2ch.net
を見ると、htmlが激しく叩かれているように見えますが、何か関係ありですか？

>>694
あまり関係ないっぽいです。

パソコンで人間ができてプログラムが出来ないようなこと
例えば連想とかを書き込みに入れられたらウイルスによる書き込み減るかも

>>696
それをいうなら画像でできた文字を入力するほうがいいだろ？

>>696-697
書き込み時Captcha（画像）認証制導入議論スレ
http://qb5.2ch.net/test/read.cgi/operate/1144071322/

SDｇｓｄｆ

とりあえず現在無限ループになってるのは，書き込めた“フリ”だけすればお引き取り願えるかな......
まぁどっちにしろ DoS 対策はしなきゃならんでしょうけど．

live23b = cobra2244 ダウンの件
疑うべきは、

電源問題
FreeBSD 6.1R + amd64 固有の問題 (news20b, live23b で起きている気がする)

あたりか。

フロントの Apache status を見ると、
フロントの httpd のコネクションが完全に詰まることは、避けられている模様。

フロントにログインして確認してみると、
F22, offlaw.cgi が刺さった状態になっている。
バックを NFS で参照している部分。

NFS の I/O 待ちになったものが、正しくタイムアウトしない様子。
df すると、刺さってしまうみたい。

read.cgi は、

例えば適当に、
http://live23.2ch.net/test/read.cgi/livecx/1111111111/

と入れると、詰まってしまう模様。

つまり、read.cgi 的にはうまく ProxyTimeout が働いていないっぽい。

http://live23.2ch.net/livecx/a/b/c/ とかは、すぐに 503 エラーになる模様。

GET /livecx/index.html HTTP/1.1
Host: live23.2ch.net

は、すぐにエラーがかえってくる。

つまり、ダウンを検出して「ダウンな状態」を
キャッシュしているように見える。

GET /バックにフォワードされる呪文 HTTP/1.1
Host: live23.2ch.net

もすぐに 503 になるので、>>705 と同じように検出はしている。

GET /test/read.cgi/livecx/1111111111/ HTTP/1.1
Host: live23.2ch.net

は、止まったままになる。（ううむ）

read.cgi は，ライブな dat が存在しないと過去ログ調べるのでは？
（つまり NFS でマウントされてるところ）

で，問題はその NFS なわけですが...... soft mount でも retrans とか timeout とか
そのあたり要調整ってことですかね．

>>708
なるほど、まさにそれですね。< NFS mount を調べる

read.cgi は、確かにそういうコードになっているです。
つまり、原因は同じか。

NFS の設定は、まだまだ調整が必要な予感。

ということで、>>701-709 のまとめとしては、

ProxyTimeout は、うまく動いているらしい。
で、いったんタイムアウトの状態になると、フロントは状況をある程度覚えるらしい。

Apache status を見ると、dat 直読み系はうまくタイムアウトしているので、
503 エラーになっている。(観測結果)

で、「覚える」までの間、たぶんぐぐぐと詰まるので、
一時的にフロントの httpd が満員になり、それで雪だるま全体が繋がりにくく
なったと考えられる。(これは推測)

「覚えた」あとは速攻でタイムアウトするので、現状では httpd の開きスロットは
ある程度確保されている。(観測結果)

NFS 系は、状況がまったく変わっていない。
つまり /etc/fstab に soft を追加しただけでは、何も変わらない。

別途他の調整を実行する必要ありということで。

ということで、ひととおりチェックしたいところは調べたので、
liveb1 の dat バックアップを固めて、
あとはたんたんとリブート要請へと。

>>712 done.

で、ここまでのチラシの裏リストの棚卸:

とりあえず >>600 あたりから。

・>>601-602

・>>615 kris の資料も置かれた模様。>>656 とかも参考に。

・>>618 の変更が 6.1R cobraダウンの原因っていう感じでもないみたい。
(ex14 は問題ないし)

・>>629-630 は問題なさげなのかな。

・バックエンドが落ちても、NFS が刺さらないようにする
>>633-635 あたり。fstab に書かずに直接 mount_nfs で試してみるか。

・Apache 的に SetEnv し、cgi でそれを参照する

・復帰の呪文の問題 (>>665)

・引越しに伴う default gateway の変更 (*.1 => *.2、153村は *.3)(>>667-668)
手順は >>669 だが、ping が通るなら先回りも。

・live23b/news20b がたまに落ちる(だまる)
>>649 でも落ちている(news20b)。しかも自分でリブートしたっぽい (>>650-652)
で、今日は live23b。

・>>679 の速度チェック
概ね問題なしという噂もありますが、一応。

・>>682 comic6 の問題(ウイルスのbbs.cgiへのDoSによる負荷)

続き

・>>687 クッキー問題
use CGI あたりで、ごにょごにょ。

以上、とりあえず。

【365Main】 回線増速(ニュー速とかお引越しのご案内) Part2
http://qb5.2ch.net/test/read.cgi/operate/1148497454/458

やっぱ、i386 と amd64 が活発なようですね。

最近では、big endian でも問題ないことや、
CPU が多くても(例えば14CPUとか)スケールすることの検証などに、
sparc64 も活用されているようです。

>>682
BBQじゃなくて自動バーボンみたいのがいるんですかねー。
判定方法が難しそうですがー。

スピードとか間隔とかだと、幾らでもかいくぐれますからねー。
1時間に1回でもウイルス作者にとってはいいですからねー。
感染パソコンを何十台も作ればいいわけですからー。

>>716
バーボンって、自動なんでは。

判定が難しいには同意で。

>>700 にあるようなことをするには、
さて、どうすればいいのかなと。

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

に、ウイルスの内部コードっぽいのが貼られてますが、
これだと、さて。

ううむ。

だんだん、フロントの httpd の空きコネクション数に余裕がなくなってきた。
刺さっている read.cgi が増えていっているせいか。

kill -KILL で殺しても死なない可能性ありか。ううむ。

>719
フロント２台ブレーメンメーターエラーになってるのはそういうことだったんですか。。。

httpd のリスタート自体はできた。
でも、微妙に変ですね。

このままだと、live22x や news20 にも影響が出ちゃうから、
cobra2244 のリブート入れない限り、
そのうちおじさんもニュー速で遊べなくなるってことか。ううむ。

>>721 は live22x1 に対して実施。

>721-722
ありゃりゃ
ｘ1ブレーメンメーター復帰は確認しましたがまた挙動不審になるのも時間の問題
って事ですか。。。。


※liveスレで早めに実＋への誘導は入れておきました。

httpd の子プロセスが刺さったまま残ってしまったですね。

他のフロントに対する設定変更は、cobra2244 のリブートが入るまでは、
なしということで。

…つまり、NFS の設定の見直しが急務ってことですね。

・タイムアウトするようにする

ってことで。

しかし、soft を指定しているのにハングアップするというのは、
しかもずっと刺さってしまうというのは、ちと納得できないですね。

# さっき間違って入れた df コマンドが、まだ刺さっているので。

で、今は UDP で mount しているわけですが、
TCP で mount するということも、試してみる意味はあるのかもですね。

ただ、TCP で mount していると、
NFS サーバのリブート入れた時に、connection reset by peer とかになるような気も
しないでもないかも。

6.0R では TCP mount はいまいちらしいけど。
http://lists.freebsd.org/pipermail/freebsd-current/2005-July/052582.html

…今は動くはずと。
http://lists.freebsd.org/pipermail/freebsd-current/2005-July/052584.html

live23リブート入ったようですが閲覧できないようです。

>730
データの差し戻しお願いします〜＞rootさん

>>731 done.

ということで、NFS の設定詰めのため、
またいろいろやってみるということで。

【実況】　live23+24　Part19【新体制始動】
http://qb5.2ch.net/test/read.cgi/operate/1148046382/790

790 名前：root▲ ★[] 投稿日：2006/05/29(月) 04:08:02 ID:???0 ?#
で、今回みたいな事態にならないように
(live23b のダウンが live22x や news20b にも影響してしまう)
近日中に、設定変更確認 & 試行のため、
一時的にわざと落としたりするかもです。

その場合には、事前に連絡を入れるということで。

live22x3 異常発生ですね。

うまくプロセスが死なない。
まだ落ちていると思っているのかな。

live22x4 も、同じ異常発生。

両サーバとも、NFS の復活を認識しません。
リブートもだめの模様。

これは、NFS に虫がいるっぽいですね。

live22x3 live22x4 フロントから外しておきます。
あとは通常のリブート要請コースで。

live22x1 x2 x5 は正常でした。

うーむですなぁ、

Cobra だと駄目なんですか?

>>734
> live22x3 live22x4 フロントから外しておきます。

done.

そういえば、

・自動でへくったフロントが切り離されるようにする

というのもあるなぁ。< 棚卸

>>735
どうも、現状ではそうなのかもですね。

設定で回避できるかもしれない可能性は、ありますけど。

一つあった問題(kbdmuxは入っているとおかしくなる)は、
はずすことで回避できました。

6.0R (ex14)ではこの問題は起こっていないので、
6.1R の問題なのかなと。

へくったフロント、うまくリブートできたようです。

reboot -q -n でリブートしてみた。

フロントを5台体制に戻しました。

・NFS しくらないようにする
・6.1R/amd64 の設定でハングアップを回避できないか調べてみる

あたりですかね。まずは。

http://www.freebsd.org/releases/6.1R/todo.html

UFS deadlocks on amd64
Needs testing Tor Egge Seen by Kris Kennaway. This problem seems MI.

これ、かなぁ。

うーむ。

これは >>499 でも指摘したかな。

http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2006-03/msg00678.html

rootちゃんがんばって！
応援してるよ！大好き

>>718
続きいるです？

>>745
あるとうれしいかもしんないです。

しかし、わたし的にはウイルスコードそのものよりも、
どうやったら無限ループじゃなくてとりあえずお引取り願えるかのほうが、
興味ありますね。

denyした方が早いような

>747
爆撃しているＰＣの数が尋常じゃないので無理かと
例の呪文を追加するタイプの登場も時間の問題なので新クッキー仕様と併せて
考えていかなければならない課題でしょうねぇ


※現状も負荷が高めなので爆撃は減っていないようです。
　無限ループに入る前にバーボン送りにしちゃうってのもあまりスマートじゃない
　しなぁ。。。
（フラグをつけてＢＢＱ焼きにするデータにはなりそうですが）

deny するよりも、graceful にお引取り願うほうが負荷が低いし。

if body.match(/(書き込み確認)|(2ch_X:check)/)
@board.cookie = head['set-cookie']
retry

elsif body.match(/お茶でも/)
@board.set_tmp_wait(60*5)
return false

elsif body.match(/もうずっと書けませんよ/)
@board.set_tmp_wait(60*65)
return false

elsif body.match(/には書き込めません/)
@over_size = true
@board.wait
@board.set_tmp_wait 0
return false

elsif body.match(/(\d+) sec たたないと書けません/)
@board.set_wait($1.to_i)
sleep($1.to_i + 1)
retry

elsif body.match(/ブラウザ変ですよん-2/)
TwoChannel::set_user_agent
retry

elsif body.match(/連続投稿ですか？？/)
@board.set_tmp_wait(60)
return false

elsif body.match(/連続投稿ですか？/)
return false

elsif body.match(/ブラウザを立ち上げなおしてみてください/)
@board.time_count += 1
retry

elsif body.match(/名前が長すぎます/)
name.chop!
retry

elsif body.match(/Rock/i)
return false

elsif body.match(/規制中/)
retry

elsif body.match(/バーボンハウス/)
raise 'babon'

else
print body if $DEBUG
raise 'Undefined Error'

end

書き込みの終了ページをクッキーきちんと渡してくれないのに見せれてみるとどうなるんだろう。

クッキー渡してくれたレスだけ反映する形でやるしかないかも。

> 対策
ここに書いちゃっていいかな？

>>752
なんか、まずそうですかね。< 対策

書いてしまったらまた亜種が出るだけか。
でもどうせ出るという噂もあるし。

>>753
出るのが遅れるだけでもずいぶんと違います。

言葉足らずだからもう少し。

つまりは自力で書き換えられるような人でも
対応がすぐ出来る人と出来ない人がいる。

すぐ対応できる人は、書かなくても自力で規制を突破するだろうけど、
書かれることで突破の敷居が低くなって、より多くの亜種が出回る
かも知れないってことで。

挙動が違うものが複数でてくると、あとでの対策も
面倒になります。

ひろゆきがソースを公開しないことはどうのこうのとか言ってた過去ログがあったね

>>750 だとすると、「書き込み確認」という文字列を
別のものに変更しない限り、お引取りいただけないということかしら。

>>757
でも「書き込み確認」で書き込めたかを判定する2chブラウザも多いような…

>>758
で、ここを変えるとまたいろんなことが起こると。

でもそれも、２ちゃんねるっぽいとも言えるのかな。 < いろんなこと

現状の爆撃対策だけなら、同人板を移転させて、「もうずっと書けませんよ」を延々と吐くだけの物をbbs.cgiの代わりに
設置するというのは？

>>760
移転させても、download のやつみたいに
bbsmenu/bbstable を読んで追尾するんじゃないかなと。

>>761
board = TwoChannel::Board.new('comic6', 'doujin')

ハードコードされてて、自動追尾はしてないと思う

>>762
download のやつとはとりあえず違うと。

be mail を撃ってみた

>>763
ぐぐるコードは残ってたり、使われてないけど

>>764
お返事を打ちました。
実験開始してみてますが、びんごみたい。

うーん
なんかまたnews20つまり気味だなぁ

ピンクの小粒ちょうだい

つ●

>>766
うーむ。

様子見てみます。

白インゲンで。

特に問題ないですね。

ちなみに PIE から一部 ISP への経路が、
一部おかしくなっていた時間があった模様。

そっか、それは失礼。

NidaってViewよりももっさりなのかなぁ

はなもげらぷろきしいれなよ

>>771
ちょっともっさり目だと思ったんで、
私は View に戻してしまいました。

View も既に対応版になっているです。

ただ、もし 64bit (amd64) で発生する虫がいるとすると、
爆弾をかかえているようなものなので、
しばらくは、常にどきどきしますね。

それでもだめならコーラック

viewに戻した、
快調だ

なんだよｗ
朝顔の種とかいってやろうとおもったのにｗ

あれ？

>>762
http://aas.u.la/c.cgi/-/operate/1145114275/762

Nidaからのアクセスは全て弾くようにしたらよくね？

style厨うざ

View厨うざ

>>780-782
池沼

ところで ex14 って、どういうシチュエーションで落ちたのかしら。
ping もかからなくなったのかな、、、。

>>784
pingはかかった
sshは繋がった
Apacheだけがしんでいたっぽい

>>785
なるほど、先日来と同じ症状ですね。
それになると、ログインもできなくなるんだよなぁ。

カーネルパニックしてリブート入った模様。 < news19
amd64 だと、FreeBSD 6.1R は微妙な挙動があるのかも。

cat info.5
Dump header from device /dev/da0s1b
Architecture: amd64
Architecture Version: 2
Dump Length: 4226842624B (4031 MB)
Blocksize: 512
Dumptime: Sun Jun 4 13:08:30 2006
Hostname: cobra2247.maido3.com
Magic: FreeBSD Kernel Dump
Version String: FreeBSD 6.1-RELEASE #0: Tue May 9 01:41:03 PDT 2006
[email protected]:/var/src/sys/amd64/compile/AMD64_COBRA_61_NOKBDMUX_NOPREEMPTION
Panic String: spin lock held too long
Dump Parity: 3586994136
Bounds: 5
Dump Status: good

>>787
kgdb の結果:

(no debugging symbols found)...Attempt to extract a component of a value that is not a structure pointer.
(kgdb) where
#0 0xffffffff802696ad in doadump ()
#1 0xffffffff802696d4 in doadump ()
#2 0x0000000000000004 in ?? ()
#3 0xffffffff80269ce7 in boot ()
#4 0xffffffff805fadc0 in enumerators ()
#5 0xffffffff80458267 in __func__.0 ()
#6 0x000000000000002f in ?? ()
#7 0x000000003ab59a70 in ?? ()
#8 0x0000000000000004 in ?? ()
#9 0xffffff00cf854720 in ?? ()
#10 0x0000000000000104 in ?? ()
#11 0x0000000000000000 in ?? ()
Previous frame identical to this frame (corrupt stack?)

あまり参考にならないかも。

kernel Panicですか。
うーん。。

終わりなきバグとの戦い

終わり無き自分との戦い

あんまり虫虫ゆっていると、
「ちゃんと send-pr してくんないと、直せるものも直せません」って、
FreeBSD の中のエロい人に怒られそうなようかんだなぁ。

しなきゃなぁと思ってはいるんだけど。

そこで、「黙れ小僧！お前に(ry」と言い返すのですよ。

Solarisはダメですか
商用利用も無料になったんですが

いくら無料になったって。ｿﾗﾘｽの鯖管出来る人がいないなら無意味。

Solaris = SunOSに詳しい人はいるので、鯖管やってくれるかどうかの問題かとｗ

Solaris10 は Solaris8/9 までのノウハウとは全く別のものが要求されますよ

Solaris10 なんかより FreeBSD のがぜんぜんいいと思うけど・・・

次ぎ乗り換えるときとか、大きな問題解決が必要になったときに選択肢になるんじゃない？

問題があったとき2chでバグバグいってるだけなら、どのOSを利用しても
最終的には一緒かと。

というわけで、rootさんにはsend-prおねがいしたいです。

Solaris(i386)は、ちょっとした高負荷をかけたとたん死亡したことがあるなぁ。
Linux(FC i386)とFreeBSDでは、まだLinuxのほうが耐えてくれたけど。
PenDでLinux(x86-64)でたったら不明なメモリーリークでフリーズ。

Solarisは重杉で使い物になからなかったなぁ。

OSから2ch仕様で作ればいいんじゃね？

略称・OS/2でどうか。

>>801
バージョンが明確じゃないと、なんとも。

FreeBSDだって、5.2.1Rと6.1Rとでは、安定性も性能も全く違うです。

>>800
がんがります、、、。

send-pr しても >>788 みたいのだと、よくわからない気もしますが。
kernel.debug は作ってないですか?

>>805
作ってないです。

#makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols

パフォーマンスが（りゃ という話はあるけど、
news20b あたりは余裕しゃくしゃくだから、
やってみるとよさげかしら。

どの OS を使うかは技術的問題以外に政治的問題ってのもあるでしょうしね．
ホスティング会社側のこともあるし，2ch 側だけで決められるものではないでしょうし．

んで，確かに Solaris 10 では 9 までとは様相の異なる部分も少なからずあって，
例えば SMF とか．まぁ慣れの問題でしょうけど．ただ，ZFS なんかはメリットありそうですね．
過去ログの膨張による HDD 圧迫も問題になってますが，compression=on にすると
容量節約できそうですし．個人的には Express (Nevada) ですでに使ってますが，
/usr なんかも普通なら 3GB ぐらい食うところが 2GB ぐらいで済んでますし，
テキストデータの dat なら圧縮も結構効くでしょうしね．
もっとも，ライブな dat まで圧縮すると CPU 的にはきつくなるでしょうけど，
そのあたりはマウントポイント単位で設定可能ですし，それに CPU に余力があるなら
I/O データ量の削減により速度向上も図れるようですし．

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

www2 のファイルを置いてある Directory のところににこれ入れてみたけど、
なんかうまくいかないっぽい。

同じ ETag: になるべきなんですよね、たぶん。

mtimeが微妙に異なるんですかね

>>809
rsync でやってはいますが、、、。
これから外出なので、あとで試してみるです。

HEAD /snow/index.js HTTP/1.0
Host: www2.2ch.net


www2f1→411963-664-c5aa2540
www2f2→2c0fb1-664-c5aa2540
www2f3→23f603-664-c5aa2540
www2f4→4006a2-664-c5aa2540
www2f5→41cf89-664-c5aa2540

Last-Modified(つまりmtime)は秒単位では全部同じでしたね。

手元のApache2.2で試しましたが、
FileETag -INode
だとinodeが含まれますね。
FileETag Size MTime
だと含まれないみたいです。

http://httpd.apache.org/docs/2.2/mod/core.html#fileetag
>デフォルト:FileETag INode MTime Size
>　　　　:
>INode, MTime, Size キーワードには + や - を前に付けて
>指定することもできます。この場合は、より広い範囲から継承された
>デフォルトの設定に変更を加えるようになります。そのような接頭辞の
>無いキーワードを指定すると、即座に継承した設定を無効にします。

ってなってるのにナゼだ......と思ってソース見てみたら，
内部的にはデフォルトが ETAG_UNSET (!= ETAG_ALL) なんですね．
で，ETag 生成時に ETAG_UNSET -> ETAG_BACKWORD (== ETAG_ALL) として扱ってると．
なんかドキュメントの書き方このままだと......って感じですが，
それはともかく >>812 のようにするか，あるいは

    FileETag All -INode

のようにするか，で i-node が外れますね．

>>812-813
なんと、、、。

あとで、やってみるです。

VIPPERどうにかなりませんか。

○●【ex14】VIP運用情報104●○
http://qb5.2ch.net/test/read.cgi/operate/1149683567/

BG3 はカーネルパニックか。
最近、BG3/BG4 は負荷試験状態かも。

>816
カーネルパニックですか・・・
そろそろ6.1Rにして凌ぐことも検討しないといけない時期かもしれませんね
（一時凌ぎにしかならないけどやらないよりマシだし）

道頓堀川の奴はちゃんと供養されたのかね

キャッシュファイルを /md に，とか．

>>818
浚っても発見されなかったそうだよ＞サンダース

>>819
6.1R にしたら、って感じですかね。

/md をすごい勢いでアクセスすると、何か起こるという噂も、
ありやなしや。

ううむ、

FileETag Size MTime

だとうまくいって、

FileETag All -INode

だと、うまくいきませんでした。

謎が多いですが、うまくいく方でやるということで、、、。

>>822 乙です．ホント FileETag 周辺の内部処理は謎が多いですが......

そういえば、どうでもいい話、mod_expiresなんかでExpiresヘッダとかCache-Controlヘッダを
送ってやると、IEとかGeckoなんかはその期限が来るまで一切リクエストを送らなくなるっぽい。
304を返すだけのリクエストが減るかも。DNSのTTLみたいな延滞が許されるならありかなーとか。

>>824
なるほど。

逆に TTL みたいな形にできる、ということですか。

DNSのキャッシュみたいに期限が切れてなければキャッシュから、切れてたら
更新されてるか問い合わせるみたいな動作になるらしい。

んで、ブラウザの方にキャッシュの更新の仕方の設定があって、GeckoもIEも
どちらも毎回更新を確認するような設定が存在するんだけど、
GeckoのMozilla 1.7.13では文字通り毎回更新のリクエストを発するようになるが、
IE 6.0 SP1は毎回更新の設定でも、なぜか期限付きのページは期限までは
キャッシュの方を優先して使うっぽい。

以下の DNS 登録をお願いします。

(新規追加)
+ex15.2ch.net:206.223.150.42

>>827
done

Header set Cache-Control max-age=600

で10分間とか．www2 のスタティックコンテンツとかならいいかもですね．
dat とかの板のデータに使うと雪だるまの mod_cache 問題と同様に
BG への影響が問題になるかも知れませんが（u.la が稼働して BG が
不要になればその問題も解消しますが）．

mod_expiresなら修正時刻基準にもアクセス時刻基準にも出来るので
Cache-Controlのmax-ageとかExpiresの日付を動的に変更してくれますよん。

ex14 の memories への収容作業、完了しました。

DNS サーバの設定変更をお願いします。

(現在)
+ex14.2ch.net:206.223.151.225

(変更後)
+ex14.2ch.net:206.223.151.230

>>831
done

確認しました。>>832

これで、今回の移転作業は終了かと。
oyster901 のハードウェア手当てについては、雪だるまスレあたりでわいわいと。

はいー

お疲れ様でし

ど疲れさーん。。

http://qb5.2ch.net/test/read.cgi/operate/1149952652/34
live23b -> 当面は保守的に 32-bit カーネル
news20b -> デバッグシンボル付き 64-bit カーネルで様子見

とか......

とりあえず、live23bの鯖落ちの原因は、logを見ないと分かりませんから
まずは状況を把握してから、考えてもいいかも。。

>>838
ログが残らないんですよね。いきなりガッと止まってしまって
強制リブート入れるのって。

前に FreeBSD 5.2.1R (例のgame6とかがちゃんと動かなかった時)にも
ちょっと調べたんですが、
カーネルデバッガ機能ありのカーネル作って、
リモートコンソールから強制的にカーネルデバッガに落とすとかいう
操作が必要になるです。

また、試行錯誤する日々か。
あるいは、最新の stable に上げてみるとか。

>>839
そういうことですか。。
うーむ。。

ひょっとすると，NFS の soft mount での timeout はデフォルトでは infinite になってて，
-s オプション指定しても -x とかも併せて指定しないと無意味になってるとか......

>>841
ありえますね。

あとは、フロントの自動切り離しと自動再接続か。
うーむ、まだまだすることが多いなと。

で、/etc/fstab に書くパターンでは -x とかは指定できない気がするので、
/md の mount と同じで、mount のためのスクリプトを別に書く必要がありそうですね。
これはそんなに難しくなさそうだけど。

FreeBSD/amd64 なバックエンドは2台あるので、
1台をとりあえず現在の stable にしてみる方向で。

うーむ。
make -j 4 buildworld で死ぬとは。

というかたぶん、負荷は関係ないっぽいですね。
踏むか踏まないかというか。

%uname -a
FreeBSD cobra2244.maido3.com 6.1-STABLE FreeBSD 6.1-STABLE #1: Sat Jun 10 20:14:59 PDT 2006 [email protected]:/var/src/sys/amd64/compile/AMD64_COBRA_61_NOKBDMUX_NOPREEMPTION amd64

live23b カーネル更新。

これで live23b がしばらくハングしなければ、news20b も同じのに更新の方向で。

6.1R (news20b)
-mpt0: MPI Version=1.2.9.0
-mpt0: Unhandled Event Notify Frame. Event 0xa.

6.1-STABLE (live23b)
+mpt0: MPI Version=1.2.12.0
+mpt0: Capabilities: ( RAID-1E RAID-1 SAFTE )
+mpt0: 0 Active Volumes (1 Max)
+mpt0: 0 Hidden Drive Members (6 Max)

SCSI コントローラのドライバが更新されているですね。

>>847

うーん、でも、
私の記憶に間違いがなければ、この更新って 6.0R で入ったもののような気が
しないでもなかったり。

…いや、>>847 はかんちがいっぽいですね。

SCSI コントローラ側のバージョンだった。
もう1回比較してみるか。

dmesg 的には変化ない模様。< 6.1R と 6.1-STABLE

とりあえず新カーネルで make -j4 buildworld 完走。

一度、リブート入れる予定。

ユーザランドも 6.1-STABLE にした。< live23b (cobra2244)

NFS の設定の詰めは、急務ということで。

mount_nfs -R 1 -D 1 -x 1 -s -a 4 -b -i -o ro,nosuid live22:/path /path

こうかな。

>>853 timeout は秒なのか別の単位なのかはわかりませんが，秒だとすればそんなところですかね．
まぁとりあえずじっk(ryで．

フロント5台の NFS を、>>853 の設定に全面的に変更した。

つうか，秒ってより回数ですね＜-R, -x

マウント時に -R 回リトライして，その後の NFS リクエストでは -x 回再送信すると．
で，再送信の間隔はデフォルトでは自動決定されるらしい（けれどもデフォルト値は不明）．

まだ read.cgi へのアクセスが固まる（NFS が刺さる）みたいですね......

>　　　　 mount retries the request up to the count specified in the
>　　　　 retry=n option. (Note that the default value　for　retry
>　　　　 differs between mount and automount. See the description
>　　　　 of retry, above.) Once the file system is mounted,　each
>　　　　 NFS request made in the kernel waits timeo=n tenths of a
>　　　　 second for a response.　 If　no　response　arrives,　the
>　　　　 time-out　 is　 multiplied　by　2　and　the　request　is
>　　　　 retransmitted. When the number　of　retransmissions　has
>　　　　 reached　the number specified in the retrans=n option, a
>　　　　 file system mounted with　the　soft　option　returns　an
>　　　　 error　on　the request; one mounted with the hard option
>　　　　 prints a warning message and continues to retry the request.

↑は Solaris での解説ですが

>　　 mount_nfs [-23NPTUbcdiLls] [-D deadthresh] [-I readdirsize] [-R retrycnt]
>　　　　　　　 [-a maxreadahead] [-g maxgroups] [-o options] [-r readsize]
>　　　　　　　 [-t timeout] [-w writesize] [-x retrans] rhost:path node

という FreeBSD のオプションを当てはめると↓でいいのかなぁ......

retry=n -> -R retrycnt
timeo=n -> -t timeout
retrans=n -> -x retrans

うーむ、

原因切り分けのため、
SMP やめて、single CPU モードにしてみる予定。< live23b/news20b

http://qb5.2ch.net/test/read.cgi/operate/1149989815/221
1 CPU で 64-bit と，SMP で 32-bit と，どっちがいいか......

フロント 強制リブート中。

いったん NFS はずします。

>>859
32bit にするのは、OS の再インストールとか
各種設定しなおしとか、ちと面倒かなと。

それよりは、原因究明したいですね。
将来を考えた場合。

tiger507 上がってこない。

NFS が影響を受けて止まっていて(フロントのF22がささっていた)、
強制リブートで上がってこなくなった。

例の KVM との相性(tiger5xx はリブート時にたまに止まることがある)、
による影響か。

負荷で落ちてるんじゃないってのがなぁ。

5.2.1R の時の悪夢再びか。

NFS は，どこかで localhost 上でマウントしてじっk(ryするとか．

>>864
家の環境でやってみようかなと。

amd64 問題は、手元に amd64 なサーバが1台もないので、
ちと、苦しいですね。

リブートしたら、作業の運びで。

…しかし Google してもヒットする事例がないっぽい、というのも、
5.2.1R の時とよく似ている、とは言えるんだが。

今度は i386 では問題ない、というのも、どうも。

優先度の高い、解決すべき問題は2つ:

1) NFS の設定を詰める

これは、テスト環境を自宅に確保する方向で。

2) FreeBSD 6.1R/amd64 の不安定動作(突然のハングアップ)の原因究明と解消

最新のstableにするも効果なし。
まずは SMP をやめてみる方向で。

>>868
うちのFreeBSD＋amd64は特に不安定になること無いですよ。
負荷のかかり方が違うからなんともいえませんが。。。

1台自宅に確保して、 FreeBSD 6.1R を入れた。

CPU: Intel Pentium III (754.71-MHz 686-class CPU)

これで、自宅に環境作れそうなので、NFS の試験と詰めを急ぎ実施予定。

>>869
構成を教えてもらえると、助かります。

motherboard
CPU
OS Version
memory
HDD

特に、
・dual CPUかどうか
・ディスクがSCSIかどうか

あたり。

>>871
motherboard：Gigabyte　GA-7A8DW
CPU ：　Optron240　×　2
OS Version FreeBSD 6.1R-p1 （SMP）
memory ：　512　×　4
HDD ：　SCSI　HITACHI　HUS157336EL3600（U320、15000rpm、3.6G）　×　2

です。

いい鯖だなぁ

なんかありますかねぇ......
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=6129+0+archive/2006/freebsd-amd64/20060521.freebsd-amd64

>>872
なるほどです。

SCSI controller は、、、。

>>875
SCSIはadaptecの39320を使っています

>>876
ahd ですか。

つまり、cobra のと違うっすね。(mpt)

>>877
そうですね。

/usr/src/sys/nfsclient/nfs_socket.c

うわーん、この#if 0 〜 #endif はなんだよぉ。

if (nmp->nm_tprintf_initial_delay != 0 &&
(rep->r_rexmit > 2 || (rep->r_flags & R_RESENDERR)) &&
rep->r_lastmsg + nmp->nm_tprintf_delay < now.tv_sec) {
rep->r_lastmsg = now.tv_sec;
nfs_down(rep, nmp, rep->r_td, "not responding",
0, NFSSTA_TIMEO);
#if 0
if (!(nmp->nm_state & NFSSTA_MOUNTED)) {
/* we're not yet completely mounted and */
/* we can't complete an RPC, so we fail */
nfsstats.rpctimeouts++;
nfs_softterm(rep);
continue;
}
#endif
}

nfs_socket.c って、current と stable/release でかなり手が入っているのね。

HEAD は 1.141 で、RELENG_6 や RELENG_6_1 は 1.125.2.9 とか言っているし、
>>879 にあった不可解な #if 0 〜 #endif は、なくなっている。

NFS まわりの、ソースの diff (RELENG_6 と CURRENT)を眺め中。>>880

mutex 系の lock/unlock とかが恐ろしく変わっていますね。
NFS 部分だけ、そのまま current のを持ってくるというわけにはいかない予感。

で、これだけ mutex 系のところで手が入っているということは、
NFS 部分に amd64/SMP だとおかしくなるバグがいる可能性も、考えられるなと。

…これだと、現状では、

1) 過去ログは offlaw.cgi や ２ちゃんねるプロバイダ用プログラム、
公式 p2 用プログラムを一式バックエンドに proxy で転送することにして、
まずは妥協する。(= 削除の呪文と同じ取り扱いにする)

ことにして、

2) バックエンド側の NFS の設定をやめて、SMP 設定のままでまずは動かしてみる(amd64も)

ことにし、

3) 次に、SMP を切る等の別のアクションを起こす方向で考える(amd64)

で、いくことにしようかと。

ちなみに自宅での NFS の実験ですが、
いろいろ試行錯誤しているものの、いまだ not responding から
そのまま異常終了してくれる状況になるには至らず。

で、そうなると、read.cgi での過去ログの検出を
直接ファイルを検索することで実現しているので、
ここの部分を、なんとか解決する必要があると。

(つまり read.cgi では「datがない」になってしまう)

で、以前はここを、

過去ログを全フロントに転送する

ことで乗り切っていました。

しかしこれは、過去ログが溜まってくるとシステムのコストが加速度的に上がってしまい、
だめだということが既に判明している

と。

さて、どうするのがいいのか。

>>884 はもちろん、フロントの数がスケールしない、
という意味でも、筋が悪いと。

と言うことは雪だるま特化型のread.cgiを考えないといけないんですね
まずは直接検索から間接検索に切り替える方向とか

>>886
既に read.cgi はフロントで動いているわけです。
特化型というか、過去ログ部分もきちんと雪だるま対応したバージョンってことですね。

雪だるまサーバの過去ログ部分の現状:

・offlaw.cgi 経由での入手: 可能。offlaw.cgi はバックエンドで動作(設定変更した)
・２ちゃんねるプロバイダでの入手: 可能なはず(未確認)。プログラムはバックエンドで動作(同上)
・公式 p2 / モリタポ利用での入手: 同上

・read.cgi での表示: 「dat が存在しません」になってしまう(実際には存在している)

なお、live23b は現在設定変更中。
変更でき次第、上記になる予定。

live23b / news20b 工事完了のはず。>>888

NFSについて:

フロントからの NFS は全面的にオフの状態。
ex15 もオフにする設定は入れたので、次はオフの状態で立ち上がる予定。

>888-889
まだ「datが存在しません。」になります。
反映されてないのかなぁ？

>>891
んーと、落ち着いて >>888 を再度、読んでいただけると。

>892
了解しました。
それで正解なんですね

live23落ちた

>>894
ううむ、、、。

リブート要請出します。
single CPU modeへの以降手配を。

誤爆スマソ

cobra2244 は上がったら、

1) 6.1R に戻す
2) single CPU mode への移行

のてはずで。

cobra2244 は、立ち上がってこない状態になった模様。

-stable にして、カーネルを 6.1R に戻したのが悪かったのかも。

514 名前：root▲ ★[] 投稿日：2006/06/11(日) 20:55:44 ID:???0 ?#
live23b は、立ち上がらない状態になった模様。

数度リブートしてもらいましたが、立ち上がらないです。
リモート KVM が使えるようになるまで、復旧作業ができない状態。

ううむ、、、。

いつもおつかれさまだお。
（　^ω^）つt■ 　コーヒーどーぞだお

で、現在の状態で http://live23.2ch.net/livetbs/ とかをアクセスすると、
結構な時間、待つ模様。

httpd のスロットが、ふさがってくるかも。

そうか、一度 503 になれば大丈夫なのかな。>>901

そういう仕様か、、、。< mod_proxy

…見ていると、live23b は起きようとして
たまに ping かかる状態になっていますね(それでまた落ちてしまう)。

これが、>>902 の原因かも。

現状:

・tiger507 = ex15: ダウンしたまま。
現地に状況調査 & 確認依頼中

・cobra2244 = live23b: たまにping通るものの、ssh通るまでに至らず、
再度落ちる。

現地に状況確認 & 状況確認中。
KVM 経由でのシングルユーザオペレーションが必要な予感。

・上記2台にリモートアクセスするための remote KVM へのアクセスが支障中。

現地に状況確認 & 復旧依頼中。

いやああああああああああああ

rootｻｿ お疲れ様です。

live23b これからの展開:

・>>897 を実施
・安定するなら、それで運用
・力(処理能力)が足りないようなら、涙を飲んで 6.0R に戻し、dual CPU へ

あたりかと。

stable 版を使うのは、特に amd64 ではリスクが大きいと。

6.0-Rにすると、Apacheのバグがでるんじゃないの？

>>908
出る可能性ありますね。

あと、ex14 で起こっていたような、
ping かかるけれども他のサービスが全部死ぬ、
というパターンになることがありえます。

(6.1R/amd64 の場合、ping もかからなくなるのが違う)

1) offlaw.cgi のための転送はやめる
2) その上で offlaw.cgi をどうするか考える。
3) read.cgi をどうするか考える。

な手順かと、

まずは転送&同期を止めましょう。

>>910
それ(過去ログのための転送&同期)は、NFS にした時点で既に全廃しているです。

>>884- 以下あたりは解決しているということ?

>>910
転送&同期？
offlaw.cgiはすでにバックエンドで動作してるけど

んで
それは事の原因じゃないということ?

>>911
when ?

今、同期とっているのは、

・板名/SETTING.TXT (更新されてなければ取り直さない)
・板名/kakolog.html (同上)
・キャップデータ等

になります。

>>912 は、NFS にする以前の設定です。

で、ちょっと前に NFS の設定に変えた。
この時点で転送&同期を全廃したわけです。(>>911 >>915)

現在、>>910 の状態になっていると理解しています。

…とここまで書いてわかった。

>>910 は、 offlaw.cgi のリクエストをバックエンドに転送するのも、やめるべし、
と言っていますか。

今の設定のまとめ。上のほうにもあるけど。

1) 過去ログのデータはバックエンドにある。フロントへのデータ同期はしていない。
2) バックエンドにある過去ログデータの NFS での共有は、今日やめた。
3) フロントで受け付けた offlaw.cgi のリクエストは、バックエンドにフォワードされ、
バックエンドで offlaw.cgi が実行され、フロント経由で結果が戻る。
4) フロントで動く read.cgi は dat 落ちしたデータについては「dat が存在しません」エラーになる。

>>916
言ってマース。

付け焼刃はやめよう作戦。
多数の選択肢を用意して検討し一番良いと思われるのを
少々(時間的、人的)コストはかかってもやろうよ作戦。

それまでは offlaw.cgi は動かない read.cgi もいまいち
もいたし方がないかと、

付け焼刃にしてから多数の選択肢を用意して検討し一番良いと思われるの
やっても問題はないでしょ

>>918
そういうことですか。
把握しました。

とりあえず＊今は＊、過去ログは致し方がないということにすると。

決してそうは思いません
最悪手

>>919

>>919 もありかもですが、このへんは、
判断のしどころなのかなと。

>>920

よろしくです。

さすがに十数人不眠不休で実況サーバのおもりをすることの意義を見出せません
かといって動かしたいのは山々で、

不安定要素は全部排除。
最小限の機能だけ動かす。

>>922
絶対無いです。

offlaw.cgi @live22
offlaw.cgi @live23b
offlaw.cgi @news20b

止めてきます。

>>923
納得したです。

offlaw.cgi をはじめとする過去ログ関連の転送、
止める作業に入ります。

offlaw.cgi @live23b　はサーバが落ちていたりするのかな?

offlaw.cgi @live22
offlaw.cgi @news20b
は止めました。

offlaw.cgiが不安要素だなんて初耳。
おじちゃんあんまり最近の動き理解してないんでしょ。
「過去ログ」って言葉を不安定要素と決め付けてるように見えるぜ。

理解していないのはあ・ん・た。

有無を言わせません。
指令です。

>>925
フロントからの offlaw.cgi の転送を止めました。

live23b = cobra2244 は、現在サーバダウン中です。

この場合のとるべき戦略は、
「引けるとこまで引く」です。

つまり　雪だるまサーバを止める。

しかし・・・
あとは自分で考えてちょ
いちいち説明してなんかいられません。

>>927

ちなみに、

cobra2244
tiger507
はリブート挑戦していますけど上がりません。

cobra2244 は作業中に、私がへまをしていまいちな設定になっている可能性が
一番大きいです。ごめんなさい。
リモートオペレーションが必要な状況と思われます。

tiger507 は他のフロントと同じ通常のリブートプロセスで
上がらなくなりました。原因はまだ解っていないです。>>931

Sean がフェラーリを飛ばして向かっているところかと、
他の人@PIE では手にあまっている状況。

offlaw.cgi がどうなってるか知らんけど
●もってても永久に過去ログが読めないってのはやめてね。

よくわかんないなあ
とりあえず向こうのスレで討論会らしいので移動しますね

>>933
了解です。
# フェラーリ。

ex15 ってジンギスカンが自動で組み込まれない?

ん?
違うのか、、、

ちょっとごにょごにょ

私は cobra2244 のほうの作業します。

ex15 は現在、上がっている状態(で、dat がない状態)
と認識。

public_html/news4vip/ が私から&cgiから見えない予感。

cgi@tiger507　から news4vip が見えない。

SSHでログインしたとき ls で news4vip は見える。
しかし cd で入れない。状況。

FTPも同様。

owner だかなんだかが違うんでないかい? >>939

>>941
確認します。

ちなみに http で 403 です

rootﾀﾝ頑張ってね(´・ω・`)

作業完了のはず。< ex15

他のフロントよりも、メモリディスクを拡張しました。
dat も流し込んだので、あとはピロリさんのほうで作業できると思います。

ksk

何があったら呼んでくださいです。

cobra2244 の作業していますので。

はーい

復帰しました。 < news4vip

ex15 は、復帰かければもとに戻るはず。

1150042408.dat<>復活！！！！ (67)
1150042493.dat<>【しょこたんうざい】中川翔子反対同盟 (1)
1150042492.dat<>RPGツクール再生 (1)
1150042491.dat<>うらっしゃあああああああああああああああああああああ (1)
1150042432.dat<>(ﾟдﾟ)ん？ (4)
1150042480.dat<>まだ復活しないのか……… (3)
1150042440.dat<>復活？ (5)
1150042488.dat<>家出をしようと思う (1)
1150042469.dat<>ﾆｺﾆｺ（´＾ω＾｀）ﾆｺﾆｺ (3)
1150042486.dat<>スクエニ垂れ流し　〜 気に入らないDJは叩こうぜ 〜 (1)
1150042485.dat<>復ッ活ッ (1)
1150042460.dat<>ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!  (3)
1150042484.dat<>VIP復活記念大喜利 (1)
1150042483.dat<>V　I　P 始　ま　っ　た　な (1)
1150042482.dat<>自治スレッド (1)
1150042446.dat<>やほおおおお (2)
1150042479.dat<>　　　　ド　　ラ　　ゴ　　ン　　圧　　縮　　　 (1)
1150042478.dat<>　　　　　　　　　 (1)
1150042465.dat<>ばーか (3)
1150042477.dat<>おい！！！最速1000目指すぞｗｗｗｗｗｗｗｗ (1)
1150042429.dat<>ああああああああああああ (3)
1150042476.dat<>俺の空 (1)
1150042448.dat<>　　　　　　ド　ル　ビ　ー　サ　ラ　ウ　ド　ン (2)
1150042434.dat<>F1世界選手権第8戦イギリスグランプリ　 (2)
1150042467.dat<>なんもねーーーーーーーーｗｗｗｗｗｗｗｗ (1)
1150042463.dat<>ＦＦ語ろうぜ (1)
1150042458.dat<>きたおきたよ！！！１ (1)
1150042436.dat<>一番乗りｗ (2)

http://ex15.2ch.net/news4vip/subject.txt

200 OK

>950
VIP復帰してきます〜

確認しました。>>949

ex15 は ok かな?

過去ログは......やはり過去ログ専用バックエンドを作ってそっちに分離ですかね．
で，そっちは手堅い設定にしておくと．過去ログにパフォーマンスはさほど必要ではないでしょうし．

>954
復帰確認しました。

んじゃ
ex15 は完了。

cobra2244 リモートコンソールつかめました。
作業入っています。

cobra2244 では、stable 版の mountd (NFS関連コマンド)を実行すると、
そこでカーネルパニックを起こしていることが判明。

カーネル・ユーザランドとも、6.1R の状態に戻すことに成功しました。

これから、NFS なしの状態に移行する作業します。

さきほどは mount (NFSのためのコマンド)でパニックしていました。
やはり NFS 周りは、FreeBSD では鬼門のようです。

サーバ部分から NFS を完全になしの状態にして、切り分けを実施。

news20b / live22 も NFS なしの状態に移行するため、
一度ずつ、リブート入れます。やる前には別途連絡予定。

>>960 の mount は、mountd ですね。

雪だるまフロント・バックとも、NFS の設定を消しました。
さようなら。FreeBSD ではもう二度と会うことはないでしょう。> NFS

…ということで、今日の復旧作業はほぼ終了という認識。

>>962 にああ書いたけど、しいてあげるなら、
NAS で使って、1台だけから mount するぐらいが「最大限の譲歩」ですかね。

少なくとも、複数サーバでファイルを共有する手段としては、
もう 2ch では金輪際、使うことはないかと。

さようなら、

ということで 実況関連板&なゅー速で
read.cgiの挙動がおかしかったり、●が使えない状況です。

次はこれをなんとかするということで、

>>運営のみなさん
今週末は、お疲れ様でした。

現状の整理:

・NFS の設定は雪だるまから永久追放
・i386 アーキテクチャは、6.1-RC2 以上にすることでほぼ安定に動作
・amd64 アーキテクチャは、安定動作の確認まだとれず => 原因究明中
・過去ログ倉庫の参照機能が現在動作していない >>964

>>962
> さようなら。FreeBSD ではもう二度と会うことはないでしょう。> NFS
何使ってるんすか？

amd64 はフロント&バック
それぞれ一台ずつ投入されているんでしたっけ?

明日がやべぇ・・・大丈夫なのだろうか？

ちと覚悟はしておけ、

>>968
フロント: i386 5台(新tiger3台、旧tiger2台)
バック: i386 1台(live22)、amd64 2台(news20b, live23b)

そういえばフロントのtigerも64bit試せますね

>>971
フロントのうち旧tiger1台は、現在 ex15 として臨時稼動中。

確かに新 tiger には、
その気になれば、amd64 と同じ 64bit OS を入れられます。(>>972 のとおり)

現状フロントは安定していると思うので、何もしない。
ということで、

旧ex14(cobra2247?) が帰ってきたら、現ex15(tiger507)をフロントに戻して
フロント五台体制。

バック amd64 が安定しないようならバックは全部tigerにするとかがあるかもということで、
今のところ様子見かな、

>>975
了解です。そんなところですね。

現 ex14 = oyster901 ですね。
cobra2247 は news20b になりました。

oyster901だった、、

そういえば oyster901 に付いているHDDはもう処分してもいい状態でしたっけ?
月曜日に新しいHD発注かかるんで到着と同時に付けてもいいか?
という質問なんです。

>>977
memories への収容は完了しているです。

ということで、装着OKと。

りょうかいですー

ということで、73G HDD のレイアウトはこれで。

・単純に、/home と /var を大きくする
・他は従来の cobra 仕様と同一

da0 (73G)

/dev/da0s1a 256M /
/dev/da0s1d 4G /tmp
/dev/da0s1e 4G /usr
/dev/da0s1f 残り全部 /var

da1 (73G)

/dev/da1s1d 全部 /home

OS は、迷うところですが、
まずは今の oyster901 と同じ、FreeBSD 6.0R/amd64 でいこうかなと。

あ、スワップエリアを忘れました。修正版。

da0 (73G)

/dev/da0s1a 256M /
/dev/da0s1b 4G swap
/dev/da0s1d 4G /tmp
/dev/da0s1e 4G /usr
/dev/da0s1f 残り全部 /var

da1 (73G)

/dev/da1s1d 全部 /home

;live23b 確認します。

なんか、原因が別にあるような気もする。
あまりにも落ちすぎ。

また実況が・・・・

ひたすら落ちた時間のログ分析する鹿

CPU 0 が 51℃ で、CPU 1 が 49℃ みたい。
これは、どうなんだろう。

>986
2度くらいなら測定誤差かと

まずは、single CPU のカーネルに換えます。

>>987
いや、高いとか低いとか。

電気代ケチってエアコン消してないか？

>>986
PCなら誤差の範囲だと思うけど鯖の場合はﾜｶﾝﾈ

single user で起動中。

5.4R は安定していたんだよなぁ。< ex12 / ex13
もう1年以上、リブートなし。

そう考えると、新しい機能を減らす方向かな。

mpsafevfs を殺そう。< live23b

%sysctl -a | grep mpsafe
debug.mpsafevfs: 0
debug.mpsafenet: 1
debug.mpsafevm: 1

原因の切り分けが必要ですね。

確かに「ハングアップ癖」はあったけど、ここまでではなかったような。
今度はもうさすがに伝家の宝刀「single CPU mode」だなと。

それでもだめなら、さすがにハードウェア方面を疑うしかないかなと。

個人的には、i-RAM とかは
ジンギスカンII にするのの代替(dat 部分だけ)というかんじに思うですね。

通常の動的なファイルは、通常ジンギスカンで特に問題ないので、
ライブな dat を置く場所、ぐらいですか。

HDD よりは高速だけど、メインメモリには劣ると。
というか SunOS さんも書いていますが、たぶんこれは「高速な HDD」ぐらいのしろものかなと。

>>996 は誤爆ですね。

次スレ、立ててきます。

2ch特化型サーバ・ロケーション構築作戦 Part22
http://qb5.2ch.net/test/read.cgi/operate/1150052911/

ぬわわわ

1,000

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