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

[1 root▲ ★ NG NG]

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

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

等を取り扱います。

現在、複数サーバによる連携により、
サーバ能力のさらなるスケールアップをめざすための「雪だるま作戦」が進行中です。

また、次世代の携帯アクセス環境をめざした「べっかんこ作戦」も稼動しはじめました。
「２ちゃんねる証券取引所」や、「Be」の機能強化等、
２ちゃんねるは今日も変化し続けています。

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

[942 動け動けウゴウゴ２ちゃんねる 2006/04/13(木) 16:03:04 ID:5UgFteSE0]

>>941
Qになる予定とのこと

[943 ◆XejmK2zG7E 2006/04/13(木) 16:42:59 ID:w4qSWLqT0]

>>939
管理人様への報告・連絡ありがとうございます。

技術情報の準備ができ次第公開いたします。
宜しくお願いいたします。

[944 動け動けウゴウゴ２ちゃんねる 2006/04/13(木) 21:45:47 ID:kb8q5+UvP]

QよりJのがいい奴手をあげろ

[945 動け動けウゴウゴ２ちゃんねる 2006/04/13(木) 22:27:09 ID:egtNQzHz0]

ノシ

[946 動け動けウゴウゴ２ちゃんねる 2006/04/13(木) 22:45:45 ID:2VDcT5E0P]

まだ実現してないのに調子に乗ると白紙になるぞ
実現してからにしな

[947 root▲ ★ NG NG]

Apr 14 04:47:01 <0.6> tiger2522 kernel: pid 15433 (httpd), uid 2001: exited on signal 10
Apr 14 04:47:05 <0.6> tiger2522 kernel: pid 15452 (httpd), uid 2001: exited on signal 10
Apr 14 04:47:10 <0.6> tiger2522 kernel: pid 15477 (httpd), uid 2001: exited on signal 10

2006/04/14 20:40:01 LA= 8:40PM up 7 days, 8:31, 0 users, load averages: 2.14, 2.04, 1.51
2006/04/14 20:50:01 LA= 8:50PM up 7 days, 8:41, 0 users, load averages: 44.46, 79.74, 42.55
2006/04/14 21:00:01 LA= 9:00PM up 7 days, 8:51, 0 users, load averages: 2.58, 15.59, 24.74
2006/04/14 21:10:01 LA= 9:10PM up 7 days, 9:01, 0 users, load averages: 0.84, 3.04, 12.88

負荷の急上昇とともに、httpd が signal 10でのダウン(ともに前からある症状)。

6.1R にすれば、直るのかどうなのか。

[948 root▲ ★ NG NG]

Fri Apr 14 20:46:00 JST 2006
"livecx" is loaded.
Its subject buffer is clean.

user CPU time = 0:49:32.163, system CPU time = 1:13:27.557
elapsed time = 176:34:57.472, CPU load = 1.16%

total worker threads = 1, idle worker threads = 0

minor page faults = 17019, major page faults = 1078187, swaps = 0
block inputs = 9334, block outputs = 3728
messages sent = 3743852, messages received = 3743852
signals = 0, vol ctx switches = 18035298, invol ctx switches = 1250974

Fri Apr 14 20:47:00 JST 2006
書き込みを受理しましたがサーバが混雑しています．書き込みが反映されない場合もあります．
Fri Apr 14 20:48:00 JST 2006
"livecx" is loaded.
Its subject buffer is clean.

user CPU time = 0:49:35.075, system CPU time = 1:13:32.107
elapsed time = 176:36:58.021, CPU load = 1.16%

total worker threads = 1, idle worker threads = 0

minor page faults = 17019, major page faults = 1078745, swaps = 0
block inputs = 9334, block outputs = 3731
messages sent = 3746332, messages received = 3746332
signals = 0, vol ctx switches = 18046569, invol ctx switches = 1256638

