0001root▲ ★NGNG
2ch特化型サーバ・ロケーション構築作戦のスレッドです。
・２ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更まわりの関連作業・調整事項
・２ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携
等を取り扱います。
現在、複数サーバによる連携により、
サーバ能力のさらなるスケールアップをめざすための「雪だるま作戦」が進行中です。
また、次世代の携帯アクセス環境をめざした「べっかんこ作戦」も稼動しはじめました。
「２ちゃんねる証券取引所」や、「Be」の機能強化等、
２ちゃんねるは今日も変化し続けています。
前スレ:
2ch特化型サーバ・ロケーション構築作戦 Part19
http://qb5.2ch.net/test/read.cgi/operate/1121886018/ Just idea ですが、
read.cgi と offlaw.cgi を動かすフロントを1台とか2台にしてしまえば、
過去ログの同期(rsync)するサーバも、それだけで済むのかな。
あるいは、一度負けた NFS を使うか。
どう実現するにせよ、スケーラブルにしたいところかなと。
いずれにせよ「過去ログ倉庫に保管されています」の判定部分なんですよね。
public_html じゃないところを読んでいるところ。
専用ブラウザだと、302 だったら offlaw.cgi みたいな処理なので、
それなりになんとかなるわけですが。
… 本筋は read.cgi の改造かなぁ、やっぱ。
ずいぶん昔にも書いたような覚えがありますが
read.cgiのデータ処理部だけなら、全然重い処理じゃないですよ。
ディスクI/Oと圧縮が重いだけで。
.datの必要部分をHTMLにするだけなら、
毎秒500-1000件程度なら処理できると思います。
ただ、もしLAN上の別マシンを使うなら
やはりHTTP経由よりNFSの方が数段軽いでしょう。
カーネル内部で完了するというのは大きいです。
>>954 第一段落
私も同じ感覚を持っています。
dso 化した後は、少なくとも tiger サーバでは、
read.cgi が高負担になった記憶はないです。
ということは、read.cgi と offlaw.cgi の処理は、専用フロントにやらせると
よさげなのかな。
で、第二段落ですが、確かにそう思うわけですが、
なにぶん一度痛い目に遭っているので(5.4Rの頃ですが)、
少なくともシビアな I/O のところ(dat直読みするところとか)には、
ちと使いずらいところがありますね。
例のディレイ(書いたdatをすぐにNFS経由で読んだ時に起きたもの)が
きちんと解決できるような気がしないので、ライブなdatには、
ちと使いにくいかんじ。
過去ログのところには、うまくすれば使えるかもですが。 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のタイミングでエラーになることがありますね。
これについては、まあ、運用でそういうことはあんまりしないかなぁと思って、
個人的には無視していますけど。 NFS が正常に動くという前提なら，NFS 使うのが一番簡単かつスマートですね．
以前ボロボロだった時は，ファイル更新時の rename() とタイミングがかち合うと
その際に起こる ESTALE でカーネルごとコケてしまうということだったと思いますが，
過去ログだけならそういうことは起こりにくいでしょうし．
あと，過去ログが HDD 食い潰すって問題も併せて対応するとなると，
過去ログを memories に転送してそっちのを NFS mount するとか......
rootたん乙
俺は絶対rootたんの頭であぼんされているな。
それにしてもjigの人来ない。
もしかしたら2ch用のゲートウェイ作っているのかな。
// ATフィールドでイオナズン防げたらなぁ。
>>957
> 過去ログを memories に転送してそっちのを NFS mount するとか......
そんなことを考え始めていたりします。
で、前におかしくなったのは、ESTALE 問題もさることながら、
mount している方が一斉にデッドロックする問題ですね。
ps で見ると一斉に D の状態になって、kill -9 でももちろん死なないし、
どうしようもなくなると。
>>958
イオナズンの解析をした人かしら。
だとしたら特に、あぼーんはしてないと思うです。
bbs.cgi 的には、該当ルーチンを組み入れれば対応できるように組んであるので、
私としては技術情報が出たら、あとはたんたんと組むだけと。 で、memories は 5.3R なので、そのへんが心配だったりします。
6.1R が安定なら、バージョンアップもありかなとは思っていますが、
なにぶん慎重にやらないといけないサーバなので、
できれば(いつになるか…)、現地でやりたいかなと。
また破綻か、、、。
6.1-RC 投入するか、あるいは 6.1R が出るまで我慢するか。
>962
ここまで虫踏みまくって調子よくないようでしたら6.1-RC早期投入した方がいいと
思います。
umtx って mutex か何かでしょうか......
まぁ race condition を起こりにくくするということなら mod_cache というのもありますが(>>949)． <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
httpd が突如、暴走状態になりました。
CPUのidle timeがなくなったのと期を同じくしています。
というか、暴走になったからidle timeがなくなったのかなと。
で、1プロセスあたりのスレッド数を下げたのは、なんというか、勘ってやつです。
虫を踏むリスクが、減るんじゃないかなと。
MaxRequestsPerChild 32000000
も、1/8 にするかな。
× 1/8
○ 1/4
# MaxRequestsPerChild 32000000
MaxRequestsPerChild 8000000
にした。次回の起動時に有効に。
あとは、マルチスレッドなApacheがforkするのは、いくない気がするので、
最初から最大プロセスにしておくか。< live22
>>965-969 乙です．スレッド数減は有効かもですね．
>>970 ん〜それは......マルチスレッド MPM でも fork() するのは
シングルスレッドな親プロセスなんで...... >>971
なるほど、、、。
とりあえず、「常に最大プロセス数で待つ」設定にしてみた。
どうせ、それで動いても問題ないはずなので。 なるほど、プロセスが多いとだめみたい。
再度httpd落とし中。
<IfModule mpm_worker_module>
StartServers 384
Serverlimit 384
MaxClients 3072
MinSpareThreads 3072
MaxSpareThreads 3072
ThreadsPerChild 8
MaxRequestsPerChild 8000000
ThreadLimit 8
MaxMemFree 64000
</IfModule>
にした。
今はちゃんと動いているっぽい。
破綻はしないけど、やはり挙動不審になる模様。
さらにプロセス数を減少。httpd リスタート中。
またですね。
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
いったん httpd を落とし、
matd を落として入ってこないようにして、
httpd をスタートして、matd を再開。
<IfModule mpm_worker_module>
StartServers 256
Serverlimit 256
MaxClients 2048
MinSpareThreads 2048
MaxSpareThreads 2048
ThreadsPerChild 8
MaxRequestsPerChild 8000000
ThreadLimit 8
MaxMemFree 64000
</IfModule>
さらにプロセス数を減少。@ live22
<IfModule mpm_worker_module>
StartServers 64
Serverlimit 64
MaxClients 2048
MinSpareThreads 2048
MaxSpareThreads 2048
ThreadsPerChild 32
MaxRequestsPerChild 32000000
ThreadLimit 32
MaxMemFree 64000
</IfModule>
に変更。
>>980 の方が明らかに楽になり、CPU idle time も増えますね。
ううむ。 実験的に、
<IfModule mpm_worker_module>
StartServers 32
Serverlimit 32
MaxClients 2048
MinSpareThreads 2048
MaxSpareThreads 2048
ThreadsPerChild 64
MaxRequestsPerChild 32000000
ThreadLimit 64
MaxMemFree 64000
</IfModule>
にした。
プロセスが少なくてスレッド数が多いほうが、システムは楽みたいですね。
ただ、32と64では有意な差はあまりないっぽい気もします。
挙動不審なら、32に戻す方向で。
そういえばこんな話もあったような．むしろ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.
>>985
そういえば、ありましたね。
こんどいやなことがおきたら、思い切ってやってみるかも。 …といいながら、今実験してみるかな。
ちょっと、やってみます。
<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
となるようです。
あと、
・やはり、過去ログの rsync は少なからず負荷になっているっぽい
かな。
過去ログの rsync をするフロントは1台にするのが、よさげみたい。
さて、Part20も終盤に差し掛かったようです。
・２ちゃんねるラック at XOロケーションの電源問題
・アクセスがヘビーだと虫を踏んでしまう問題
・携帯フルブラウザから書き込む場合の諸条件
(これは２ちゃんねるの規制のコンセプトにもからむ)
など、今回のスレは話題抱負だったように思います。
もうちょっとしたら、次スレ立てます。
>>988 worker.c の処理を見ると
・ MaxClients の前に ThreadsPerChild を設定
・ ThreadsPerChild の前に ThreadLimit を設定
じゃないとダメっぽいです． >>991
つまり、ThreadLimit, ThreadsPerChild, MaxClients の順でやれと。
やってみます。 <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 がちゃんと増えないみたい。
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。