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

**root▲ ★** · NG

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

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

等を取り扱います。

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

また「２ちゃんねる証券取引所」をはじめとする「株」関連や「Be」の機能強化、
あるいは、次世代の携帯アクセス環境をめざした「べっかんこ作戦」の状況など、
気候も暖かくなり、そろそろ気になりだす季節にさしかかりつつある今日この頃、
あいかわらず２ちゃんねるは、刻一刻と確実に変化し続けています。

**root▲ ★** · NG

◆KONAN/fu2I · 2006/04/16(日) 00:21:09

>>1
乙！　(･∀･)ﾆﾔﾆﾔ

**root▲ ★** · NG

前スレからの課題
・削除関係の呪文の雪だるま対応 (すみませんまだ進んでいないです)
・live22 バックエンドの安定稼動 (先は長いですね)
・matd を用いた受付の安定稼動 (ほぼ解決、フロントエンドの自動切り離し要)
・mod_cache の導入によりバックエンドの負荷を下げる (squidとのマッチング要調査)
・DNS ラウンドロビンから matd への移行 (解決!)
・heartbeat を利用した受付の冗長化 (ucarpで解決!)

・電源食い杉どうしよう (未解決、一部サーバの移設をすすめる方向で)
・携帯フルブラウザからの書き込み対応 (しかけは完了、個別対応していけばOK)

重要な課題
・効率の良い金色会員維持 (進行中)
・家庭の保守 (・・・・・・)

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

ｵﾒ