Fri Apr 14 20:49:00 JST 2006
書き込みを受理しましたがサーバが混雑しています．書き込みが反映されない場合もあります．
Fri Apr 14 20:50:00 JST 2006
書き込みを受理しましたがサーバが混雑しています．書き込みが反映されない場合もあります．
Fri Apr 14 20:51:00 JST 2006
"livecx" is loaded.
Its subject buffer is clean.

user CPU time = 0:49:42.222, system CPU time = 1:13:41.488
elapsed time = 176:39:57.569, CPU load = 1.16%

total worker threads = 1, idle worker threads = 0

minor page faults = 17019, major page faults = 1079707, swaps = 0
block inputs = 9335, block outputs = 3734
messages sent = 3750715, messages received = 3750715
signals = 0, vol ctx switches = 18068414, invol ctx switches = 1270275

[949 root▲ ★ NG NG]

あと、今でもできることとして、

・mod_cache うまく動くようにする
- squid と通信させて、動きをよく見てみる
・フロントが落ちたら matd の仲間から外す仕掛け作り

徐々にすすめることとして、

・フロント・バックともFreeBSD 6.1Rへの更新
・フロントエンドApache 2.2系への更新

さらに、

・game10 hobby7 news19 BBQ の電源・ロケーション移動
・その後、フロント #4 = tiger503 #5 = tiger507 と バック #2 = cobra2247 の稼動

あと、構築系以外だと、

・削除系呪文の本格対応

[950 root▲ ★ NG NG]

一つ忘れていた。

・過去ログ rsync の改良
- これはフロント #4 or #5 またはバック #2 がきたら、それらの1台を使用か。

[951 root▲ ★ NG NG]

Just idea ですが、
read.cgi と offlaw.cgi を動かすフロントを1台とか2台にしてしまえば、
過去ログの同期(rsync)するサーバも、それだけで済むのかな。

[952 root▲ ★ NG NG]

あるいは、一度負けた NFS を使うか。
どう実現するにせよ、スケーラブルにしたいところかなと。

いずれにせよ「過去ログ倉庫に保管されています」の判定部分なんですよね。
public_html じゃないところを読んでいるところ。

専用ブラウザだと、302 だったら offlaw.cgi みたいな処理なので、
それなりになんとかなるわけですが。

… 本筋は read.cgi の改造かなぁ、やっぱ。

[953 root▲ ★ NG NG]

お、show stopper がなくなったぞ、と思ったら、
desired に移動したものも多いのかな。
http://www.freebsd.org/releases/6.1R/todo.html

と思ってみてみると、やっぱりすね。
http://www.freebsd.org/cgi/cvsweb.cgi/www/en/releases/6.1R/todo.sgml?rev=1.25&content-type=text/x-cvsweb-markup

ということは、ぼちぼちリリースに向けた作業が始まる運びかなと。

[954 動け動けウゴウゴ２ちゃんねる 2006/04/15(土) 01:51:43 ID:l3MyIRYk0]

ずいぶん昔にも書いたような覚えがありますが
read.cgiのデータ処理部だけなら、全然重い処理じゃないですよ。
ディスクI/Oと圧縮が重いだけで。
.datの必要部分をHTMLにするだけなら、
毎秒500-1000件程度なら処理できると思います。

ただ、もしLAN上の別マシンを使うなら
やはりHTTP経由よりNFSの方が数段軽いでしょう。
カーネル内部で完了するというのは大きいです。

[955 root▲ ★ NG NG]

>>954 第一段落
私も同じ感覚を持っています。
dso 化した後は、少なくとも tiger サーバでは、
read.cgi が高負担になった記憶はないです。

ということは、read.cgi と offlaw.cgi の処理は、専用フロントにやらせると
よさげなのかな。

で、第二段落ですが、確かにそう思うわけですが、
なにぶん一度痛い目に遭っているので(5.4Rの頃ですが)、
少なくともシビアな I/O のところ(dat直読みするところとか)には、
ちと使いずらいところがありますね。

