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

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

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