＞・家庭の保守 (・・・・・・)
('A｀)

**root▲ ★** · NG

前スレでやったこと(1)

・ucarp/matdによる受付嬢の稼動
・www2の雪だるまへの収容(レンガ表示がスムーズに)
・www/menuのスタンバイ機作成(banana201
・携帯フルブラウザからの書き込み対応(情報を送信してもらえるケース、識別マークQ)
・FreeBSD 6.0R 実践投入、6.1-RC テスト投入(ex11/狼)
・Apache 2.2 + worker MPM, PHP 5.1.2 本格投入
・虫との闘い(継続中)

**root▲ ★** · NG

今のところの虫との闘いの記録

・libthrのほうがいろんな意味でよい
・カーネル作成時にPREEMPTION を切ること
・DEVICE_POLLING は有効かもしれない(ただしPREEMPTIONなしに限る)
・dsoのところがMT-safeではないので、Apache 2.2 にパッチが必要
・libthr やカーネルにいろいろパッチ当て

**root▲ ★** · NG

**root▲ ★** · NG

・プロセス数が多くてスレッド数が少ないのより、
プロセス数が少なくてスレッド数が多いほうがよい模様
http://qb5.2ch.net/test/read.cgi/operate/1140540754/983

・ThreadLimit, ThreadsPerChild, MaxClients には順番がある
http://qb5.2ch.net/test/read.cgi/operate/1140540754/991-992

**root▲ ★** · NG

で、
http://qb5.2ch.net/test/read.cgi/operate/1140540754/993
> 1 と 2048 だと、Apache がちゃんと増えないみたい。

ですが、

pid 32740 (httpd), uid 2001: exited on signal 11
pid 32741 (httpd), uid 2001: exited on signal 11
pid 32742 (httpd), uid 2001: exited on signal 11
pid 32743 (httpd), uid 2001: exited on signal 11
pid 32745 (httpd), uid 2001: exited on signal 11
pid 32746 (httpd), uid 2001: exited on signal 11
pid 32763 (httpd), uid 2001: exited on signal 11
...

となっていた模様。

**root▲ ★** · NG

で、本日寝る前に、PREEMPTION ありのカーネルに入れ替える作業する予定。< live22

**root▲ ★** · NG

あー、間違えた。DEVICE_POLLING ありでした。>>11

**root▲ ★** · NG

あと、前スレで登場されたjig.jpの中の方に伝言を。

新スレに変わったので、技術情報の準備ができたら、
こちらに書いていただけると助かりますです。

**動け動けウゴウゴ２ちゃんねる** · 2006/04/16(日) 01:28:04

>>10
kern.threads.max_threads_per_proc
kern.threads.max_groups_per_proc
は設定されてますか?
デフォルトは1500のはずなので、1プロセス2048スレッドなら設定が必要ですが。。

株価【650】 ▲ ◆cZfSunOs.U · 2006/04/16(日) 01:29:09

>>10 SIGSEGV ですか......これもちょっと不可解ですね．

**root▲ ★** · NG

>>14
してないですね。
なるほど、、、。

>>15
たぶん >>14 じゃないかなと。

**root▲ ★** · NG

SYSCTL_INT ですか。

ということは、sysctl すればよさげですね。

**root▲ ★** · NG

%sysctl kern.threads.max_threads_per_proc=4096
%sysctl kern.threads.max_groups_per_proc=4096
(2048ではだめでした)

で、

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

が動きました。

しかし子プロセス1つだと、
signal 10とか踏んだ時にまるごとぼーんと死んじゃう瞬間があるのかしら。

**root▲ ★** · NG

topでみると:

52301 ch2live22 2050 4 0 339M 110M accept 1 4:31 27.25% httpd

なるほど、2050というぐらいで2048 + 2 なわけですか。

株価【650】 ▲ ◆cZfSunOs.U · 2006/04/16(日) 01:38:33

>>14 >>16 そういうことですか......ただ，

rv = apr_thread_create(&threads[i], thread_attr,
worker_thread, my_info, pchild);
if (rv != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_ALERT, rv, ap_server_conf,
"apr_thread_create: unable to create worker thread");
/* let the parent decide how bad this really is */
clean_child_exit(APEXIT_CHILDSICK);
}

ということなんで，正常に exit() せず SIGSEGV ってのも妙ではありますが......

**root▲ ★** · NG

/etc/sysctl.conf に追加した。

# Thank you for AC, http://qb5.2ch.net/test/read.cgi/operate/1145114275/14
kern.threads.max_threads_per_proc=4096
kern.threads.max_groups_per_proc=4096

株価【650】 ▲ ◆cZfSunOs.U · 2006/04/16(日) 01:43:28

>>18
>しかし子プロセス1つだと、
>signal 10とか踏んだ時にまるごとぼーんと死んじゃう瞬間があるのかしら。

まぁそれが弱点といえば弱点ですね．ただ，これまで SIGBUS になった時は
どっちにしろ一気にどん詰まりになってるようなんで実際上あまり変わらないかもですが......

>>19 main 1 + listener 1 + worker 2048 ですね．

**動け動けウゴウゴ２ちゃんねる** · 2006/04/16(日) 01:43:57

>>14 のように書きましたが、
個人的には、1プロセスあたりのスレッド数をあまり多くするのは反対ですけどね。
多すぎず、少なすぎずがいいと思いますが。
でも、いろいろ試してみるのも良いかもしれませんね。

**root▲ ★** · NG

>>22-23
なるほど。

システムのデフォルトのリミット値を尊重して、
まずは 2 プロセス、1024 スレッドで試してみようかなと。

**root▲ ★** · NG

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

にした。@ live22

株価【650】 ▲ ◆cZfSunOs.U · 2006/04/16(日) 01:49:03

>>23 まぁこれは↓ということもあったんで．
http://qb5.2ch.net/test/read.cgi/operate/1140540754/985

ただ，一方でスレッド数を増やした際の挙動が心配というのも確かにありますが．

**root▲ ★** · NG

>>26
ですね。

ただ、虫踏みは prefork MPM でも発生することがわかっているので、
いずれにせよ起こるリスクはあるということで、
いろいろ実験してみる価値は、あるのかなと。

**動け動けウゴウゴ２ちゃんねる** · 2006/04/16(日) 02:07:15

>>22

前から不思議に思ってたのが

>ただ，これまで SIGBUS になった時は
>どっちにしろ一気にどん詰まりになってるようなんで実際上あまり変わらないかもですが......

の動作で、何で一度にSIGBUSになるんだろうなぁと思っていました。
仮に thread library の問題だとして、1プロセスが落ちるならわかるんですが、
どうして一度に複数落ちちゃうのかなぁと。
まあ、load average が異常にあがったら落ちちゃうとか、
MaxClients に達したら落ちちゃうとか考えられるかもですが、
少なくとも、うちじゃあ load average が1000になろうと MaxClients いっぱいになろうと
SIGBUSで落ちるのは見たことないです。。

**root▲ ★** · NG

後ろでmake -j 4 を動かすと、CPU idle timeがなくなり、
動きがぐにゃぐにゃになりました。< スレッドが多いと
8/256 にしたら、落ち着いたみたい。

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

**root▲ ★** · NG

ちなみにさっきおかしかった時は、top で見ると umtx という状態の httpd が
たくさんいました。たぶんですが、スレッドが多すぎなのかなと。

**root▲ ★** · NG

ということでこれは必要なさげなので、
/etc/sysctl.conf からコメントアウトした。

#kern.threads.max_threads_per_proc=4096
#kern.threads.max_groups_per_proc=4096

◆boot//5v0I · 2006/04/16(日) 02:15:10

>>30
ちょｗｗｗグーグル先生は休校ですか？

**root▲ ★** · NG

>>28
うーむ。そうですか。

この状態の時に signal 10 で落ちるのは、よく見かけるですね。

**動け動けウゴウゴ２ちゃんねる** · 2006/04/16(日) 02:17:07

>>30
umtxですか。
ucondならわかるんですが。

普段がacceptで、負荷の時にucondになるなら、
それは、空きworkerスレッドがないため、
listenerスレッドがworkerスレッドが空くのを待っている状態です。
つまり、ThreadsPerChildが256なら、256いっぱいいっぱいってことです。

**root▲ ★** · NG

>>34
ucond はこんな感じでみかけますね(現在の状態、カーネルmake中)。

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND
86396 root 132 0 12524K 11916K CPU2 2 0:02 62.53% cc1
86398 root 132 0 10240K 9668K CPU1 0 0:02 56.89% cc1
3633 ch2live22 97 0 2788K 1552K CPU3 3 12:45 3.52% bbsd
86388 root 129 0 732K 620K select 2 0:00 2.56% make
86229 root 96 0 5688K 4944K CPU0 3 0:00 1.38% top
77348 ch2live22 100 0 63504K 30708K select 3 1:25 0.88% httpd
77344 ch2live22 100 0 74416K 41728K select 0 1:25 0.49% httpd
77344 ch2live22 100 0 74416K 41728K select 0 1:25 0.34% httpd
77342 ch2live22 100 0 60492K 28796K select 0 1:25 0.34% httpd
77341 ch2live22 100 0 73844K 40696K select 3 1:25 0.29% httpd
77346 ch2live22 100 0 66564K 34484K select 3 1:26 0.24% httpd
77346 ch2live22 100 0 66564K 34484K ucond 3 1:26 0.24% httpd
77343 ch2live22 100 0 61928K 30148K ucond 0 1:26 0.24% httpd
77343 ch2live22 100 0 61928K 30148K select 0 1:26 0.24% httpd
77348 ch2live22 100 0 63504K 30708K select 0 1:25 0.24% httpd
77348 ch2live22 100 0 63504K 30708K ucond 0 1:25 0.24% httpd
77344 ch2live22 100 0 74416K 41728K ucond 1 1:25 0.24% httpd
77345 ch2live22 100 0 69808K 37128K select 0 1:25 0.24% httpd
77343 ch2live22 100 0 61928K 30148K select 1 1:26 0.20% httpd
77343 ch2live22 100 0 61928K 30148K ucond 0 1:26 0.20% httpd
77341 ch2live22 100 0 73844K 40696K select 0 1:25 0.20% httpd
77345 ch2live22 100 0 69808K 37128K select 0 1:25 0.20% httpd
77345 ch2live22 100 0 69808K 37128K ucond 0 1:25 0.20% httpd
77347 ch2live22 100 0 69160K 36336K select 0 1:24 0.20% httpd
77348 ch2live22 100 0 63504K 30708K select 0 1:25 0.15% httpd
77344 ch2live22 100 0 74416K 41728K ucond 0 1:25 0.15% httpd

**root▲ ★** · NG

>>34
> つまり、ThreadsPerChildが256なら、256いっぱいいっぱいってことです。

ということは、ucond ばかりになる時は、何らかの対策が必要と。

Apache status (server-statusで見られるやつ)を見る限り、余裕しゃくしゃくに見えますが、
それでもいっぱいになることがあるのかしら。

>>32
ん、何かまずかったかしら。