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

**root▲ ★** · NG

2ch特化型サーバ・ロケーション構築作戦のスレッドです。

・２ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更関連の各種作業や調整事項
・２ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携

等を取り扱います。

現在、複数サーバによる連携により、
サーバ能力のさらなるスケールアップをめざすための「雪だるま作戦」が進行中です。
しかし、問題はあらゆる意味で山積の状態です。

特に、成熟度を高めたリリースであるはずの FreeBSD 6.1R において、
amd64 アーキテクチャでの突然のハングアップの不具合が、深刻な問題となっています。

**動け動けウゴウゴ２ちゃんねる** · 2006/06/12(月) 04:10:19

にん

**ｒｅｆｆｉ@報告人 ★** · 2006/06/12(月) 04:11:58

>1
乙～
前スレ1000もきれいに決まったようで

**動け動けウゴウゴ２ちゃんねる** · 2006/06/12(月) 04:12:03

999 ：たにし ★ ：2006/06/12(月) 04:09:13 ID:???0
　　ぬわわわ

**root▲ ★** · NG

**動け動けウゴウゴ２ちゃんねる** · NG

>>1
乙

**動け動けウゴウゴ２ちゃんねる** · 2006/06/12(月) 04:13:25

>>1
ぼみょ

＞ぬわわわ
流行るといいね

**動け動けウゴウゴ２ちゃんねる** · 2006/06/12(月) 04:13:54

前1000ﾜﾛﾀ

**動け動けウゴウゴ２ちゃんねる** · 2006/06/12(月) 04:16:52

むぎゅに対抗でもしてるのかとｗ＞ぬわわわ

**root▲ ★** · NG

>>4
1000 のほうが（りゃ。

前々スレからの課題
・削除関係の呪文の雪だるま対応 (まずはバックに転送して一時しのぎ中)
・バックエンドの安定稼動 (i386 版はほぼ安定、amd64 版は格闘中)
・matd を用いた受付の安定稼動 (ほぼ解決、フロントエンドの自動切り離し要)
・mod_cache の導入によりバックエンドの負荷を下げる (squidとのマッチング要調査)

・電源食い杉どうしよう (やりくりで何とか3台+5台まで拡張、しかし根本解決は 365main)
・携帯フルブラウザからの書き込み対応 (解決、更新のしくみも確立)

重要な課題
・効率の良い金色会員維持 (おごってもらう話があったような)
・家庭の保守 (・・・・・・・・・・・・)

**root▲ ★** · NG

live23b/news20b (amd64 版バックエンド)のこれまでの経緯まとめ:

・新規投入、FreeBSD 6.1R/amd64
・投入時に、kbdmux 機能ありだと、ちょっとした負荷でシステム全体がハングアップする症状が判明
・kbdmux 機能をはずしたところ、上記は解決、本格投入
・しかしその後も数日に1度程度、負荷に関係なくシステム全体のハングアップが発生
・最新の 6.1-STABLE に上げたところ、mountd 実行時に page fault で panic する症状が発生
・6.1-STABLE をあきらめ、6.1R に戻した
・その後も live23b において断続的にハングアップが発生
・ちなみに同一ハードウェアにおいて1年以上、FreeBSD 5.4R/amd64 で安定稼動実績あり
・同一ハードウェアでは、FreeBSD 6.0R/amd64 でも稼動実績あり、
ただし 5.4R ほどの安定さはない。でも ex14 だったから、負荷理由かもしれない
・現在、5.4R での安定稼動を見て、6.0R で有効になった機能、
mpsafevfs (ファイルシステムの処理の mpsafe 化)を殺して、問題の切り分け作業中。@ live23b

**root▲ ★** · NG

これ以外の前スレのサマリは、明日以降ということで。

さすがに、今日はそろそろ限界が近いかも。

**root▲ ★** · NG

news20b も、mpsafevfs を殺した。

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

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

株価【800】 ▲ ◆cZfSunOs.U · 2006/06/12(月) 04:46:16

乙ですた

**動け動けウゴウゴ２ちゃんねる** · 2006/06/12(月) 04:52:39

