2ch特化型サーバ・ロケーション構築作戦のスレッドです。
・２ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更関連の各種作業や調整事項
・２ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携
等を取り扱います。
現在、複数サーバによる連携により、
サーバ能力のさらなるスケールアップをめざすための「雪だるま作戦」が進行中です。
しかし、問題はあらゆる意味で山積の状態です。
また「２ちゃんねる証券取引所」をはじめとする「株」関連や「Be」の機能強化、
あるいは、次世代の携帯アクセス環境をめざした「べっかんこ作戦」の状況など、
気候も暖かくなり、そろそろ気になりだす季節にさしかかりつつある今日この頃、
あいかわらず２ちゃんねるは、刻一刻と確実に変化し続けています。
2ch特化型サーバ・ロケーション構築作戦 Part21
■ このスレッドは過去ログ倉庫に格納されています
1root▲ ★
NGNG どれだけ同時に起動されていて
どのように使っているのかわからないので、一概には言えないけど、
もと 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に設定されているのがどの領域なのかは
確認してみたいところですが。
2006/05/05(金) 22:55:44ID:b7udRDHi0
それと、
関連スレは全然チェックしてないのですが
Signal10の原因はOSかApacheのコアだというのは間違いないのですかね？
SpeedyCGIとmod_cgidso、及びdso版read.cgiが原因という可能性は？
というのは、もし単純なバッファオーバーフローがapacheのコア部分にあったら
簡単に発見されて修正されそうな気がするので
もしバッファオーバーフローであれば、追加モジュールに原因があるのではと。
関連スレは全然チェックしてないのですが
Signal10の原因はOSかApacheのコアだというのは間違いないのですかね？
SpeedyCGIとmod_cgidso、及びdso版read.cgiが原因という可能性は？
というのは、もし単純なバッファオーバーフローがapacheのコア部分にあったら
簡単に発見されて修正されそうな気がするので
もしバッファオーバーフローであれば、追加モジュールに原因があるのではと。
417root▲ ★
NGNG <IfModule mpm_worker_module>
StartServers 64
ServerLimit 80
MaxClients 640
ThreadLimit 16 <= 8
ThreadsPerChild 16 <= 8
MinSpareThreads 64
MaxSpareThreads 512
MaxRequestsPerChild 1000000
MaxMemFree 16000
</IfModule>
こうしてみた。 < www/menu
StartServers 64
ServerLimit 80
MaxClients 640
ThreadLimit 16 <= 8
ThreadsPerChild 16 <= 8
MinSpareThreads 64
MaxSpareThreads 512
MaxRequestsPerChild 1000000
MaxMemFree 16000
</IfModule>
こうしてみた。 < www/menu
419root▲ ★
NGNG cobra2247 準備が整いました。
あと、www2 の4号機と5号機の登録も。
まずは DNS 登録依頼いきます。
以下の追加登録をお願いします。
+live22-2.2ch.net:206.223.150.52:300
+www2f4.2ch.net:206.223.150.110:300
+www2f5.2ch.net:206.223.150.42:300
あと、www2 の4号機と5号機の登録も。
まずは DNS 登録依頼いきます。
以下の追加登録をお願いします。
+live22-2.2ch.net:206.223.150.52:300
+www2f4.2ch.net:206.223.150.110:300
+www2f5.2ch.net:206.223.150.42:300
420root▲ ★
NGNG で、live22-2 を動かすには、
read.cgi と bbs.cgi を更新する必要があるですね。
もちろん、掲示板システムの入れ込みとか F22 (F15?) の起動とか、
そのへんも必要で。
read.cgi と bbs.cgi を更新する必要があるですね。
もちろん、掲示板システムの入れ込みとか F22 (F15?) の起動とか、
そのへんも必要で。
なんでなんで?
前回その話になったとき、 live22x? を使うんじゃなく
別のvirtualをどんどん追加していくと言っていたような、
前回その話になったとき、 live22x? を使うんじゃなく
別のvirtualをどんどん追加していくと言っていたような、
422root▲ ★
NGNG423root▲ ★
NGNG つまり、
cobra2247 = news20
tiger2523, 2524, 2525, 503, 507 = news20x1 〜 news20x5
cobra2247 = news20
tiger2523, 2524, 2525, 503, 507 = news20x1 〜 news20x5
424root▲ ★
NGNG というわけで >>419 はとりさげて、申請出しなおしますです。
425root▲ ★
NGNG というわけで、
live22x という名前で、複数バックエンドにする
もんだと、勘違いしていました。すんません。
news20(x) のつもりで、設定ごにょごにょしてくるです。
live22x という名前で、複数バックエンドにする
もんだと、勘違いしていました。すんません。
news20(x) のつもりで、設定ごにょごにょしてくるです。
427root▲ ★
NGNG428root▲ ★
NGNG ということで、改めて DNS 登録申請いきます。
以下の追加をお願いします。
+www2f4.2ch.net:206.223.150.110
+www2f5.2ch.net:206.223.150.42
+news20b.2ch.net:206.223.150.52
+news20f1.2ch.net:206.223.150.64
+news20f2.2ch.net:206.223.150.74
+news20f3.2ch.net:206.223.150.84
+news20f4.2ch.net:206.223.150.110
+news20f5.2ch.net:206.223.150.42
+news20.2ch.net:206.223.150.96
以下の追加をお願いします。
+www2f4.2ch.net:206.223.150.110
+www2f5.2ch.net:206.223.150.42
+news20b.2ch.net:206.223.150.52
+news20f1.2ch.net:206.223.150.64
+news20f2.2ch.net:206.223.150.74
+news20f3.2ch.net:206.223.150.84
+news20f4.2ch.net:206.223.150.110
+news20f5.2ch.net:206.223.150.42
+news20.2ch.net:206.223.150.96
429root▲ ★
NGNG >>390
○live22x3 復活 & フロントに再投入(済)
○live22 OS バージョンアップ(済)
・news20 構築 DNS 変更依頼中、DNS 登録完了後作業継続予定
・live22x1 OS バージョンアップ + Apache 更新 これから
○live22x3 復活 & フロントに再投入(済)
○live22 OS バージョンアップ(済)
・news20 構築 DNS 変更依頼中、DNS 登録完了後作業継続予定
・live22x1 OS バージョンアップ + Apache 更新 これから
430root▲ ★
NGNG #!/bin/sh
exec 2>&1
exec env - TZ="JST-9" PATH="/usr/sbin:/usr/bin:/bin:/usr/local/bin" \
LANG="ja_JP.SJIS" \
setuidgid ch2live22 /usr/local/sbin/bbsd -f \
-c -b 192.168.100.1 -d /home/ch2live22/public_html \
-i 10 -I 120 -n 8 -p 2222 -s live22x.2ch.net
bbsd の nice 値 -20 をやめてみた。(きりわけのため)
現在、PREEMPTION なし以外は、概ね通常のサーバ設定。
exec 2>&1
exec env - TZ="JST-9" PATH="/usr/sbin:/usr/bin:/bin:/usr/local/bin" \
LANG="ja_JP.SJIS" \
setuidgid ch2live22 /usr/local/sbin/bbsd -f \
-c -b 192.168.100.1 -d /home/ch2live22/public_html \
-i 10 -I 120 -n 8 -p 2222 -s live22x.2ch.net
bbsd の nice 値 -20 をやめてみた。(きりわけのため)
現在、PREEMPTION なし以外は、概ね通常のサーバ設定。
431root▲ ★
NGNG 寝る前に、news20 関連のアカウント情報をメールしておくです。
432root▲ ★
NGNG433▲ ◆SANUKI/VII
NGNG news20ﾐｴﾀ＼(^o^)／
2006/05/06(土) 14:19:28ID:f1rVV7JE0
(ﾟ∀ﾟ)
2006/05/06(土) 15:29:27ID:6X8cZn1V0
おらわくわくするぞ
2006/05/06(土) 18:23:49ID:mXk+K8xl0
6.1-RELEASE タグ来てますね。
ちょっとだけ遅かった?
ちょっとだけ遅かった?
437む P061198250186.ppp.prin.ne.jp
2006/05/06(土) 18:56:17ID:t3hL77EW0 きましたか。
ということは今週中にはアナウンス出る感じかしら。
ということは今週中にはアナウンス出る感じかしら。
2006/05/06(土) 19:00:14ID:IDtWUQIu0
>>437
むむむさん、memoriesが例によって例の調子です。
むむむさん、memoriesが例によって例の調子です。
440root▲ ★
NGNG news20b は最初から 6.1R でいけるのかな。
memories は OS 更新したいところだけど、
センシティブな構成だから、リモートコンソールがないと微妙かも。
まずは Apache とか更新しておくか。
memories は OS 更新したいところだけど、
センシティブな構成だから、リモートコンソールがないと微妙かも。
まずは Apache とか更新しておくか。
2006/05/06(土) 22:37:56ID:n8Q6mkvt0
そろそろ削除呪文系も対応しないと、バックエンドが
2つ(以上?)になるともっと大変になるかも。
おじさんのいう勝ちに行くっていうのは、やっぱり
WCUPに対してなんですよね。
サーバ群(7台)の機能分担が鍵ですよね。今のところ、
単機能のフロント側の負けはないようなので、mod_cacheを
導入しない場合は、正直フロントは3台で十分のような。
live22x1のbbsdを単独サーバにしたほうがよいのかも。
2つ(以上?)になるともっと大変になるかも。
おじさんのいう勝ちに行くっていうのは、やっぱり
WCUPに対してなんですよね。
サーバ群(7台)の機能分担が鍵ですよね。今のところ、
単機能のフロント側の負けはないようなので、mod_cacheを
導入しない場合は、正直フロントは3台で十分のような。
live22x1のbbsdを単独サーバにしたほうがよいのかも。
442root▲ ★
NGNG >>441
呪文は、例のとりあえずmod_proxyでフォワードするというのを、
ちと試してみるです。
で、news20 がうまく稼動したら、たぶん news19 を空けることできて、
news19 は既に XO ロケーションに、、、とか、いろいろと。
呪文は、例のとりあえずmod_proxyでフォワードするというのを、
ちと試してみるです。
で、news20 がうまく稼動したら、たぶん news19 を空けることできて、
news19 は既に XO ロケーションに、、、とか、いろいろと。
443root▲ ★
NGNG cobra2247 を 6.1R にすべく、make buildworld を流していたら、
突然ハングアップしました。
ううむ、、、。
突然ハングアップしました。
ううむ、、、。
444root▲ ★
NGNG ・ping かからない
・KVM で見ると画面が出たまま凍っている
…とりあえず、リブート要請出します。ううむ。
・KVM で見ると画面が出たまま凍っている
…とりあえず、リブート要請出します。ううむ。
445root▲ ★
NGNG とりあえず、Apache2.0 と PHP4 をそれぞれ最新にしてみた。 < memories
446root▲ ★
NGNG 本日準備できたら、live22x1 のバージョンアップ作業する予定。
規制系 DB 用の bbsd は、一時的に live22 へと(作業済)。
規制系 DB 用の bbsd は、一時的に live22 へと(作業済)。
447root▲ ★
NGNG %uname -a
FreeBSD banana273.maido3.com 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sat May 6 08:05:11 PDT 2006 root@banana273.maido3.com:/usr/obj/var/src/sys/I386_BANANA_61 i386
cvsup.peko.2ch.net、特に問題なく。
FreeBSD banana273.maido3.com 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sat May 6 08:05:11 PDT 2006 root@banana273.maido3.com:/usr/obj/var/src/sys/I386_BANANA_61 i386
cvsup.peko.2ch.net、特に問題なく。
449root▲ ★
NGNG リモートコンソールで操作中。
一世代前のカーネルに戻してみる。
一世代前のカーネルに戻してみる。
450root▲ ★
NGNG 一世代前のカーネルだと、ちゃんと動くようだ。
微妙だ、、、。
微妙だ、、、。
451root▲ ★
NGNG もう1回 make buildworld buildkernel からじっくりやろう。
453root▲ ★
NGNG bbs.cgi 等配布リストに、live22x4/live22x5 を追加した。
454root▲ ★
NGNG もう1回、教科書どおりのほうほうでカーネルとユーザランドを更新しなおしてみた。
普通に 6.1R になったところで、SMP ありのカーネルに差し替え。 < cobra2247
普通に 6.1R になったところで、SMP ありのカーネルに差し替え。 < cobra2247
455root▲ ★
NGNG 無事に上がったので、make -j 4 buildworld (負荷試験のかわり)を実施中。
456root▲ ★
NGNG 死にました、、、。
SMP なカーネルに問題があるのか。
あるいは CPU が片方いまいちなのか。
SMP なカーネルに問題があるのか。
あるいは CPU が片方いまいちなのか。
457root▲ ★
NGNG このカーネル config は、ex14 のと同じなので、
問題があるとはちと考えにくいが、、、。ううむ。
リブート要請と、調査依頼を出しておくです。
問題があるとはちと考えにくいが、、、。ううむ。
リブート要請と、調査依頼を出しておくです。
458root▲ ★
NGNG >>429
○live22x1 OS バージョンアップ + Apache 更新 … 済 6.1R
・news20 システム構築 … DNS 登録 done 後作業継続予定、ただしトラブル解決後
・news20b = cobra2247 トラブル中、調査依頼中 … 土曜日なので週明けからか
・memories = oyster902 httpd が暴走する問題 … とりあえずその場しのぎを入れてみた
・削除の呪文の mod_proxy でのフォワード … 別途すすめる
○live22x1 OS バージョンアップ + Apache 更新 … 済 6.1R
・news20 システム構築 … DNS 登録 done 後作業継続予定、ただしトラブル解決後
・news20b = cobra2247 トラブル中、調査依頼中 … 土曜日なので週明けからか
・memories = oyster902 httpd が暴走する問題 … とりあえずその場しのぎを入れてみた
・削除の呪文の mod_proxy でのフォワード … 別途すすめる
459root▲ ★
NGNG 違うとは思えないけど、
config ...; make cleandepend; make depend; make で作ったカーネルと、
make buildkernel KERNCONF=... で作ったカーネルでやってみた。
しかし、やはりだめだった。
リブート依頼と調査依頼(一時的に作業依頼止めていた)出します。
# 今日は、ここまでで、、、。ううむ。
config ...; make cleandepend; make depend; make で作ったカーネルと、
make buildkernel KERNCONF=... で作ったカーネルでやってみた。
しかし、やはりだめだった。
リブート依頼と調査依頼(一時的に作業依頼止めていた)出します。
# 今日は、ここまでで、、、。ううむ。
2006/05/07(日) 03:49:17ID:cgA4oCWW0
>459
お疲れ様でした〜
原因は指摘してるＣＰＵ１発あぼ〜ん説に一票
ＳＭＰ無しで動くのに有りにするとこけるなんて１発壊れてるとしか思えない
お疲れ様でした〜
原因は指摘してるＣＰＵ１発あぼ〜ん説に一票
ＳＭＰ無しで動くのに有りにするとこけるなんて１発壊れてるとしか思えない
2006/05/07(日) 04:11:52ID:ggeP+nf10
乙です。
live22のOS version up後もsignal 10で
落ちていますか？
live22のOS version up後もsignal 10で
落ちていますか？
465root▲ ★
NGNG フロントエンド5台も、signal 10 は現在まで一つも観測していない模様。
466root▲ ★
NGNG 今見てみましたが、signal 10 がひとつもありませんね。< live22/live22x1
これは、バージョンアップが有効だったということなのかしら。
これは、バージョンアップが有効だったということなのかしら。
467root▲ ★
NGNG 6.1R にして、全体的に明らかに軽くなった気がするんだけど、
何が変わったんだろう。
5.4R → 6.0R の時は、ファイルシステム周りが劇的に軽くなった気がしたんですが、
6.0R → 6.1R では、全体になんとなくっていう感じ。
何が変わったんだろう。
5.4R → 6.0R の時は、ファイルシステム周りが劇的に軽くなった気がしたんですが、
6.0R → 6.1R では、全体になんとなくっていう感じ。
468root▲ ★
2006/05/07(日) 22:48:05ID:???0 ぢぇんぬさんに教えてもらった削除系標準呪文セットを、
mod_proxy で live22 にとばすようにしてみた。
これで、うまくいくといいけど。
mod_proxy で live22 にとばすようにしてみた。
これで、うまくいくといいけど。
469root▲ ★
NGNG そういえばいただきオンラインって、
live22x => live22 という処理入れていたんでしたっけ。
もし入れていたら、解除をお願いしますです。 > いただきさん
live22x => live22 という処理入れていたんでしたっけ。
もし入れていたら、解除をお願いしますです。 > いただきさん
470root▲ ★
NGNG お知らせしてきました。
☆ 連絡＆報告 6 ☆
http://qb5.2ch.net/test/read.cgi/saku/1127100825/940
>>469 をいただきさんに知らせるには、
どうすればよいのかしら。
☆ 連絡＆報告 6 ☆
http://qb5.2ch.net/test/read.cgi/saku/1127100825/940
>>469 をいただきさんに知らせるには、
どうすればよいのかしら。
>>428
done
done
NGNG
>>470
たもんくんのスレで告知してる人がいらっしゃいました。
たもんくんのスレで告知してる人がいらっしゃいました。
474root▲ ★
NGNG >>458
・news20 システム構築 … DNS 登録済、ただしトラブル解決後
・news20b = cobra2247 トラブル中、調査依頼中 … 週明けからの見込み
○memories = oyster902 httpd が暴走する問題 … その場しのぎはとりあえず機能している模様(後述)
○削除の呪文の mod_proxy でのフォワード … 設定済、異常報告があれば対応
・なにやら大きな引越しがあるとかなんとか … 動きが決まってきたらということで
・news20 システム構築 … DNS 登録済、ただしトラブル解決後
・news20b = cobra2247 トラブル中、調査依頼中 … 週明けからの見込み
○memories = oyster902 httpd が暴走する問題 … その場しのぎはとりあえず機能している模様(後述)
○削除の呪文の mod_proxy でのフォワード … 設定済、異常報告があれば対応
・なにやら大きな引越しがあるとかなんとか … 動きが決まってきたらということで
475root▲ ★
NGNG こんなかんじ @ oyster902
May 7 07:05:00 <0.3> oyster902 kernel: pid 11511 (httpd), uid 80, was killed: exceeded maximum CPU limit
May 7 07:30:46 <0.3> oyster902 kernel: pid 11593 (httpd), uid 80, was killed: exceeded maximum CPU limit
May 7 07:33:31 <0.3> oyster902 kernel: pid 11414 (httpd), uid 80, was killed: exceeded maximum CPU limit
May 7 07:46:34 <0.3> oyster902 kernel: pid 11506 (httpd), uid 80, was killed: exceeded maximum CPU limit
May 7 09:03:30 <0.3> oyster902 kernel: pid 11604 (httpd), uid 80, was killed: exceeded maximum CPU limit
May 7 07:05:00 <0.3> oyster902 kernel: pid 11511 (httpd), uid 80, was killed: exceeded maximum CPU limit
May 7 07:30:46 <0.3> oyster902 kernel: pid 11593 (httpd), uid 80, was killed: exceeded maximum CPU limit
May 7 07:33:31 <0.3> oyster902 kernel: pid 11414 (httpd), uid 80, was killed: exceeded maximum CPU limit
May 7 07:46:34 <0.3> oyster902 kernel: pid 11506 (httpd), uid 80, was killed: exceeded maximum CPU limit
May 7 09:03:30 <0.3> oyster902 kernel: pid 11604 (httpd), uid 80, was killed: exceeded maximum CPU limit
■ このスレッドは過去ログ倉庫に格納されています