例のディレイ(書いたdatをすぐにNFS経由で読んだ時に起きたもの)が
きちんと解決できるような気がしないので、ライブなdatには、
ちと使いにくいかんじ。

過去ログのところには、うまくすれば使えるかもですが。

[956 動け動けウゴウゴ２ちゃんねる 2006/04/15(土) 03:08:55 ID:I5hjKHvK0]

6.1のNFSについて、個人的に、tools/regression/fsx を使用してテストしたりしてますが、
NFSv3 + UDP + リモートマウント
であるならば、今のところ問題ないように思えます。。。
まあ、あくまでfsxでテストした結果なので、実践投入では違うかも知れませんが。

TCPを使用した場合は、理由はわかりませんが、たまにエラーが発生してました。これはKrisの意見
http://lists.freebsd.org/pipermail/freebsd-stable/2006-March/023707.html
とも一致します。

ローカルマウント(127.0.0.1に対してNFS経由でマウント)した場合は、
syncのタイミングでエラーになることがありますね。
これについては、まあ、運用でそういうことはあんまりしないかなぁと思って、
個人的には無視していますけど。

[957 株価【650】 ▲ ◆cZfSunOs.U 2006/04/15(土) 20:58:23 ID:bxoh0yJy0]

NFS が正常に動くという前提なら，NFS 使うのが一番簡単かつスマートですね．
以前ボロボロだった時は，ファイル更新時の rename() とタイミングがかち合うと
その際に起こる ESTALE でカーネルごとコケてしまうということだったと思いますが，
過去ログだけならそういうことは起こりにくいでしょうし．

あと，過去ログが HDD 食い潰すって問題も併せて対応するとなると，
過去ログを memories に転送してそっちのを NFS mount するとか......

[958 動け動けウゴウゴ２ちゃんねる 2006/04/15(土) 21:04:02 ID:9yYW06UBO]

rootたん乙

俺は絶対rootたんの頭であぼんされているな。

それにしてもjigの人来ない。
もしかしたら2ch用のゲートウェイ作っているのかな。

// ATフィールドでイオナズン防げたらなぁ。

[959 root▲ ★ NG NG]

>>957
> 過去ログを memories に転送してそっちのを NFS mount するとか......

そんなことを考え始めていたりします。

で、前におかしくなったのは、ESTALE 問題もさることながら、
mount している方が一斉にデッドロックする問題ですね。

ps で見ると一斉に D の状態になって、kill -9 でももちろん死なないし、
どうしようもなくなると。

>>958
イオナズンの解析をした人かしら。
だとしたら特に、あぼーんはしてないと思うです。

bbs.cgi 的には、該当ルーチンを組み入れれば対応できるように組んであるので、
私としては技術情報が出たら、あとはたんたんと組むだけと。

[960 動け動けウゴウゴ２ちゃんねる 2006/04/15(土) 21:38:00 ID:GV1/e9bL0]

>>958
ヒント：釣り

[961 root▲ ★ NG NG]

で、memories は 5.3R なので、そのへんが心配だったりします。
6.1R が安定なら、バージョンアップもありかなとは思っていますが、
なにぶん慎重にやらないといけないサーバなので、
できれば(いつになるか…)、現地でやりたいかなと。

[962 root▲ ★ NG NG]

また破綻か、、、。

6.1-RC 投入するか、あるいは 6.1R が出るまで我慢するか。

[963 ◆Reffiz2Zh. 2006/04/15(土) 22:20:57 ID:VW1sPzu60]

>962
ここまで虫踏みまくって調子よくないようでしたら6.1-RC早期投入した方がいいと
思います。

[964 株価【650】 ▲ ◆cZfSunOs.U 2006/04/15(土) 22:24:06 ID:bxoh0yJy0]

umtx って mutex か何かでしょうか......
まぁ race condition を起こりにくくするということなら mod_cache というのもありますが(>>949)．

[965 root▲ ★ NG NG]

