2ch特化型サーバ・ロケーション構築作戦 Part22
■ このスレッドは過去ログ倉庫に格納されています
2ch特化型サーバ・ロケーション構築作戦のスレッドです。
・２ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更関連の各種作業や調整事項
・２ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携
等を取り扱います。
現在、複数サーバによる連携により、
サーバ能力のさらなるスケールアップをめざすための「雪だるま作戦」が進行中です。
しかし、問題はあらゆる意味で山積の状態です。
特に、成熟度を高めたリリースであるはずの FreeBSD 6.1R において、
amd64 アーキテクチャでの突然のハングアップの不具合が、深刻な問題となっています。 >1
乙～
前スレ1000もきれいに決まったようで 999 ：たにし ★ ：2006/06/12(月) 04:09:13 ID:???0
ぬわわわ >>4
1000 のほうが（りゃ。
前々スレからの課題
・削除関係の呪文の雪だるま対応 (まずはバックに転送して一時しのぎ中)
・バックエンドの安定稼動 (i386 版はほぼ安定、amd64 版は格闘中)
・matd を用いた受付の安定稼動 (ほぼ解決、フロントエンドの自動切り離し要)
・mod_cache の導入によりバックエンドの負荷を下げる (squidとのマッチング要調査)
・電源食い杉どうしよう (やりくりで何とか3台+5台まで拡張、しかし根本解決は 365main)
・携帯フルブラウザからの書き込み対応 (解決、更新のしくみも確立)
重要な課題
・効率の良い金色会員維持 (おごってもらう話があったような)
・家庭の保守 (・・・・・・・・・・・・) 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 これ以外の前スレのサマリは、明日以降ということで。
さすがに、今日はそろそろ限界が近いかも。 news20b も、mpsafevfs を殺した。
%sysctl -a | grep mpsafe
debug.mpsafevfs: 0
debug.mpsafenet: 1
debug.mpsafevm: 1
今日は、ここまでかなと。 前スレ
・家庭の保守 (・・・・・・)
今スレ
・家庭の保守 (・・・・・・・・・・・・)
「・」の数が、何げに倍になってるのがなんともかんとも(´･ω･`) 前スレにあったSCSI controllerの話はもう続かないの？ >>17
それは、とある場所にある秘境。
偶然迷い込むこともあれば、歩き回って行き着くこともある。
さぁ、君も探索に出るんだ。その内行き着くかも知れない。 >>17
その国の名はガンダーラ､どこかにあるユートピア
よろしく～ネッ!! うーん
報告したかどうかも忘れちまった。
再度、
> (現在)
> +ex14.2ch.net:206.223.151.225
>
> (変更後)
> +ex14.2ch.net:206.223.151.230
>
これおわった >>21
どもです。
2ch特化型サーバ・ロケーション構築作戦 Part21
http://qb5.2ch.net/test/read.cgi/operate/1145114275/831-833
oyster901 はたぶん、移設 & HDD 交換が合い前後して、
というかんじですかね。
よみがえる時は ex16 になると。 ex11 に移転した campus と keiba 、ジンギスカンになっていないような。 >>25
ここはひとつ。
とは言っても、morningcoffee はジンギスカンIIだから、/md の容量がちょっと足りないですね。
先に私のほうで拡張工事します。 keiba は土日があるから
やっぱジンギスカンの方がいいっすね、
つうことで campus keiba ジンギスカンⅠにしてきます。 >>27
今見たら、問題なさげですね。
作業可能です。< ex11 debug.mpsafevfs=0 は、外れだったのか。 Submit a FreeBSD problem report
http://www.freebsd.org/send-pr.html
そろそろ、まじめに送らないといけないと。 今回の WC は「勝ちに行く」ってことだったと思うんで（それでバック追加して live23 新設ってことでしたし），
live23 は実績のある手堅いバージョンで行く一方で，その代わり news20 には人b(ryになって頂く方向とか，
そんな感じでどうかな，とか...... >>36
5.4R とか 6.0R にバージョンダウンする、か、
i386 にするか、ということですか。
i386 にするのは、現地での(少なくとも)CD-ROMの差込と除去が必要になると。 # Workarounds for some known-to-be-broken chipsets (nVidia nForce3-Pro150)
device atpic # 8259A compatability
これは、関係ないのかなぁ。(デフォルトで有効) ここは片方のCPUでどれだけ行けるかを見てみようぜ
もう時間ないけど >>39
single CPU mode のカーネルは、作ってはあるので、
入れ替える作業そのものは、できる状態にあります。
しかしまずは、現状でいくかんじで。 次上がったら、single CPU mode に移行。
これは決定で。< live23b, news20b ここまでの状況:
バックエンドはまだ、目分量で半分も使われていない状態だった。
フロントは、あふれた。bbs.cgi (speedy_backend) の起動数(-M)を調整。
1フロントの1バーチャルホストあたり 24 に制限。(-M24)
debug.mpsafevfs=0 は効果がなかった。on FreeBSD 6.1R/amd64 NFS をはずしたおかげで、
バックエンドサーバ1台のダウンが全体を完全に止めてしまうことは、
一応避けられるようになった模様。 live23b single CPU mode に移行しました。
mpsafevfs はWC試合終了後に再度有効にするということで。 live22 (tiger なバックエンド)は、パンク状態。
LA=500 とかなりました。落ちてはいないものの、めいっぱいという感じ。 >>46
live22 はかなりめいっぱいという感じだけど、
ブレーメンに隙間を出さないというのは、さすがという感じかも。 LA=780 @ live22
リモートログインはほとんど無反応になったけど、ちゃんと耐えているのか。 むこう書けないんで、
news18
ex13
Saborin 発動、IsKoukoku カット。 ex13 は LA=35 ぐらい。
大丈夫でしょう。
news18 は LA=60 超えましたが、
>>49 発動で下がりました。
大丈夫でしょう。 ex11 IsKoukoku カット。(Saborin は常時発動済み) ex11 LA 10ぐらいになりました。
さっきは200以上あった。
大丈夫でしょう。
掛けまくも畏き イザナギの大神 ◇ ミ ◇ 祓へ給ひ清め給へと
筑紫の日向の橘の ◇◇ /￣| ◇◇ まをすことを聞こし召せと
小戸の阿波岐原に ◇◇ ＼ |＿_| ◇ 恐み恐みもまをす。
禊ぎ祓へ給ひし時に 彡 O(,,ﾟДﾟ) /.. 2ch稼動サーバ・ロケーションの
なりませる祓へ戸の大神たち ( Ｐ `O 常盤かきはに幸くと
諸々の禍事・罪・穢れあらむをば ／彡#＿|ミ＼ 請ひのみ奉らくとまをす
</｣_|凵_ゝ
やはり課金システムにして蹴って行かないと駄目なんジャマイカ 恒常的な収入があるといいのだが。
広告の収入が増えないかな。
アングラなイメージはだいぶなくなってきたと思うのだけど、
エロ広告ばっかりでちょっと引く。 負荷問題はいずれ解決しなけりゃならん問題になるんだし
一時しのぎ程度のものは問題を先送りしてるだけかと．
お金で解決できりゃ良いけど，技術的にそういうわけには
いかない部分も出てくるだろうし．
雪だるま周りはどういう風に解決するか楽しみだったり…… >>45
live23b
news20b
両サーバとも、single CPU モードに移行。
mpsafevfs は、デフォルトに戻した(有効)。
これで安定してくれるといいけど。
で、安定するようなら、それはそれで問題なわけだが。 >>57
三年前の状態に戻すだけだよ､パケ代定額前の状態に
腹八分目って大切だと思うよ
実際にスレ立て制限とか書き込み時間制限とかで削ってる訳だからさ バックエンド (live22) もついにアップアップ状態まで逝きましたか．
それに対応するとしたらやはり mod_cache ということでしょうけど，
フロントの httpd でこんな設定すれば BG (Squid) 問題の対策できるかなぁ......
SetEnvIf Remote_Addr ^206\.223\.151\.(55|57)$ BlackGoat
Header append Cache-Control proxy-revalidate env=BlackGoat
フロント側としても，毎回バックエンドにお伺い立てるよりは
ローカルキャッシュ使えた方が軽くなるかなぁ...... で，携帯は中期的には u.la に期待するとして，短期的に今の c を延命させるとすると......
現状 Squid でキャッシュさせてるのは生の dat や subject.txt だけなんですよね？
となると，PHP 出力側も mod_cache でキャッシュさせてみるとか．
んで，dat 等をフェッチする際に得られる Last-Modified をそのまま PHP 出力でも吐いてもらうと． たぶん、バックエンドの少なくともプライベート側のほうは、
Apache ではないのを使う( thttpd とか )方向かなと。
で、mod_cache の件ですが、前から気になっているのですが、
mod_cache 入れた場合、書いた直後に dat を読むタイプの専用ブラウザとかで、
ちゃんと自分の書いたレスが読まれるようになるのかしら。
直感では、キャッシュが働くので、昔の NFS で動かした時のように、
反映に遅延が発生するような気もします。 お世話になっております。株式会社jig.jpの菊池です。
サーバ移設のためIPアドレスが変更になります。
詳細は下記URLからご確認ください。
http://br.jig.jp/pc/ip_br.html
宜しくお願い致します。 >>65
確認しました。
これは、すぐに変更・反映してしまってよろしいでしょうか。 …というか、CIDR 的には 1ブロックの追加ということですね。
いってきます。 210.188.205.92/30 を jig ブラウザ用 CIDR ブロックとして追加しました。
10分程度で反映されるはず。 >>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 があればそれがよさそうですね． >>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 とかそのへん
がちゃんと動くなら、ってかんじですか。 で、昨日の様子を見る限りでは明らかに、
cobra > tiger でした。
メモリ容量ほぼ同じ
HDD 仕様ほぼ同じ
Apache セッティングほぼ同じ
で、tiger は正しく LA=750 になり、cobra は LA=3 とかでした。
64bit I/O が効いているのか、あるいは dat オンメモリというぐらいで、
メモリアクセスが高速なのか。
でも、ハングアップ癖があるんではなぁ。 >>71
正しく = 虫を踏んだわけではなさそう、という意味 >>70 そんな感じですね．パブリック/プライベートで分けてもいいし，ポート番号で分けてもいいし．
>>71-72 なるほど...... amd64 で駆虫が成し遂げられれば最強ってところですね．
tiger も新しいのは EM64T として 64-bit で動くんでしたよね．もっとも，
EM64T でも同じ虫，あるいは別の虫も出てきちゃうかも知れませんけど． >>68
対応ありがとうございます。
【全IP】の方に間違いがありましたので、修正致しました。
【CIDR】表記に変更はございません。
http://br.jig.jp/pc/ip_br.html
宜しくお願い致します。
>>74
了解しました。
今後ともよろしくお願いします。
# 最初見た時「あれ」と思いましたが、修正バージョンを見て納得しました(w。 こんなスレッドが。
6.1 Stable keeps hanging
http://lists.freebsd.org/pipermail/freebsd-stable/2006-June/025939.html
Xeon の例だけど、amd64 (64bit) での例。
ざっとしか読んでないけど、mpsafenet を切ると直るとかなんとか。 config 見ると、この人は kbdmux を有効(デフォルト)にしているのか。
devicekbdmux# keyboard multiplexer
preemption も有効と。
options PREEMPTION# Enable kernel thread preemption
もうちょっと調べてみる必要ありですが、
同じ現象が起きている人が少なくとも複数いて、
workaround を適用して直った、という人もいることまで、とりあえずわかったと。 …しかし、mpsafenet は疑わなかったなぁ。
ぜんぜん確定じゃないけど。 >>76-79 う～む，どっちか片方を SMP に戻した上で debug.mpsafenet=0 にして様子見とか． news20b で
_ ∩
( ﾟ∀ﾟ)彡 実験！実験！
( ⊂彡
| |
し ⌒Ｊ >>80-81
そうしたい誘惑はすごくすごくあるんですが、
２ちゃんねるのサーバが 2F に移動完了するまでは、
カーネルの設定変更については、しない方向でいこうかと。
現状のシチュエーションでは、ハングした時とかの対応考えると、
各方面にあまり負荷をかけたくないですね。
ということで、第二戦は今の設定でいく感じかなと。 というか、シングル CPU でも問題は起こるのかとか、
シングル CPU 状態での限界性能はどうなのかとか、
そういうことも確認できるわけで、
まったく無駄な時間になることは、ないと思っているです。 >>84
おー。
あの libthr の davidxu のスケジューラですか。 >>75
こちらこそ今後とも宜しくお願いします！
誤表記がないよう今度注意します。
宜しくお願いします。 >>87
わざわざありがとうございます。
>>86
なお現在の設定は、>>86 から options SMP をはずしただけ。 NFSが駄目ならGFSか。
静的コンテンツはlighttpでいいかと。
あとガンビアって >>89
GFS は寡聞にして知りませんでしたので、Google に。
Red Hat Global File Systemによるエンタープライズデータ共有
http://www.jp.redhat.com/magazine/NO19/
GFSストレージクラスタによるデータ共有
http://www.jp.redhat.com/magazine/NO11/
こんなのがあるですか。
> あとガンビアって
これは、なんでしょう。 あ単純に頑張ってというのもなんだったので。頑張ってくらはい codaなんてのもちょっとだけおもしろそうだなぁ、と。
ここで求められてる機能とはちょっと違う気もするけど [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:17.sendmail
http://lists.freebsd.org/pipermail/freebsd-announce/2006-June/001071.html
2ch的にはそう影響はないのかな． dnstop というのがあるみたいなので、少し遊んでみた。
以下は ex11 の内容。
リモホ得るためにDNS引いているので、逆引きばかり(想定どおり)。
あと、今の ex11 では BBQ と BBM の比率はだいたい 11:1 ぐらいみたい。
Source 3LD count %
---------------- -------------------- --------- ------
127.0.0.1 niku.2ch.net 541 28.2
127.0.0.1 9.211.in-addr.arpa 69 3.6
127.0.0.1 bbm.2ch.net 43 2.2
127.0.0.1 136.210.in-addr.arpa 40 2.1
127.0.0.1 7.222.in-addr.arpa 34 1.8
127.0.0.1 125.219.in-addr.arpa 16 0.8
127.0.0.1 153.210.in-addr.arpa 14 0.7
127.0.0.1 98.219.in-addr.arpa 13 0.7
127.0.0.1 150.222.in-addr.arpa 12 0.6
127.0.0.1 89.58.in-addr.arpa 12 0.6
127.0.0.1 185.221.in-addr.arpa 12 0.6
127.0.0.1 130.210.in-addr.arpa 12 0.6
127.0.0.1 84.124.in-addr.arpa 11 0.6
127.0.0.1 3.125.in-addr.arpa 11 0.6
127.0.0.1 47.218.in-addr.arpa 11 0.6
127.0.0.1 217.218.in-addr.arpa 11 0.6
127.0.0.1 211.220.in-addr.arpa 11 0.6
127.0.0.1 158.222.in-addr.arpa 10 0.5
127.0.0.1 146.220.in-addr.arpa 10 0.5
127.0.0.1 200.125.in-addr.arpa 10 0.5
127.0.0.1 39.60.in-addr.arpa 10 0.5
127.0.0.1 225.218.in-addr.arpa 10 0.5
127.0.0.1 227.218.in-addr.arpa 10 0.5
127.0.0.1 106.219.in-addr.arpa 10 0.5
127.0.0.1 110.219.in-addr.arpa 10 0.5
127.0.0.1 236.60.in-addr.arpa 10 0.5
127.0.0.1 108.220.in-addr.arpa 9 0.5
127.0.0.1 45.60.in-addr.arpa 8 0.4 1 CPU モードにしてからは落ちてない模様なので，とりあえずそれで虫は回避できてるんですかね．
ただ，パワーダウンしてるので日曜日にどうなるか......
live23b は >>83 のように限界性能を見るという意味でそのまま突入ってのもいいかも知れませんが，
第一戦で限界に達したと思われる live22 の方ではバックエンドの負荷軽減策（mod_cache，軽量版 httpd 等）
を試してみるのもいいかも...... 【実況】 live22+live23 Part21
http://qb5.2ch.net/test/read.cgi/operate/1150119711/340
過去ログの課題のまとめへのリンク。
>>97
live22 は、少し何かしてみますかね。 帰宅。雨。
まずは、例の JavaScript を read.cgi にインラインで埋め込む方向かも、かも。 >>99 index.js ですか？ 確かに，現状でフロントの負荷に影響してるとしたら
それもいいかも知れませんね．ただ，バックに負荷をかけるものではないので
今後フロントの台数が増えた段階ではまた状況も変わるかもとか，あとは
どなたかも言ってたように mod_expires でリロード抑制させてみるとか．
あと，httpd / read.cgi や bbsd 等のコンパイル時の最適化オプションとかも
ひょっとして詰める余地があったりとか......？ >>100
基本的に -O2 のはず。< read.cgi / bbsd
Apache は ports のデフォルトかな。
mod_expires って、JavaScript のファイルを読むところでも区別なく効くんでしたっけ。 ■ このスレッドは過去ログ倉庫に格納されています