´･ω･`)つ旦~旦~旦~旦~

**動け動けウゴウゴ２ちゃんねる** · 2006/06/12(月) 07:00:44

前スレ
・家庭の保守 (・・・・・・)
今スレ
・家庭の保守 (・・・・・・・・・・・・)

「・」の数が、何げに倍になってるのがなんともかんとも(´･ω･`)

**動け動けウゴウゴ２ちゃんねる** · 2006/06/12(月) 09:19:25

http://qb5.2ch.net/test/read.cgi/operate/1145114275/935
向こうのスレってどこですか？

**動け動けウゴウゴ２ちゃんねる** · 2006/06/12(月) 09:44:44

前スレにあったSCSI controllerの話はもう続かないの？

**動け動けウゴウゴ２ちゃんねる** · 2006/06/12(月) 10:40:50

>>17
それは、とある場所にある秘境。
偶然迷い込むこともあれば、歩き回って行き着くこともある。
さぁ、君も探索に出るんだ。その内行き着くかも知れない。

**動け動けウゴウゴ２ちゃんねる** · 2006/06/12(月) 12:25:44

>>17
その国の名はガンダーラ､どこかにあるユートピア

よろしく～ネッ!!

**ピロリ** · 2006/06/12(月) 12:51:36

うーん
報告したかどうかも忘れちまった。

再度、
> (現在)
> +ex14.2ch.net:206.223.151.225
>
> (変更後)
> +ex14.2ch.net:206.223.151.230
>
これおわった

**root▲ ★** · NG

>>21
どもです。

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

oyster901 はたぶん、移設 & HDD 交換が合い前後して、
というかんじですかね。

よみがえる時は ex16 になると。

**root▲ ★** · NG

ex11 に移転した campus と keiba 、ジンギスカンになっていないような。

**動け動けウゴウゴ２ちゃんねる** · 2006/06/12(月) 14:41:47

>>16
それはプログレスバーなんですよ、きっと

**ピロリ** · 2006/06/12(月) 14:42:08

必要ないかな? と思って、、さぼった

のバレタ。

**動け動けウゴウゴ２ちゃんねる** · 2006/06/12(月) 14:43:11

>>25
>>25
>>25

**root▲ ★** · NG

>>25
ここはひとつ。

とは言っても、morningcoffee はジンギスカンIIだから、/md の容量がちょっと足りないですね。
先に私のほうで拡張工事します。

**ピロリ** · 2006/06/12(月) 14:45:17

keiba は土日があるから
やっぱジンギスカンの方がいいっすね、

つうことで campus keiba ジンギスカンⅠにしてきます。

**ピロリ** · 2006/06/12(月) 14:45:44

まってますー >>27

**root▲ ★** · NG

>>27
今見たら、問題なさげですね。

作業可能です。< ex11

**ピロリ** · 2006/06/12(月) 14:49:09

はーい

**ピロリ** · 2006/06/12(月) 14:53:01

>>28
完

**root▲ ★** · NG

>>32
おつでした。

**root▲ ★** · NG

debug.mpsafevfs=0 は、外れだったのか。

**root▲ ★** · NG

Submit a FreeBSD problem report
http://www.freebsd.org/send-pr.html

そろそろ、まじめに送らないといけないと。

株価【600】 ▲ ◆cZfSunOs.U · 2006/06/12(月) 21:22:44