<IfModule mpm_worker_module>
StartServers 96
Serverlimit 128
MaxClients 4096
MinSpareThreads 256
MaxSpareThreads 3072
ThreadsPerChild 32
MaxRequestsPerChild 32000000
ThreadLimit 32
MaxMemFree 64000
</IfModule>

を、

<IfModule mpm_worker_module>
StartServers 384
Serverlimit 512
MaxClients 4096
MinSpareThreads 256
MaxSpareThreads 3072
ThreadsPerChild 8
MaxRequestsPerChild 32000000
ThreadLimit 8
MaxMemFree 64000
</IfModule>

に変更。
1プロセスあたりのスレッド数を、32から8に減少。@ live22

[966 root▲ ★ NG NG]

httpd が突如、暴走状態になりました。
CPUのidle timeがなくなったのと期を同じくしています。
というか、暴走になったからidle timeがなくなったのかなと。

[967 root▲ ★ NG NG]

で、1プロセスあたりのスレッド数を下げたのは、なんというか、勘ってやつです。
虫を踏むリスクが、減るんじゃないかなと。

[968 root▲ ★ NG NG]

MaxRequestsPerChild 32000000

も、1/8 にするかな。

[969 root▲ ★ NG NG]

× 1/8
○ 1/4

# MaxRequestsPerChild 32000000
MaxRequestsPerChild 8000000

にした。次回の起動時に有効に。

[970 root▲ ★ NG NG]

あとは、マルチスレッドなApacheがforkするのは、いくない気がするので、
最初から最大プロセスにしておくか。< live22

[971 株価【650】 ▲ ◆cZfSunOs.U 2006/04/15(土) 22:34:23 ID:bxoh0yJy0]

>>965-969 乙です．スレッド数減は有効かもですね．

>>970 ん〜それは......マルチスレッド MPM でも fork() するのは
シングルスレッドな親プロセスなんで......

[972 root▲ ★ NG NG]

>>971
なるほど、、、。

とりあえず、「常に最大プロセス数で待つ」設定にしてみた。
どうせ、それで動いても問題ないはずなので。

[973 root▲ ★ NG NG]

なるほど、プロセスが多いとだめみたい。

再度httpd落とし中。

[974 root▲ ★ NG NG]

<IfModule mpm_worker_module>
StartServers 384
Serverlimit 384
MaxClients 3072
MinSpareThreads 3072
MaxSpareThreads 3072
ThreadsPerChild 8
MaxRequestsPerChild 8000000
ThreadLimit 8
MaxMemFree 64000
</IfModule>

にした。

今はちゃんと動いているっぽい。

[975 root▲ ★ NG NG]

破綻はしないけど、やはり挙動不審になる模様。

さらにプロセス数を減少。httpd リスタート中。

[976 root▲ ★ NG NG]

またですね。

LA=700 超え。

