2ch特化型サーバ・ロケーション構築作戦のスレッドです。
・２ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更関連の各種作業や調整事項
・２ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携
等を取り扱います。
現在、複数サーバによる連携により、
サーバ能力のさらなるスケールアップをめざすための「雪だるま作戦」が進行中です。
しかし、問題はあらゆる意味で山積の状態です。
また「２ちゃんねる証券取引所」をはじめとする「株」関連や「Be」の機能強化、
あるいは、次世代の携帯アクセス環境をめざした「べっかんこ作戦」の状況など、
気候も暖かくなり、そろそろ気になりだす季節にさしかかりつつある今日この頃、
あいかわらず２ちゃんねるは、刻一刻と確実に変化し続けています。
2ch特化型サーバ・ロケーション構築作戦 Part21
■ このスレッドは過去ログ倉庫に格納されています
1root▲ ★
NGNG316root▲ ★
NGNG >>315
状況は全く同じですね。
まだ core 一つしか調べてないですが。
今の方針は明確に「勝ちに行く」なので、
修正が入っているはずの、最新の OS にバージョンアップをする予定。
ゴールデンウィーク明けまでに 6.1R が出ない場合、
6.1-RC2 でいこうと。
状況は全く同じですね。
まだ core 一つしか調べてないですが。
今の方針は明確に「勝ちに行く」なので、
修正が入っているはずの、最新の OS にバージョンアップをする予定。
ゴールデンウィーク明けまでに 6.1R が出ない場合、
6.1-RC2 でいこうと。
2006/05/02(火) 19:01:01ID:gD/Ndbla0
319モーマン☆鯛。
NGNG 乗り遅れ…
>>310
電源について,主幹と有りますが,そう呼んでしまうとトランス2次側からの電源が別系統で と
受け取ってしまいます。
要は「分電盤のブレーカーに空きがある」ということで良いのかしら？
という前提で 3)ですが,フル稼働時で万が一落ちた時に切り離し及び復帰が
問題なく行えるのか心配だったり。
逆に,x1〜x5がひとつのバックエンドとして利用でき,切り離し・復帰が問題なく行えるであろうと言うのであれば,
─live22
┌live22x1
├live22x2
└live22x3
┌live22x4
└live22x5
という具合に3系統に分けられると,フロントが落ちた時以外は冗長化が容易では無いかと。
>>310
電源について,主幹と有りますが,そう呼んでしまうとトランス2次側からの電源が別系統で と
受け取ってしまいます。
要は「分電盤のブレーカーに空きがある」ということで良いのかしら？
という前提で 3)ですが,フル稼働時で万が一落ちた時に切り離し及び復帰が
問題なく行えるのか心配だったり。
逆に,x1〜x5がひとつのバックエンドとして利用でき,切り離し・復帰が問題なく行えるであろうと言うのであれば,
─live22
┌live22x1
├live22x2
└live22x3
┌live22x4
└live22x5
という具合に3系統に分けられると,フロントが落ちた時以外は冗長化が容易では無いかと。
320root▲ ★
NGNG >>319
> 電源について,主幹と有りますが,そう呼んでしまうとトランス2次側からの電源が別系統で と
> 受け取ってしまいます。
すみませんです。
私の電気屋的知識は、所詮門前のなんたら。
> 要は「分電盤のブレーカーに空きがある」ということで良いのかしら？
です。
> という具合に3系統に分けられると,フロントが落ちた時以外は冗長化が容易では無いかと。
なるほどです。
ただまだ全貌を掌握しているわけではないので、
まずは一歩ずつ進めていこうかなと。
> 電源について,主幹と有りますが,そう呼んでしまうとトランス2次側からの電源が別系統で と
> 受け取ってしまいます。
すみませんです。
私の電気屋的知識は、所詮門前のなんたら。
> 要は「分電盤のブレーカーに空きがある」ということで良いのかしら？
です。
> という具合に3系統に分けられると,フロントが落ちた時以外は冗長化が容易では無いかと。
なるほどです。
ただまだ全貌を掌握しているわけではないので、
まずは一歩ずつ進めていこうかなと。
321root▲ ★
NGNG >>317
(gdb) thread 73
[Switching to thread 73 (Thread 0x81d5e00 (LWP 101639))]#0 0x2828b4b3 in kill
() from /lib/libc.so.6
(gdb) info frame
Stack level 0, frame at 0xbc0c5a40:
eip = 0x2828b4b3 in kill; saved eip Cannot access memory at address 0xbc0c5a3c
(gdb) info registers
eax 0x0 0
ecx 0xc3ae7fec -1011974164
edx 0xf7f5 63477
ebx 0xa 10
esp 0xbc0c5a3c 0xbc0c5a3c
ebp 0xbc0c5a58 0xbc0c5a58
esi 0x285c5000 677138432
edi 0x3c9 969
eip 0x2828b4b3 0x2828b4b3
eflags 0x200296 2097814
cs 0x33 51
ss 0x3b 59
ds 0x3b 59
es 0x3b 59
fs 0x3b 59
gs 0x1b 27
(gdb) thread 73
[Switching to thread 73 (Thread 0x81d5e00 (LWP 101639))]#0 0x2828b4b3 in kill
() from /lib/libc.so.6
(gdb) info frame
Stack level 0, frame at 0xbc0c5a40:
eip = 0x2828b4b3 in kill; saved eip Cannot access memory at address 0xbc0c5a3c
(gdb) info registers
eax 0x0 0
ecx 0xc3ae7fec -1011974164
edx 0xf7f5 63477
ebx 0xa 10
esp 0xbc0c5a3c 0xbc0c5a3c
ebp 0xbc0c5a58 0xbc0c5a58
esi 0x285c5000 677138432
edi 0x3c9 969
eip 0x2828b4b3 0x2828b4b3
eflags 0x200296 2097814
cs 0x33 51
ss 0x3b 59
ds 0x3b 59
es 0x3b 59
fs 0x3b 59
gs 0x1b 27
322root▲ ★
NGNG (gdb) thread 14
[Switching to thread 14 (Thread 0x8249900 (LWP 100922))]#0 0x2828b4b3 in kill
() from /lib/libc.so.6
(gdb) where
#0 0x2828b4b3 in kill () from /lib/libc.so.6
Cannot access memory at address 0xb858aa3c
(gdb) info frame
Stack level 0, frame at 0xb858aa40:
eip = 0x2828b4b3 in kill; saved eip Cannot access memory at address 0xb858aa3c
(gdb) info registers
eax 0x0 0
ecx 0xab590bbd -1420227651
edx 0xf7f5 63477
ebx 0xa 10
esp 0xb858aa3c 0xb858aa3c
ebp 0xb858aa58 0xb858aa58
esi 0x285b2000 677060608
edi 0xa7 167
eip 0x2828b4b3 0x2828b4b3
eflags 0x200296 2097814
cs 0x33 51
ss 0x3b 59
ds 0x3b 59
es 0x3b 59
fs 0x3b 59
gs 0x1b 27
[Switching to thread 14 (Thread 0x8249900 (LWP 100922))]#0 0x2828b4b3 in kill
() from /lib/libc.so.6
(gdb) where
#0 0x2828b4b3 in kill () from /lib/libc.so.6
Cannot access memory at address 0xb858aa3c
(gdb) info frame
Stack level 0, frame at 0xb858aa40:
eip = 0x2828b4b3 in kill; saved eip Cannot access memory at address 0xb858aa3c
(gdb) info registers
eax 0x0 0
ecx 0xab590bbd -1420227651
edx 0xf7f5 63477
ebx 0xa 10
esp 0xb858aa3c 0xb858aa3c
ebp 0xb858aa58 0xb858aa58
esi 0x285b2000 677060608
edi 0xa7 167
eip 0x2828b4b3 0x2828b4b3
eflags 0x200296 2097814
cs 0x33 51
ss 0x3b 59
ds 0x3b 59
es 0x3b 59
fs 0x3b 59
gs 0x1b 27
323root▲ ★
NGNG とりあえず、二つ分。
2006/05/03(水) 04:45:06ID:qpNDFpsT0
>>321-323
情報どうもです。
ちょっとだけ光が見えてきたような気がします。
こうなるとVMのマップ状態が知りたくなってくるんですが、
/usr/ports/sysutils/procmap を使用して、現在稼働中のhttpdのマップ状態を
見ることは可能でしょうか?
なお、procmapはprocfsを必要としますので、現在mountしてないのでしたら、
一時的にでもmountする必要があります。
あと、kern.dflssiz, kern.maxssiz, kern.sgrowsiz等は設定されてますでしょうか?
また、Apacheの設定でThreadStackSizeは設定されてますでしょうか?
情報どうもです。
ちょっとだけ光が見えてきたような気がします。
こうなるとVMのマップ状態が知りたくなってくるんですが、
/usr/ports/sysutils/procmap を使用して、現在稼働中のhttpdのマップ状態を
見ることは可能でしょうか?
なお、procmapはprocfsを必要としますので、現在mountしてないのでしたら、
一時的にでもmountする必要があります。
あと、kern.dflssiz, kern.maxssiz, kern.sgrowsiz等は設定されてますでしょうか?
また、Apacheの設定でThreadStackSizeは設定されてますでしょうか?
2006/05/03(水) 11:48:39ID:qpNDFpsT0
2006/05/03(水) 11:53:27ID:qpNDFpsT0
次に、>>326の結果を利用して、関数呼び出しの流れが取得可能か試す。
(gdb) p/a *(0xbc0c5a58 + 4)
$11 = ...
(gdb) p/a *(0xXXXXXXXX + 4)
$12 = ...
(gdb) p/a *(0xYYYYYYYY + 4)
...
うまくいけば、関数名が表示されると思います。
(gdb) p/a *(0xbc0c5a58 + 4)
$11 = ...
(gdb) p/a *(0xXXXXXXXX + 4)
$12 = ...
(gdb) p/a *(0xYYYYYYYY + 4)
...
うまくいけば、関数名が表示されると思います。
328root▲ ★
NGNG329む P211018235141.ppp.prin.ne.jp
2006/05/03(水) 18:57:25ID:IAaJAFY00 外からですが、
見ていると、プロセスあたりのスレッド数が32の時のほうが、パフォーマンスは出るような感じですね。
でもそれだと、虫を踏んだ時にLAがめちゃくちゃ上がって、瀕死状態になってしまうと。
見ていると、プロセスあたりのスレッド数が32の時のほうが、パフォーマンスは出るような感じですね。
でもそれだと、虫を踏んだ時にLAがめちゃくちゃ上がって、瀕死状態になってしまうと。
330root▲ ★
NGNG まずは。
live22、signal 10 でのダウン(虫ふみ)多数。
別途解析すすめる予定。
live22, live22x1 は重くなった局面あり。
プライベート接続側の受信バッファがあふれた模様。
May 3 02:30:34 <0.4> tiger2522 kernel: em1: RX overrun
May 3 02:47:17 <0.4> tiger2522 kernel: em1: RX overrun
May 3 05:04:32 <0.4> tiger2522 kernel: em1: RX overrun
May 3 05:00:00 <0.4> tiger2523 kernel: em1: RX overrun
May 3 05:00:00 <0.4> tiger2523 last message repeated 2 times
live22x2 特に異常なし。
live22x3 リブートかかった模様、原因不明(メッセージなし)。
それとは別にこんなメッセージが。
やや不吉なるも、とりあえず経過観察。
May 3 08:49:50 <0.2> tiger2525 kernel: ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=94099079
live22、signal 10 でのダウン(虫ふみ)多数。
別途解析すすめる予定。
live22, live22x1 は重くなった局面あり。
プライベート接続側の受信バッファがあふれた模様。
May 3 02:30:34 <0.4> tiger2522 kernel: em1: RX overrun
May 3 02:47:17 <0.4> tiger2522 kernel: em1: RX overrun
May 3 05:04:32 <0.4> tiger2522 kernel: em1: RX overrun
May 3 05:00:00 <0.4> tiger2523 kernel: em1: RX overrun
May 3 05:00:00 <0.4> tiger2523 last message repeated 2 times
live22x2 特に異常なし。
live22x3 リブートかかった模様、原因不明(メッセージなし)。
それとは別にこんなメッセージが。
やや不吉なるも、とりあえず経過観察。
May 3 08:49:50 <0.2> tiger2525 kernel: ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=94099079
331root▲ ★
NGNG ex14は大きな破綻なしか。
cobra、強いなぁ。
cobra、強いなぁ。
332root▲ ★
NGNG live22x3、また変なリブート入った。
おかしいな。
おかしいな。
333root▲ ★
NGNG live22x3 は、ログインして状況確認中。
メールチェックしてきます。
作業終わっているといいな。
メールチェックしてきます。
作業終わっているといいな。
334root▲ ★
NGNG live22x3、いけませんね。
受付嬢の設定変えて、フロントエンドからはずします。
受付嬢の設定変えて、フロントエンドからはずします。
335root▲ ★
NGNG live22x3 は、ハードウェアトラブルっぽいですね。
いろいろ手配します。
matd の設定いじって、とりあえずフロントエンドからはずしました。
いろいろ手配します。
matd の設定いじって、とりあえずフロントエンドからはずしました。
336root▲ ★
NGNG live22x4, live22x5, cobra2247(= live22-2 予定)
電源移設作業完了したとの連絡が入りました。
ということで、雪だるま作戦本格再開です。
OSバージョンアップ、設定仕込み等、たんたんとすすめるということで。
電源移設作業完了したとの連絡が入りました。
ということで、雪だるま作戦本格再開です。
OSバージョンアップ、設定仕込み等、たんたんとすすめるということで。
337root▲ ★
NGNG tiger2525(= live22x3)、remote KVM でチェックしました。
HDD コントローラからエラー出まくり。
HDD or HDD コントローラがあぼーんした模様。
tiger503/507/cobra2247 の作業ありがとうメールに、
tiger2525 の緊急対応を依頼しました。
# ちなみに、tiger2525 はフロントの1台なので、
# 仮に HDD 完全あぼーんでも、交換して OS 入れれば問題なし。
HDD コントローラからエラー出まくり。
HDD or HDD コントローラがあぼーんした模様。
tiger503/507/cobra2247 の作業ありがとうメールに、
tiger2525 の緊急対応を依頼しました。
# ちなみに、tiger2525 はフロントの1台なので、
# 仮に HDD 完全あぼーんでも、交換して OS 入れれば問題なし。
338root▲ ★
NGNG tiger2525 (= live22x3) は、HDD あぼーんとのこと。
HDD 交換・OS 再インストールで中の人と調整中。
HDD 交換・OS 再インストールで中の人と調整中。
339root▲ ★
NGNG もののけ姫までに、
・live22x3 復活 & フロントに再投入
・live22x4, live22x5, live22-2 投入 with FreeBSD 6.1-RC2 or 6.1R
・live22, live22x[12] OS バージョンアップ + Apache 更新
をめざすことにしよう。
・live22x3 復活 & フロントに再投入
・live22x4, live22x5, live22-2 投入 with FreeBSD 6.1-RC2 or 6.1R
・live22, live22x[12] OS バージョンアップ + Apache 更新
をめざすことにしよう。
341root▲ ★
NGNG 過去ログ(NFS経由)を、すいているlive22のパブリック側で
アクセスするようにしてみた。
アクセスするようにしてみた。
342root▲ ★
NGNG live22x4, live22x5 をフロントに再投入。
・OS は 6.1-RC2
%uname -a
FreeBSD tiger507.maido3.com 6.1-RC2 FreeBSD 6.1-RC2 #0: Wed May 3 23:09:45 PDT 2006 root@tiger507.maido3.com:/var/src/sys/i386/compile/I386_TIGER_61 i386
・Apache 2.2.2 + patch + worker MPM + libthr
・カーネルパッチ(FD_SETSIZE) とりあえず導入せず
・PREEMPTION とりあえず有効
・OS は 6.1-RC2
%uname -a
FreeBSD tiger507.maido3.com 6.1-RC2 FreeBSD 6.1-RC2 #0: Wed May 3 23:09:45 PDT 2006 root@tiger507.maido3.com:/var/src/sys/i386/compile/I386_TIGER_61 i386
・Apache 2.2.2 + patch + worker MPM + libthr
・カーネルパッチ(FD_SETSIZE) とりあえず導入せず
・PREEMPTION とりあえず有効
343root▲ ★
NGNG 以降の予定
cobra2247 稼動
フロントエンドを切り替えつつ、バージョンアップ
バックエンドバージョンアップ(この際にはサービス停止)
cobra2247 稼動
フロントエンドを切り替えつつ、バージョンアップ
バックエンドバージョンアップ(この際にはサービス停止)
344root▲ ★
NGNG cobra2247、バージョンアップの準備していたら
いきなりハングアップした。
KVM 画面もフリーズしている模様。ううむ。
いきなりハングアップした。
KVM 画面もフリーズしている模様。ううむ。
345root▲ ★
NGNG 見たところ、カーネルパニックしている模様。
ううむ。
ちょっと、しらべてみます。
ううむ。
ちょっと、しらべてみます。
346root▲ ★
NGNG savecore: reboot after panic: spin lock held too long
ううむ、これって。
ううむ、これって。
347root▲ ★
NGNG いったん single CPU の kernel に替えてみるか。
なんだかだけど。
なんだかだけど。
>>347
まだソースがガシガシ更新されているから虫がいるんですかね？
まだソースがガシガシ更新されているから虫がいるんですかね？
349root▲ ★
NGNG >>348
まだ 6.0R のままなんですよ。< cobra2247
make buildworld の間に panic したという。
ほぼ同じハードウェア構成で 6.0R な ex14 はちゃんと動いているので、
ハードウェア障害の予感も。
まだ 6.0R のままなんですよ。< cobra2247
make buildworld の間に panic したという。
ほぼ同じハードウェア構成で 6.0R な ex14 はちゃんと動いているので、
ハードウェア障害の予感も。
350root▲ ★
NGNG カーネル作っている間にまた固まった、、、。 < cobra2247
352root▲ ★
NGNG しばらく待ってだめなら、リブート要請を再度出すということで。
(さっき一度出したのですが、その後ちゃんとパニックしてくれたので
いったんキャンセルした)
(さっき一度出したのですが、その後ちゃんとパニックしてくれたので
いったんキャンセルした)
354root▲ ★
NGNG だめなようですね。
リブート要請します。< cobra2247
リブート要請します。< cobra2247
355root▲ ★
NGNG >>325
> あと、kern.dflssiz, kern.maxssiz, kern.sgrowsiz等は設定されてますでしょうか?
> また、Apacheの設定でThreadStackSizeは設定されてますでしょうか?
http://httpd.apache.org/docs/2.2/ja/mod/mpm_common.html#threadstacksize
スタックオーバー風呂ということなら、
大きくする、という手はあるのかも。
> あと、kern.dflssiz, kern.maxssiz, kern.sgrowsiz等は設定されてますでしょうか?
> また、Apacheの設定でThreadStackSizeは設定されてますでしょうか?
http://httpd.apache.org/docs/2.2/ja/mod/mpm_common.html#threadstacksize
スタックオーバー風呂ということなら、
大きくする、という手はあるのかも。
357root▲ ★
NGNG <IfModule mpm_worker_module>
ThreadStackSize 262144
StartServers 64
ServerLimit 64
ThreadLimit 32
ThreadsPerChild 32
MaxSpareThreads 2048
MinSpareThreads 2048
MaxSpareThreads 2048
MaxRequestsPerChild 32000000
MaxMemFree 64000
</IfModule>
にしてみた。< live22
前に read.cgi のことをやった時に、確か SunOS さんが
65536 がデフォルトって言っていたっぽいような気がするので、
とりあえずスタックサイズを4倍にしてみたつもり。
ThreadStackSize 262144
StartServers 64
ServerLimit 64
ThreadLimit 32
ThreadsPerChild 32
MaxSpareThreads 2048
MinSpareThreads 2048
MaxSpareThreads 2048
MaxRequestsPerChild 32000000
MaxMemFree 64000
</IfModule>
にしてみた。< live22
前に read.cgi のことをやった時に、確か SunOS さんが
65536 がデフォルトって言っていたっぽいような気がするので、
とりあえずスタックサイズを4倍にしてみたつもり。
358root▲ ★
NGNG %uname -a
FreeBSD tiger2524.maido3.com 6.1-RC2 FreeBSD 6.1-RC2 #0: Thu May 4 10:04:11 PDT 2006 root@tiger2524.maido3.com:/home/src/sys/i386/compile/I386_TINYTIGER_61 i386
@ live22x2
FreeBSD tiger2524.maido3.com 6.1-RC2 FreeBSD 6.1-RC2 #0: Thu May 4 10:04:11 PDT 2006 root@tiger2524.maido3.com:/home/src/sys/i386/compile/I386_TINYTIGER_61 i386
@ live22x2
2006/05/05(金) 03:33:44ID:b3qevcS80
>>357
FreeBSD 6.x のデフォルトのスレッドスタックサイズは1MBです。
FreeBSD 6.x のデフォルトのスレッドスタックサイズは1MBです。
360root▲ ★
NGNG >>355 >>357
リンク先を読んでみると、
スレッドスタックサイズのデフォルト値が比較的小さく設定されている プラットホーム
(例えば HP-UX) では、自動変数用の領域で大きな容量を 使用するサードパーティ製
モジュールのために Apache がクラッシュする 場合もあります。そのモジュールは他の
プラットホームでは スタックサイズが大きいために、快調に動作するかもしれません。
このタイプのクラッシュは、ThreadStackSize で OS のデフォルト値より大きな値を指定
することで解決します。 サードパーティ製モジュールでこの処置が必要であると記載
されている 場合か、Apache の出力するメッセージでスレッドスタックサイズが
小さすぎると指摘されている場合にのみ、この調整をしてください。
デフォルトスレッドスタックサイズが、Web サーバ用途に必要な量よりも 明らかに
大きすぎる場合、ThreadStackSize を OS のデフォルト値よりも小さな値にすることで、
子プロセスあたりの スレッド数をより多く持たせられるようになります。 このタイプの
調整は、テスト環境でウェブサーバを完全に テストできる場合に限って行なうべきです。
まれに多数のスタックが要求されるリクエストを受けることがあるかも しれないからです。
Web サーバの設定を変更すると、現在の ThreadStackSize の設定が取り消される
場合があります。
…ううむ、大きくするのがよいのか、小さくするのがよいのか。
あるいは実はあまり効果がないのか。
とりあえず、今は >>357 にしておくか。
リンク先を読んでみると、
スレッドスタックサイズのデフォルト値が比較的小さく設定されている プラットホーム
(例えば HP-UX) では、自動変数用の領域で大きな容量を 使用するサードパーティ製
モジュールのために Apache がクラッシュする 場合もあります。そのモジュールは他の
プラットホームでは スタックサイズが大きいために、快調に動作するかもしれません。
このタイプのクラッシュは、ThreadStackSize で OS のデフォルト値より大きな値を指定
することで解決します。 サードパーティ製モジュールでこの処置が必要であると記載
されている 場合か、Apache の出力するメッセージでスレッドスタックサイズが
小さすぎると指摘されている場合にのみ、この調整をしてください。
デフォルトスレッドスタックサイズが、Web サーバ用途に必要な量よりも 明らかに
大きすぎる場合、ThreadStackSize を OS のデフォルト値よりも小さな値にすることで、
子プロセスあたりの スレッド数をより多く持たせられるようになります。 このタイプの
調整は、テスト環境でウェブサーバを完全に テストできる場合に限って行なうべきです。
まれに多数のスタックが要求されるリクエストを受けることがあるかも しれないからです。
Web サーバの設定を変更すると、現在の ThreadStackSize の設定が取り消される
場合があります。
…ううむ、大きくするのがよいのか、小さくするのがよいのか。
あるいは実はあまり効果がないのか。
とりあえず、今は >>357 にしておくか。
363root▲ ★
NGNG だんだん、思い出してきました。
前は、dso 版 read.cgi でこの局面になったですね。
auto 変数で 512M のバッファとかとっていて、
それが Apache 2.0 の worker MPM ではうまく動かなかったんでした。
ちょっと、過去ログを見てみるか。
前は、dso 版 read.cgi でこの局面になったですね。
auto 変数で 512M のバッファとかとっていて、
それが Apache 2.0 の worker MPM ではうまく動かなかったんでした。
ちょっと、過去ログを見てみるか。
367root▲ ★
NGNG × 512M
○ 512K
○ 512K
それはヒープ? >>366
2006/05/05(金) 03:46:14ID:b3qevcS80
>>361
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libthr/thread/thr_private.h.diff?r1=1.42&r2=1.43
なので、1048576。
あと、64bit だと2MBがデフォルトですね。
65536は、5.4までのデフォルト。
(5.5は6.xと同じになるみたいです)
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libthr/thread/thr_private.h.diff?r1=1.42&r2=1.43
なので、1048576。
あと、64bit だと2MBがデフォルトですね。
65536は、5.4までのデフォルト。
(5.5は6.xと同じになるみたいです)
371root▲ ★
NGNG read.cgi の件は、これですね。
read.cgi再開発スレ Part2
http://qb5.2ch.net/test/read.cgi/operate/1105909861/428 あたり。
read.cgi再開発スレ Part2
http://qb5.2ch.net/test/read.cgi/operate/1105909861/428 あたり。
373root▲ ★
2006/05/05(金) 03:48:29ID:???0375root▲ ★
2006/05/05(金) 03:49:50ID:???0 ということは、これではないっぽい、、、のかな。
あるいは 1M にしたことが、副作用を呼んでいるのか。< live22x
# ってことは、Apacheのドキュメントにあるように
# あえて少なくする(5.4Rの時のように)ことも、ありなのかしら。
あるいは 1M にしたことが、副作用を呼んでいるのか。< live22x
# ってことは、Apacheのドキュメントにあるように
# あえて少なくする(5.4Rの時のように)ことも、ありなのかしら。
どれだけ同時に起動されていて
どのように使っているのかわからないので、一概には言えないけど、
もと 65536 を read.dso に渡していたならそれを巨大にするのはかなり危険かも、
ただし Apache等で必要ならまた別の話ですが、
どのように使っているのかわからないので、一概には言えないけど、
もと 65536 を read.dso に渡していたならそれを巨大にするのはかなり危険かも、
ただし Apache等で必要ならまた別の話ですが、
378root▲ ★
2006/05/05(金) 03:55:19ID:???0 >>377
live22 は read.cgi 動いてないですが、
フロントにも同じことがいえるのかもですね。 < read.cgi の話
で、FreeBSD 6.0R で変わった(でかくなった)とすると、
そこの部分を元のように＊減らして＊みる、というのは、
意味があることなのかも。
live22 は read.cgi 動いてないですが、
フロントにも同じことがいえるのかもですね。 < read.cgi の話
で、FreeBSD 6.0R で変わった(でかくなった)とすると、
そこの部分を元のように＊減らして＊みる、というのは、
意味があることなのかも。
379root▲ ★
NGNG FreeBSD 6.0R では、こうか。
/*
* Miscellaneous definitions.
*/
#define THR_STACK_DEFAULT (sizeof(void *) / 4 * 1024 * 1024)
/*
* Miscellaneous definitions.
*/
#define THR_STACK_DEFAULT (sizeof(void *) / 4 * 1024 * 1024)
380root▲ ★
NGNG SunOS さんが試したのは、5.3R か。
read.cgi再開発スレ Part2
http://qb5.2ch.net/test/read.cgi/operate/1105909861/482
5.4R まで … 一律64K
6.0R, 5.5R 以降 … 32bit だと 1M 、64bit だと 2M
ということですか。
read.cgi再開発スレ Part2
http://qb5.2ch.net/test/read.cgi/operate/1105909861/482
5.4R まで … 一律64K
6.0R, 5.5R 以降 … 32bit だと 1M 、64bit だと 2M
ということですか。
382root▲ ★
NGNG という前提で >>360 を読むと、
> ThreadStackSize を OS のデフォルト値よりも小さな値にすることで、
> 子プロセスあたりの スレッド数をより多く持たせられるようになります。
が、とても気になりますね。
> ThreadStackSize を OS のデフォルト値よりも小さな値にすることで、
> 子プロセスあたりの スレッド数をより多く持たせられるようになります。
が、とても気になりますね。
2006/05/05(金) 04:11:39ID:b3qevcS80
通常、減らすのは、
ThreadsPerChild に 3000 とか、大きな値を指定する場合で、
普通なら減らす必要はないと思います。
ThreadsPerChild に 3000 とか、大きな値を指定する場合で、
普通なら減らす必要はないと思います。
385root▲ ★
NGNG つまり、これで試してみることには、おおいに意味があるかもしれないと。
スタック使いすぎでスワップが発生しているなら意味があるのではないかなぁ
そうでないなら意味ないと思う
そうでないなら意味ないと思う
「スタック使いすぎで」はランボーないい方か、
子供たちにスタックを与えすぎて合計のメモリが逼迫しているならってことです
子供たちにスタックを与えすぎて合計のメモリが逼迫しているならってことです
390root▲ ★
NGNG …さて、そんななか明日以降の予定。
○ live22x4, live22x5 フロントに再投入(済)
○ live22x2 OS・Apache 更新(済)
・live22x3 復活 & フロントに再投入
・live22-2 (= cobra2247) 投入 with FreeBSD 6.1-RC2 or 6.1R => まずは問題解決しないと
・live22, live22x1 OS バージョンアップ + Apache 更新
○ live22x4, live22x5 フロントに再投入(済)
○ live22x2 OS・Apache 更新(済)
・live22x3 復活 & フロントに再投入
・live22-2 (= cobra2247) 投入 with FreeBSD 6.1-RC2 or 6.1R => まずは問題解決しないと
・live22, live22x1 OS バージョンアップ + Apache 更新
391root▲ ★
NGNG2006/05/05(金) 04:31:56ID:b3qevcS80
>>325は私の書き込みですが、
procmapを使用して、VMのマッピング状態をみることにより、
Cannot access memory at address 0xXXXXXXXX の
0xXXXXXXXX がマッピングされているのか、
そのアドレスがスレッドスタック領域内か付近か見たかったわけです。
FreeBSDはgrow stackを使用するので、スレッドスタックが1MBだとしても、
最初は128kの領域しか取りません。以後は必要において1MBまで拡張されます。
通常の状態であれば、procmapを使って稼働中のhttpdの状態を見たときは、
下の方に多くの128kの領域があるはずです。
もし、スタックが拡張されていれば128k+拡張された領域が見えます。
procmapを使用して、VMのマッピング状態をみることにより、
Cannot access memory at address 0xXXXXXXXX の
0xXXXXXXXX がマッピングされているのか、
そのアドレスがスレッドスタック領域内か付近か見たかったわけです。
FreeBSDはgrow stackを使用するので、スレッドスタックが1MBだとしても、
最初は128kの領域しか取りません。以後は必要において1MBまで拡張されます。
通常の状態であれば、procmapを使って稼働中のhttpdの状態を見たときは、
下の方に多くの128kの領域があるはずです。
もし、スタックが拡張されていれば128k+拡張された領域が見えます。
2006/05/05(金) 04:36:01ID:b7udRDHi0
スタックを小さくするのは、単にアドレス空間の枯渇を防ぐためですよ。
例えば某OSのデフォルトだと、スタックは1スレッドあたり10M程。
ということは、32bit環境では、どんなに頑張っても
400スレッド(事実上200以下)しか出来ないわけですね。
これを増やすために、1スレッドのサイズを減らすということで。
例えば某OSのデフォルトだと、スタックは1スレッドあたり10M程。
ということは、32bit環境では、どんなに頑張っても
400スレッド(事実上200以下)しか出来ないわけですね。
これを増やすために、1スレッドのサイズを減らすということで。
2006/05/05(金) 04:37:17ID:b3qevcS80
kern.dflssiz, kern.maxssiz, kern.sgrowsiz は、
これらを設定した方が良いという意味ではなくて、
設定することにより動きが変わってくるので、確認の意味で書きました。
特に、kern.sgrowsizは、上記の最初の128kというサイズに影響を与えます。
kern.dflssiz, kern.maxssiz は、limit などで表示されるスレッドの制限に
影響を与えますが、これは最初の main スレッドの制限なので、
worker の場合はあまり関係ありません。
これらを設定した方が良いという意味ではなくて、
設定することにより動きが変わってくるので、確認の意味で書きました。
特に、kern.sgrowsizは、上記の最初の128kというサイズに影響を与えます。
kern.dflssiz, kern.maxssiz は、limit などで表示されるスレッドの制限に
影響を与えますが、これは最初の main スレッドの制限なので、
worker の場合はあまり関係ありません。
2006/05/05(金) 04:51:09ID:b3qevcS80
>>393
そうですね。
FreeBSDはi386(32bit)だと、デフォルトのサイズは1MBなので、
デフォルトでは2500弱のスレッドしか作れないです。
よって、ThreadsPerChildもそのあたりが限界。
もし、ThreadsPerChildを3000とかにすると、pthread_create()が失敗するので、
Apacheが起動できません。
そうですね。
FreeBSDはi386(32bit)だと、デフォルトのサイズは1MBなので、
デフォルトでは2500弱のスレッドしか作れないです。
よって、ThreadsPerChildもそのあたりが限界。
もし、ThreadsPerChildを3000とかにすると、pthread_create()が失敗するので、
Apacheが起動できません。
2006/05/05(金) 04:55:53ID:b3qevcS80
>>395
それは、amd64(64bit)ではなくて、i386(32bit)の話という意味でしょうか?
それは、amd64(64bit)ではなくて、i386(32bit)の話という意味でしょうか?
2006/05/05(金) 05:01:22ID:b3qevcS80
設定うんぬんということならば、
同じFreeBSDである限り、i386でもamd64でも変わらないでしょうが、
amd64だとVMのアドレス空間が莫大になるので、
アドレス空間の枯渇の問題は、ほぼ起こらないと思っていいでしょう。
同じFreeBSDである限り、i386でもamd64でも変わらないでしょうが、
amd64だとVMのアドレス空間が莫大になるので、
アドレス空間の枯渇の問題は、ほぼ起こらないと思っていいでしょう。
2006/05/05(金) 05:07:55ID:lGySeUIB0
なんか「おいでよどうぶつの森」の博物館の
フクロウさんを思い出したのは内緒です。
フクロウさんを思い出したのは内緒です。
2006/05/05(金) 05:10:59ID:b3qevcS80
あと、kern.sgrowsizを設定しているかどうかにより、
Red Zone が作成されるかどうかにも影響を与えます。
FreeBSDは Thread A のスタックと Thread B のスタックの間に
Red Zone と呼ばれるアクセス読み書き不可の領域をわざとつくり、
Thread A が Thread B のスタックを破壊するのを防ごうとします。
ただ、grow stack のせいで、デフォルトの設定だと
Red Zone が作成されないんですね。
kern.sgrowsizの設定を尋ねたのは、Red Zone が作成される設定になっているか
確認する意味もありました。
Red Zone が作成されるかどうかにも影響を与えます。
FreeBSDは Thread A のスタックと Thread B のスタックの間に
Red Zone と呼ばれるアクセス読み書き不可の領域をわざとつくり、
Thread A が Thread B のスタックを破壊するのを防ごうとします。
ただ、grow stack のせいで、デフォルトの設定だと
Red Zone が作成されないんですね。
kern.sgrowsizの設定を尋ねたのは、Red Zone が作成される設定になっているか
確認する意味もありました。
なんか 何十年たっても結局同じ話をしているんだなぁ
面白いっすね、
これからプログラムを書こうという人は是非ここを学んで欲しいと思ったりなんかして、
hehehe
面白いっすね、
これからプログラムを書こうという人は是非ここを学んで欲しいと思ったりなんかして、
hehehe
2006/05/05(金) 05:22:26ID:b3qevcS80
>>403
これは仕様というか、まあバグに近いものだと思いますが、、、
1) Thread Library (libpthread or libthr)は、1MB + 4k(Red Zone)の領域を
mmap()を使用して作成する。
2) カーネルは、grow stack を使用するので、実際には 128k の領域しか作らない。
3) Thread Library は、最後の 4k の領域を、mprotect()を使用して、
読み書き不可に設定する。
4) カーネルは、最後の 4k は実際にマッピングしてないので、何もしない
ということで、デフォルトでは Red Zone は作られないんですね。
なので、Red Zone を作成するためには、デフォルトの1MBという大きさを
128kより小さくするか、kern.sgrowsiz を大きく設定して、最初から大きな
領域をスタックとして割り当てるかどちらかをする必要があります。
ちなみに、これも動きの説明で、kern.sgrowsiz を設定した方が良いという
意味ではないです。
これは仕様というか、まあバグに近いものだと思いますが、、、
1) Thread Library (libpthread or libthr)は、1MB + 4k(Red Zone)の領域を
mmap()を使用して作成する。
2) カーネルは、grow stack を使用するので、実際には 128k の領域しか作らない。
3) Thread Library は、最後の 4k の領域を、mprotect()を使用して、
読み書き不可に設定する。
4) カーネルは、最後の 4k は実際にマッピングしてないので、何もしない
ということで、デフォルトでは Red Zone は作られないんですね。
なので、Red Zone を作成するためには、デフォルトの1MBという大きさを
128kより小さくするか、kern.sgrowsiz を大きく設定して、最初から大きな
領域をスタックとして割り当てるかどちらかをする必要があります。
ちなみに、これも動きの説明で、kern.sgrowsiz を設定した方が良いという
意味ではないです。
407root▲ ★
NGNG cobra2247 ですが、oyster901 = ex14 でコンパイルした
GENERIC カーネルでブートしたところ、make buildworld buildkernel 通りました。
# -j 4 つけると 1 error になり、
# /usr/obj の下にひとつ usr -> var なシンボリックリンクが必要だった。
GENERIC カーネルでブートしたところ、make buildworld buildkernel 通りました。
# -j 4 つけると 1 error になり、
# /usr/obj の下にひとつ usr -> var なシンボリックリンクが必要だった。
408root▲ ★
NGNG live22x3 6.1-RC2 で復活。
これで、フロントはとりあえずの完成形に。
cobra2247 をやるか。
これで、フロントはとりあえずの完成形に。
cobra2247 をやるか。
2006/05/05(金) 16:31:02ID:v0LBpmeQ0
412root▲ ★
NGNG413root▲ ★
NGNG -i 2 -I 60 → -i 10 -I 120 にした。 < bbsd
414root▲ ★
NGNG signal 10 で落ちる症状は変わらない模様ですね。
バージョンアップ前に、
いったん、 ThreadStackSize 262144 を元に戻すか。
他もいったん、設定の棚卸というかんじで。
バージョンアップ前に、
いったん、 ThreadStackSize 262144 を元に戻すか。
他もいったん、設定の棚卸というかんじで。
2006/05/05(金) 22:49:20ID:b7udRDHi0
>>322の
> esp 0xb858aa3c 0xb858aa3c
> ebp 0xb858aa58 0xb858aa58
ってのは、スタックオーバーフローなんですかね？
まあ、スタック領域がこの辺にあってもおかしくは無いのですが
むしろ、バッファオーバーフローで変な領域にspが設定されている気もします。
(ebpの退避されている領域にゴミが書かれると、espにも伝播して壊れるはず)
実行環境(FreeBSD/amd64)での、スタック/ヒープ/コード(リテラル)/静的データ(bssが別ならそれも)の
それぞれのおよその配置と比べてみて
esp/ebpに設定されているのがどの領域なのかは
確認してみたいところですが。
> esp 0xb858aa3c 0xb858aa3c
> ebp 0xb858aa58 0xb858aa58
ってのは、スタックオーバーフローなんですかね？
まあ、スタック領域がこの辺にあってもおかしくは無いのですが
むしろ、バッファオーバーフローで変な領域にspが設定されている気もします。
(ebpの退避されている領域にゴミが書かれると、espにも伝播して壊れるはず)
実行環境(FreeBSD/amd64)での、スタック/ヒープ/コード(リテラル)/静的データ(bssが別ならそれも)の
それぞれのおよその配置と比べてみて
esp/ebpに設定されているのがどの領域なのかは
確認してみたいところですが。
■ このスレッドは過去ログ倉庫に格納されています