今回の WC は「勝ちに行く」ってことだったと思うんで（それでバック追加して live23 新設ってことでしたし），
live23 は実績のある手堅いバージョンで行く一方で，その代わり news20 には人b(ryになって頂く方向とか，
そんな感じでどうかな，とか......

**root▲ ★** · NG

>>36
5.4R とか 6.0R にバージョンダウンする、か、
i386 にするか、ということですか。

i386 にするのは、現地での(少なくとも)CD-ROMの差込と除去が必要になると。

**root▲ ★** · NG

# Workarounds for some known-to-be-broken chipsets (nVidia nForce3-Pro150)
device atpic # 8259A compatability

これは、関係ないのかなぁ。(デフォルトで有効)

**動け動けウゴウゴ２ちゃんねる** · 2006/06/12(月) 21:45:10

ここは片方のCPUでどれだけ行けるかを見てみようぜ
もう時間ないけど

**root▲ ★** · NG

>>39
single CPU mode のカーネルは、作ってはあるので、
入れ替える作業そのものは、できる状態にあります。

しかしまずは、現状でいくかんじで。

株価【600】 ▲ ◆cZfSunOs.U · 2006/06/12(月) 22:23:51

FreeBSD にもポートされてるらしいですが，使えますかね......
http://docs.sun.com/app/docs/doc/819-0395/6n2qtspga?a=view

**root▲ ★** · NG

次上がったら、single CPU mode に移行。
これは決定で。< live23b, news20b

**root▲ ★** · NG

ここまでの状況:

バックエンドはまだ、目分量で半分も使われていない状態だった。
フロントは、あふれた。bbs.cgi (speedy_backend) の起動数(-M)を調整。
1フロントの1バーチャルホストあたり 24 に制限。(-M24)

debug.mpsafevfs=0 は効果がなかった。on FreeBSD 6.1R/amd64

**root▲ ★** · NG

NFS をはずしたおかげで、
バックエンドサーバ1台のダウンが全体を完全に止めてしまうことは、
一応避けられるようになった模様。

**root▲ ★** · NG

live23b single CPU mode に移行しました。

mpsafevfs はWC試合終了後に再度有効にするということで。

**root▲ ★** · NG

live22 (tiger なバックエンド)は、パンク状態。
LA=500 とかなりました。落ちてはいないものの、めいっぱいという感じ。

**root▲ ★** · NG

>>46
live22 はかなりめいっぱいという感じだけど、
ブレーメンに隙間を出さないというのは、さすがという感じかも。

**root▲ ★** · NG

LA=780 @ live22

リモートログインはほとんど無反応になったけど、ちゃんと耐えているのか。

**root▲ ★** · NG

むこう書けないんで、

news18
ex13

Saborin 発動、IsKoukoku カット。

**root▲ ★** · NG

ex13 は LA=35 ぐらい。
大丈夫でしょう。

news18 は LA=60 超えましたが、
>>49 発動で下がりました。
大丈夫でしょう。

**root▲ ★** · NG

ex11 IsKoukoku カット。(Saborin は常時発動済み)

**root▲ ★** · NG

ex11 LA 10ぐらいになりました。
さっきは200以上あった。

大丈夫でしょう。

**root▲ ★** · NG

で、携帯系の負荷、予想通りむちゃくちゃだなぁ。

**動け動けウゴウゴ２ちゃんねる** · NG

　掛けまくも畏きイザナギの大神　　　◇　　　　　　　ミ　◇　祓へ給ひ清め給へと
　筑紫の日向の橘の　　　　　　　　◇◇　　 /￣|　　◇◇　　まをすことを聞こし召せと
　小戸の阿波岐原に　　　　　　　◇◇　＼　|＿_| ◇　　　　　恐み恐みもまをす。
　禊ぎ祓へ給ひし時に　　　　　　　　　彡　O(,,ﾟДﾟ)　/..　　　　2ch稼動サーバ・ロケーションの
　なりませる祓へ戸の大神たち　　　　　　(　　Ｐ `O 　　　　　常盤かきはに幸くと
　諸々の禍事・罪・穢れあらむをば　　／彡#＿|ミ＼　　　　請ひのみ奉らくとまをす
　　　　　　　　　　　　　　　　　　　　　　　　 </｣_|凵_ゝ

**動け動けウゴウゴ２ちゃんねる** · 2006/06/13(火) 00:18:00

やはり課金システムにして蹴って行かないと駄目なんジャマイカ

**動け動けウゴウゴ２ちゃんねる** · 2006/06/13(火) 00:31:36

●と株主優先にするとか

**動け動けウゴウゴ２ちゃんねる** · 2006/06/13(火) 00:33:05

削り落として負荷削減をするのはよろしくない。

**動け動けウゴウゴ２ちゃんねる** · 2006/06/13(火) 00:40:30

恒常的な収入があるといいのだが。

広告の収入が増えないかな。
アングラなイメージはだいぶなくなってきたと思うのだけど、
エロ広告ばっかりでちょっと引く。

**動け動けウゴウゴ２ちゃんねる** · NG

負荷問題はいずれ解決しなけりゃならん問題になるんだし
一時しのぎ程度のものは問題を先送りしてるだけかと．
お金で解決できりゃ良いけど，技術的にそういうわけには
いかない部分も出てくるだろうし．

雪だるま周りはどういう風に解決するか楽しみだったり……

**root▲ ★** · NG

>>45
live23b
news20b

両サーバとも、single CPU モードに移行。
mpsafevfs は、デフォルトに戻した(有効)。

これで安定してくれるといいけど。
で、安定するようなら、それはそれで問題なわけだが。

**動け動けウゴウゴ２ちゃんねる** · 2006/06/13(火) 01:15:35

>>57
三年前の状態に戻すだけだよ､パケ代定額前の状態に
腹八分目って大切だと思うよ

実際にスレ立て制限とか書き込み時間制限とかで削ってる訳だからさ

株価【600】 ▲ ◆cZfSunOs.U · 2006/06/13(火) 06:26:57

バックエンド (live22) もついにアップアップ状態まで逝きましたか．
それに対応するとしたらやはり mod_cache ということでしょうけど，
フロントの httpd でこんな設定すれば BG (Squid) 問題の対策できるかなぁ......

SetEnvIf Remote_Addr ^206\.223\.151\.(55|57)$ BlackGoat
Header append Cache-Control proxy-revalidate env=BlackGoat

フロント側としても，毎回バックエンドにお伺い立てるよりは
ローカルキャッシュ使えた方が軽くなるかなぁ......

株価【600】 ▲ ◆cZfSunOs.U · 2006/06/13(火) 07:26:53

で，携帯は中期的には u.la に期待するとして，短期的に今の c を延命させるとすると......
現状 Squid でキャッシュさせてるのは生の dat や subject.txt だけなんですよね？
となると，PHP 出力側も mod_cache でキャッシュさせてみるとか．
んで，dat 等をフェッチする際に得られる Last-Modified をそのまま PHP 出力でも吐いてもらうと．

**root▲ ★** · NG

たぶん、バックエンドの少なくともプライベート側のほうは、
Apache ではないのを使う( thttpd とか )方向かなと。

で、mod_cache の件ですが、前から気になっているのですが、
mod_cache 入れた場合、書いた直後に dat を読むタイプの専用ブラウザとかで、
ちゃんと自分の書いたレスが読まれるようになるのかしら。

直感では、キャッシュが働くので、昔の NFS で動かした時のように、
反映に遅延が発生するような気もします。

◆XejmK2zG7E · 2006/06/13(火) 11:41:51

お世話になっております。株式会社jig.jpの菊池です。
サーバ移設のためIPアドレスが変更になります。

詳細は下記URLからご確認ください。
http://br.jig.jp/pc/ip_br.html

宜しくお願い致します。

**root▲ ★** · NG

>>65
確認しました。

これは、すぐに変更・反映してしまってよろしいでしょうか。

**root▲ ★** · NG

…というか、CIDR 的には 1ブロックの追加ということですね。

いってきます。

**root▲ ★** · NG

210.188.205.92/30 を jig ブラウザ用 CIDR ブロックとして追加しました。
10分程度で反映されるはず。

株価【400】 ▲ ◆cZfSunOs.U · 2006/06/13(火) 12:45:52

>>64
>mod_cache 入れた場合、書いた直後に dat を読むタイプの専用ブラウザとかで、
>ちゃんと自分の書いたレスが読まれるようになるのかしら。

これは設定次第かなぁ．

[案1: CacheMaxExpire 1, CacheDefaultExpire 1, CacheLastModifiedFactor 1]
　　最大1秒間のディレイは発生しますが，瞬間的な怒濤のようなアクセスに対し
　　結構効果はありそうな気はします．で，書き込んだ後1秒以内にリロードされると
　　自分のカキコが反映されない可能性はあるので，これを解決するなら
　　専ブラ作者さんのご協力も頂いてリロードまでに1秒間ディレイを入れて頂くとか．

[案2: CacheMaxExpire 0, CacheDefaultExpire 0]
　　毎回必ずバックエンドに問い合わせるので，案1ほどの効果は見込めないかも知れません．
　　ただ，mod_cache なしならバックエンドからのレスポンスの多くが 200 になるところを
　　304 にすることは期待でき，その分バックエンドの負担は軽減できるかも．

>バックエンドの少なくともプライベート側のほうは、
>Apache ではないのを使う( thttpd とか )方向かなと

304 をちゃんと扱えさえすれば，あとはスタティックファイル専門で
超高速・超軽量な httpd があればそれがよさそうですね．

**root▲ ★** · 2006/06/13(火) 13:20:24

>>69
ふむふむ。

で、

148 名前：名無し草[sage] 投稿日：2006/06/13(火) 12:47:29
> Apache ではないのを使う( thttpd とか )方向かなと。
ttp://wota.jp/ac/?date=20060605#p01
参考になるかは知らないけど、一応。

ですが、軽い httpd の試みはいろいろあるようですね。

パブリック側は Apache のままにしておいて、
削除 CGI とかはそちらに飛ばすようにすれば、
CGI の実行すら要らないという噂もあるですね。

とすると、

・差分転送関連
・If-Modified-Since とかそのへん

がちゃんと動くなら、ってかんじですか。

**root▲ ★** · NG

で、昨日の様子を見る限りでは明らかに、
cobra > tiger でした。

メモリ容量ほぼ同じ
HDD 仕様ほぼ同じ
Apache セッティングほぼ同じ

で、tiger は正しく LA=750 になり、cobra は LA=3 とかでした。
64bit I/O が効いているのか、あるいは dat オンメモリというぐらいで、
メモリアクセスが高速なのか。

でも、ハングアップ癖があるんではなぁ。

**root▲ ★** · NG

>>71
正しく = 虫を踏んだわけではなさそう、という意味

株価【390】 ▲ ◆cZfSunOs.U · 2006/06/13(火) 13:41:44

>>70 そんな感じですね．パブリック/プライベートで分けてもいいし，ポート番号で分けてもいいし．

>>71-72 なるほど...... amd64 で駆虫が成し遂げられれば最強ってところですね．
tiger も新しいのは EM64T として 64-bit で動くんでしたよね．もっとも，
EM64T でも同じ虫，あるいは別の虫も出てきちゃうかも知れませんけど．

◆XejmK2zG7E · 2006/06/13(火) 13:45:42

>>68
対応ありがとうございます。

【全IP】の方に間違いがありましたので、修正致しました。
【CIDR】表記に変更はございません。

http://br.jig.jp/pc/ip_br.html

宜しくお願い致します。

**root▲ ★** · 2006/06/13(火) 13:53:17

>>74
了解しました。
今後ともよろしくお願いします。

# 最初見た時「あれ」と思いましたが、修正バージョンを見て納得しました(w。

**root▲ ★** · NG

こんなスレッドが。

6.1 Stable keeps hanging
http://lists.freebsd.org/pipermail/freebsd-stable/2006-June/025939.html

Xeon の例だけど、amd64 (64bit) での例。

ざっとしか読んでないけど、mpsafenet を切ると直るとかなんとか。

**root▲ ★** · NG

現象は 2ch で起きているのと全く同じっぽい。理由もなく突然ハング
http://lists.freebsd.org/pipermail/freebsd-stable/2006-June/025939.html

ハングしているサーバのハードウェア構成(dmesg)
Xeon dual (新tiger相当)を amd64 で使用。ネットワークは em で、SCSI は amr
http://lists.freebsd.org/pipermail/freebsd-stable/2006-June/025944.html

同じ現象を経験した人がいて、debug.mpsafenet=0 で直ったらしい
http://lists.freebsd.org/pipermail/freebsd-stable/2006-June/025949.html

それに対して開発者の rwatson は「情報をくださいー」
http://lists.freebsd.org/pipermail/freebsd-stable/2006-June/025951.html

6.0R ではとりあえずハングはしないらしい(2chでの現象と同じ)
http://lists.freebsd.org/pipermail/freebsd-stable/2006-June/025957.html

**root▲ ★** · NG

config 見ると、この人は kbdmux を有効(デフォルト)にしているのか。

devicekbdmux# keyboard multiplexer

preemption も有効と。

options PREEMPTION# Enable kernel thread preemption

もうちょっと調べてみる必要ありですが、
同じ現象が起きている人が少なくとも複数いて、
workaround を適用して直った、という人もいることまで、とりあえずわかったと。

**root▲ ★** · NG

…しかし、mpsafenet は疑わなかったなぁ。
ぜんぜん確定じゃないけど。