last pid: 16772; load averages: 817.21, 292.39, 154.68 up 8+10:43:39 06:52:22
2625 processes:7 starting, 1744 running, 874 sleeping
CPU states: 58.9% user, 0.0% nice, 25.5% system, 15.6% interrupt, 0.0% idle
Mem: 472M Active, 1716M Inact, 357M Wired, 16M Cache, 112M Buf, 954M Free
Swap: 4096M Total, 4096M Free

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND
12220 root 128 0 8872K 8136K CPU0 0 0:56 3.27% top
16252 ch2live22 130 0 10448K 6876K RUN 0 0:01 0.54% httpd
3633 ch2live22 131 0 2676K 1436K RUN 1 2:44 0.54% bbsd
16223 ch2live22 130 0 9556K 6464K RUN 3 0:01 0.44% httpd
16393 ch2live22 130 0 9552K 6376K RUN 1 0:01 0.29% httpd
16384 ch2live22 130 0 9896K 6540K select 2 0:01 0.29% httpd
16328 ch2live22 130 0 9876K 6700K RUN 3 0:01 0.29% httpd
16168 ch2live22 130 0 9836K 6676K select 2 0:02 0.29% httpd
16204 ch2live22 130 0 9852K 6552K RUN 3 0:01 0.29% httpd
16386 ch2live22 131 0 9788K 6148K RUN 0 0:01 0.25% httpd
16261 ch2live22 130 0 9092K 6068K ucond 1 0:01 0.25% httpd
16767 ch2live22 128 0 2856K 2224K RUN 3 0:00 0.22% perl5.8.7
16384 ch2live22 130 0 9896K 6540K RUN 0 0:01 0.20% httpd
16379 ch2live22 130 0 10588K 7296K RUN 0 0:01 0.20% httpd
16352 ch2live22 131 0 9072K 6052K select 0 0:01 0.20% httpd
16352 ch2live22 131 0 9072K 6052K RUN 2 0:01 0.20% httpd
16358 ch2live22 128 0 9564K 6500K ucond 3 0:01 0.20% httpd
16261 ch2live22 130 0 9092K 6068K ucond 1 0:01 0.20% httpd
16264 ch2live22 130 0 9764K 6592K RUN 3 0:01 0.20% httpd
16208 ch2live22 130 0 9872K 6500K RUN 3 0:01 0.20% httpd
16180 ch2live22 130 0 10488K 7032K RUN 3 0:01 0.20% httpd
16270 ch2live22 130 0 9632K 6588K ucond 3 0:01 0.20% httpd
16426 ch2live22 130 0 8972K 5944K select 1 0:01 0.15% httpd
16397 ch2live22 129 0 9260K 6220K RUN 0 0:01 0.15% httpd
16367 ch2live22 129 0 9188K 6156K RUN 1 0:01 0.15% httpd
16284 ch2live22 131 0 9140K 6120K RUN 3 0:01 0.15% httpd

[977 root▲ ★ NG NG]

いったん httpd を落とし、
matd を落として入ってこないようにして、
httpd をスタートして、matd を再開。

[978 root▲ ★ NG NG]

<IfModule mpm_worker_module>
StartServers 256
Serverlimit 256
MaxClients 2048
MinSpareThreads 2048
MaxSpareThreads 2048
ThreadsPerChild 8
MaxRequestsPerChild 8000000
ThreadLimit 8
MaxMemFree 64000
</IfModule>

さらにプロセス数を減少。@ live22

[979 root▲ ★ NG NG]

スレッド数減少は、かえって負荷が高まった予感。

[980 root▲ ★ NG NG]

<IfModule mpm_worker_module>
StartServers 64
Serverlimit 64
MaxClients 2048
MinSpareThreads 2048
MaxSpareThreads 2048
ThreadsPerChild 32
MaxRequestsPerChild 32000000
ThreadLimit 32
MaxMemFree 64000
</IfModule>

に変更。

[981 root▲ ★ NG NG]

>>980 の方が明らかに楽になり、CPU idle time も増えますね。
ううむ。

[982 root▲ ★ NG NG]

実験的に、

<IfModule mpm_worker_module>
StartServers 32
Serverlimit 32
MaxClients 2048
MinSpareThreads 2048
MaxSpareThreads 2048
ThreadsPerChild 64
MaxRequestsPerChild 32000000
ThreadLimit 64
MaxMemFree 64000
</IfModule>

にした。

[983 root▲ ★ NG NG]

プロセスが少なくてスレッド数が多いほうが、システムは楽みたいですね。

[984 root▲ ★ NG NG]

ただ、32と64では有意な差はあまりないっぽい気もします。
挙動不審なら、32に戻す方向で。

[985 株価【650】 ▲ ◆cZfSunOs.U 2006/04/15(土) 23:18:29 ID:bxoh0yJy0]

そういえばこんな話もあったような．むしろ1プロセスだけにしてしまった方がいい!?

　　* FreeBSD, threads, and worker MPM. All seems to work fine
　　　if you only have one worker process with many threads. Add
　　　a second worker process and the accept lock seems to be
　　　lost. This might be an APR issue with how it deals with
　　　the child_init hook (i.e. the fcntl lock needs to be resynced).
　　　More examination and analysis is required.
　　　　Status: Works with FreeBSD 5.3. Does not work in previous versions.
　　　　　　　　This has also been reported on Cygwin.

[986 root▲ ★ NG NG]

>>985
そういえば、ありましたね。

こんどいやなことがおきたら、思い切ってやってみるかも。

[987 root▲ ★ NG NG]

…といいながら、今実験してみるかな。

ちょっと、やってみます。

[988 root▲ ★ NG NG]

<IfModule mpm_worker_module>
StartServers 1
Serverlimit 1
MaxClients 2048
MinSpareThreads 2048
MaxSpareThreads 2048
ThreadLimit 2048
ThreadsPerChild 2048
MaxRequestsPerChild 32000000
MaxMemFree 64000
</IfModule>

にしたら、configtest すると、

Performing sanity check on apache22 configuration:
WARNING: ThreadsPerChild of 2048 exceeds ThreadLimit value of 64
threads, lowering ThreadsPerChild to 64. To increase, please see the
ThreadLimit directive.
WARNING: MaxClients of 2048 would require 32 servers,
and would exceed the ServerLimit value of 1.
Automatically lowering MaxClients to 64. To increase,
please see the ServerLimit directive.
Syntax OK

となるようです。

[989 root▲ ★ NG NG]

あと、
・やはり、過去ログの rsync は少なからず負荷になっているっぽい

かな。
過去ログの rsync をするフロントは1台にするのが、よさげみたい。

[990 root▲ ★ NG NG]

さて、Part20も終盤に差し掛かったようです。

・２ちゃんねるラック at XOロケーションの電源問題
・アクセスがヘビーだと虫を踏んでしまう問題
・携帯フルブラウザから書き込む場合の諸条件
(これは２ちゃんねるの規制のコンセプトにもからむ)

など、今回のスレは話題抱負だったように思います。

もうちょっとしたら、次スレ立てます。

[991 株価【650】 ▲ ◆cZfSunOs.U 2006/04/15(土) 23:46:05 ID:bxoh0yJy0]

>>988 worker.c の処理を見ると

・ MaxClients の前に ThreadsPerChild を設定
・ ThreadsPerChild の前に ThreadLimit を設定

じゃないとダメっぽいです．

[992 root▲ ★ NG NG]

>>991
つまり、ThreadLimit, ThreadsPerChild, MaxClients の順でやれと。
やってみます。

[993 root▲ ★ NG NG]

<IfModule mpm_worker_module>
# StartServers 32
# ServerLimit 32
# ThreadLimit 64
# ThreadsPerChild 64
StartServers 2
ServerLimit 2
ThreadLimit 1024
ThreadsPerChild 1024
MaxClients 2048
MinSpareThreads 2048
MaxSpareThreads 2048
MaxRequestsPerChild 32000000
MaxMemFree 64000
</IfModule>

で、うまくいきました。

1 と 2048 だと、Apache がちゃんと増えないみたい。

[994 root▲ ★ NG NG]

あとは、次スレでやりますか。

準備はじめます。

[995 root▲ ★ NG NG]

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

[996 株価【650】 ▲ ◆cZfSunOs.U 2006/04/16(日) 00:23:08 ID:tLC8VCxI0]

>>995 乙です．

[997 動け動けウゴウゴ２ちゃんねる 2006/04/16(日) 00:27:12 ID:xi8cthtA0]

おつですー
家庭の保守はこまめにね！

[998 動け動けウゴウゴ２ちゃんねる 2006/04/16(日) 02:36:05 ID:Gf32UvAS0]

ぬ

[999 動け動けウゴウゴ２ちゃんねる 2006/04/16(日) 02:38:01 ID:grFxUKmp0]

る

[1000 動け動けウゴウゴ２ちゃんねる 2006/04/16(日) 02:38:32 ID:zUKwKF8F0]

ぽ