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

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

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

等を取り扱います。

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

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

過去ログ一覧:
Part1 http://qb3.2ch.net/operate/kako/1052/10529/1052923573.html
Part2 http://qb3.2ch.net/operate/kako/1062/10621/1062137886.html
Part3 http://qb3.2ch.net/operate/kako/1068/10680/1068017802.html
Part4 http://qb3.2ch.net/operate/kako/1074/10741/1074124767.html
Part5 http://qb3.2ch.net/operate/kako/1076/10761/1076162131.html
Part6 http://qb3.2ch.net/operate/kako/1076/10764/1076413123.html
Part7 http://qb3.2ch.net/operate/kako/1076/10767/1076733846.html
Part8 http://qb3.2ch.net/operate/kako/1078/10789/1078972549.html
Part9 http://qb3.2ch.net/operate/kako/1080/10802/1080298357.html
Part10 http://qb3.2ch.net/operate/kako/1082/10821/1082125059.html
Part11 http://qb3.2ch.net/test/read.cgi/operate/1082990543/　(なぜか未HTML化)
Part12 http://qb5.2ch.net/operate/kako/1084/10844/1084429098.html
Part13 http://qb5.2ch.net/operate/kako/1085/10856/1085678587.html
Part14 http://qb5.2ch.net/operate/kako/1087/10876/1087666806.html
Part15 http://qb5.2ch.net/operate/kako/1093/10930/1093068260.html
Part16 http://qb5.2ch.net/operate/kako/1102/11020/1102087698.html
Part17 http://qb5.2ch.net/operate/kako/1107/11073/1107376477.html
Part18 http://qb5.2ch.net/operate/kako/1115/11151/1115133136.html
Part19 http://qb5.2ch.net/test/read.cgi/operate/1121886018/
Part20 http://qb5.2ch.net/test/read.cgi/operate/1140540754/

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

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

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

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

ｵﾒ

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

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

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

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

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

・maxvnodes の値を見直してみるのはありかも。
http://qb5.2ch.net/test/read.cgi/operate/1140540754/70

・PREEMPTION と DEVICE_POLLING について
http://qb5.2ch.net/test/read.cgi/operate/1140540754/737
http://qb5.2ch.net/test/read.cgi/operate/1140540754/739

・今後の作業メモ
http://qb5.2ch.net/test/read.cgi/operate/1140540754/760
http://qb5.2ch.net/test/read.cgi/operate/1140540754/761

・denyではじく負荷やら対策やらについて
http://qb5.2ch.net/test/read.cgi/operate/1140540754/797
http://qb5.2ch.net/test/read.cgi/operate/1140540754/804
http://qb5.2ch.net/test/read.cgi/operate/1140540754/828

・6.1Rへのバージョンアップ作業について
http://qb5.2ch.net/test/read.cgi/operate/1140540754/919

・これからのいろいろ
http://qb5.2ch.net/test/read.cgi/operate/1140540754/949-952

・NFSしてみるとかなんとか
http://qb5.2ch.net/test/read.cgi/operate/1140540754/954-961

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

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

で、
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
...

となっていた模様。

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

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

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

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

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

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

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

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

SYSCTL_INT ですか。

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

%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とか踏んだ時にまるごとぼーんと死んじゃう瞬間があるのかしら。

topでみると:

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

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

>>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 ってのも妙ではありますが......

/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

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

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

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

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

>>22-23
なるほど。

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

<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

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

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

>>26
ですね。

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

>>22

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

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

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

後ろで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>

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

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

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

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

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

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

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

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

>>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

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

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

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

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

>>35
ああ、すいません。
私が言ったのは、topでスレッドを展開せずに表示した時のことです。
経験上、スレッドを展開しなかったときは、
listnerスレッドの状態が accept とか ucond とかであらわれるようなので。

>>37
なるほど、そういうことですか。
(-H状態ではない場合と)

例えば、
http://qb5.2ch.net/test/read.cgi/operate/1140540754/674
のような状態は、もう、どのプロセスもパンパンだと思うんですよ。
で、なんで、パンパンになっちゃうのかと言うと、
普通に考えれば worker の処理が完了する前にどんどん接続を受け入れちゃうからで、
つまり、workerの処理に時間がかかりすぎていると。
Apacheって、workerの処理時間ログに出せませんでしたっけ?

DEVICE_POLLING ありにした。

%ifconfig -a
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=4b<RXCSUM,TXCSUM,VLAN_MTU,POLLING>
inet6 fe80::230:48ff:fe53:ec66%em0 prefixlen 64 scopeid 0x1
inet 206.223.150.54 netmask 0xffffff00 broadcast 206.223.150.255
ether 00:30:48:53:ec:66
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=4b<RXCSUM,TXCSUM,VLAN_MTU,POLLING>
inet6 fe80::230:48ff:fe53:ec67%em1 prefixlen 64 scopeid 0x2
inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255
ether 00:30:48:53:ec:67
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff000000

心なしか、軽くなったような気も。

>>39
WBCの時ですね。

あぁ、なんかちょっとだけ限界に近づいたなぁ、っていう感じを初めて受けた時でした。
work の処理時間ですか。んー、SunOS さんが詳しそうですね(私はそこまで知らないです)。

man polling
...
SUPPORTED DEVICES
Device polling requires explicit modifications to the device drivers. As
of this writing, the dc(4), em(4), fwe(4), fwip(4), fxp(4), ixgb(4),
nge(4), re(4), rl(4), sf(4), sis(4), ste(4), vge(4), vr(4), and xl(4)
devices are supported, with others in the works.

がーん、cobra2247 (Cobra)の I/F って bge だから、この機能ないのね。
/usr/src/sys/dev/bge で grep POLLING しても、何も出てこないし。

で、この PREEMPTION なし、DEVICE_POLLING ありは、
BG3/BG4 (携帯バックエンド)にもいずれ使えそうだから、
苦しくなったら導入を考えようと。

>>42
6.1では

SUPPORTED DEVICES
Device polling requires explicit modifications to the device drivers. As
of this writing, the bge(4), dc(4), em(4), fwe(4), fwip(4), fxp(4),
ixgb(4), nge(4), re(4), rl(4), sf(4), sis(4), ste(4), vge(4), vr(4), and
xl(4) devices are supported, with others in the works

ですね。

>>44
おーっ ♥

%pushd /usr/src/sys/dev/bge
/usr/src/sys/dev/bge ~
%ls
if_bge.c if_bgereg.h
%grep POLLING *.[ch]
if_bge.c:#ifdef DEVICE_POLLING
if_bge.c:#ifdef DEVICE_POLLING
if_bge.c: ifp->if_capabilities |= IFCAP_POLLING;
if_bge.c:#ifdef DEVICE_POLLING
(以下略)

もう今日は、live22 をおびやかすような負荷は来ないかな。

HDDアクセスとネットワークアクセスが重なると、
特にHDDをヘビーに触ると、苦しくなりやすい

んだとすると、PREEMPTIONなし+DEVICE_POLLINGありの設定は、
理論上は効果を期待できそうな気がします。

で、Apacheのスレッド数の変更をし、
最初から最大値で待たせ、かつプロセス数をちょっと控えめに設定変更しました。

で、cobra サーバでも 6.1R にすれば、DEVICE_POLLING が使えることもわかりました。

まだまだ先は長そうですが、今日のところはこんなかんじで。

systat で見ると、数千回とかあった em0 と em1 の割り込みがなくなって、ちと感動。
(というか、あたりまえか)

DEVICE_POLLING のチューニング点は、

・HZ を変える(今1000 = 6.0Rのデフォルト)
・kern.polling.user_frac の調整
> When polling is enabled, and provided that there is some work to
> do, up to this percent of the CPU cycles is reserved to userland
> tasks, the remaining fraction being available for polling pro-
> cessing. Default is 50.

あたりですか。あとは man polling を読めと。

今日はそろそろ寝る時間で。

お疲れさまでした。

あと、httpdが落ちた時にcoreファイルが作られれば、
もっと原因解明ができると思います。
その場合、libthr, httpd, apache モジュール等、関連する全てのバイナリを
-O オプションなし & -g オプションつきでコンパイルしていれば、
どこで落ちたかはっきりするはず。
パフォーマンスは多少ダウンするし、バイナリも大きくなりますけどね。。

乙でした．

>>39 >>41 これでしょうか？

%D　　The time taken to serve the request, in microseconds.

live22のapacheで、workerの処理時間がかかることって
なんでしょうかね。
.dat/.txtの読み出しぐらいしかしていないと思うから、
ファイルの読み出しに時間がかかっているのですかね。
(bbsdの書き込みでブロックされているとか。)

>>50
HDDとネットワークの割り込みの取り合い(race condition)かなぁと思っていたりします。
昨日の出来事でかなりの確率でそうかなと、思うようになってきました。

今日2:30の設定変更でDEVICE_POLLING(この部分に有効といわれている)を入れたのが、
どう働くかなと。

ex14で、昨日live22で詰めた設定の実験を始めた。

・Apache 2.2 / 64bit + patch + worker MPM
・libthr

・DEVICE_POLLINGなし
・non-雪だるまサーバ

<IfModule mpm_worker_module>
StartServers 4
Serverlimit 4
ThreadLimit 256
ThreadsPerChild 256
MaxClients 1024
MinSpareThreads 1024
MaxSpareThreads 1024
MaxRequestsPerChild 32000000
MaxMemFree 64000
</IfModule>

ex14、妙なシステムダウン。
pingかかるものの、ログインできず。

ブレーメンのログやapache statusのログを見ても、
負荷がかかったような様子はなし。

>>52 が原因か。ううむ。

サーバダウンスレは流れそうなので、こっちに状況を。

www port: 詰まる
telnet port: 正しく connection refused
ftp port: 詰まる
ssh port: 繋がるものの、その先の応答なし

で、>>52 にあたり変えたのは、

・libpthread => libthr (libmap.conf 設定)
・httpd.conf (>>52 の部分のみ)

ううむ。

単なる憶測ですが，メモリか何かの資源を食い潰したとかそんな感じなんでしょうかねぇ......

>>56
http://mumumu.mu/mrtg/mrtg-rrd.cgi/memory/ex14memory.html

最初にそれを疑ったんですが、
あんまり、それっぽくもないんですよね(上記)。

libthr とかかしら。

いずれにせよ上がったら、
1024 thread も要らないっぽいので、 StartServers と ServerLimit を 3 にして、
768 に減らしてみるということで。

# 今日はもうだめぽ。

>>57 なるほど......

カーネル内の何かのロックで引っかかってるかとかですかねぇ......

>>59
そんな気がするですね。
TCP で接続しようとすると、ユーザランドにいかないっぽい(>>54)ので。

リブート入ったので、

<IfModule mpm_worker_module>
StartServers 3
ServerLimit 3
ThreadLimit 256
ThreadsPerChild 256
MaxClients 768
MinSpareThreads 768
MaxSpareThreads 768
MaxRequestsPerChild 32000000
MaxMemFree 64000
</IfModule>

に変更。 < ex14

結構、ネットワークからの割り込み入っていますね。
systat とかで見ると 2500 以上あります。< この時間

6.1R が出たら、DEVICE_POLLING にするということで。< ex14

で、
pid 789 (httpd), uid 2003: exited on signal 10
pid 791 (httpd), uid 2003: exited on signal 10
pid 2529 (httpd), uid 2003: exited on signal 10
pid 3980 (httpd), uid 2003: exited on signal 10

やはり、signal 10 で死ぬことがある模様。
read.cgi かな。

通常サーバを 256 threads/process で動かすと、ちと危険かもですね。
やはり、もうちょっと減らそう。

>>61-62 乙です．>>51 みたいなことが ex14 でも起きたんでしょうかね......？
race condition だとするとタイミングの問題でしょうし．

<IfModule mpm_worker_module>
# StartServers 3
# ServerLimit 3
# ThreadLimit 256
# ThreadsPerChild 256
StartServers 12
ServerLimit 12
ThreadLimit 64
ThreadsPerChild 64
MaxClients 768
MinSpareThreads 768
MaxSpareThreads 768
MaxRequestsPerChild 32000000
MaxMemFree 64000
</IfModule>

こうしてみた。

>>64
ありえますね。

前にも数回、同じような不可解な停止(ただし高負荷時)にあったので、
そうかなと思っていたり。

GFSはないか、ないな

Apr 18 04:48:07 <0.6> tiger2522 kernel: pid 49512 (httpd), uid 2001: exited on signal 10
Apr 18 04:48:08 <0.6> tiger2522 kernel: pid 51181 (httpd), uid 2001: exited on signal 10
Apr 18 04:48:11 <0.6> tiger2522 kernel: pid 47579 (httpd), uid 2001: exited on signal 10
Apr 18 04:48:53 <0.6> tiger2522 kernel: pid 54596 (httpd), uid 2001: exited on signal 10
Apr 18 04:48:54 <0.6> tiger2522 kernel: pid 54600 (httpd), uid 2001: exited on signal 10
Apr 18 04:49:02 <0.6> tiger2522 kernel: pid 47591 (httpd), uid 2001: exited on signal 10
Apr 18 04:49:03 <0.6> tiger2522 kernel: pid 49264 (httpd), uid 2001: exited on signal 10
Apr 18 04:49:23 <0.6> tiger2522 kernel: pid 54777 (httpd), uid 2001: exited on signal 10
Apr 18 04:49:24 <0.6> tiger2522 kernel: pid 46092 (httpd), uid 2001: exited on signal 10
Apr 18 04:49:26 <0.6> tiger2522 kernel: pid 50612 (httpd), uid 2001: exited on signal 10
Apr 18 04:49:29 <0.6> tiger2522 kernel: pid 51482 (httpd), uid 2001: exited on signal 10
Apr 18 04:49:30 <0.6> tiger2522 kernel: pid 54770 (httpd), uid 2001: exited on signal 10
Apr 18 04:50:00 <0.6> tiger2522 kernel: pid 54606 (httpd), uid 2001: exited on signal 10
Apr 18 04:50:12 <0.6> tiger2522 kernel: pid 54903 (httpd), uid 2001: exited on signal 10
Apr 18 04:51:22 <0.6> tiger2522 kernel: pid 54904 (httpd), uid 2001: exited on signal 10
Apr 18 04:51:45 <0.6> tiger2522 kernel: pid 54880 (httpd), uid 2001: exited on signal 10
Apr 18 04:51:55 <0.6> tiger2522 kernel: pid 55080 (httpd), uid 2001: exited on signal 10

ううむ。

とりあえず、

# XXX
kern.maxvnodes=200000

にしてみた。@ live22

今は、ゆとりありだからわからないなぁ。

%sysctl vfs.numvnodes
vfs.numvnodes: 39509
%sysctl kern.maxvnodes
kern.maxvnodes: 200000

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html

このへんは大丈夫(だった)っぽいなぁ。

%netstat -m
544/4016/4560 mbufs in use (current/cache/total)
520/1878/2398/32768 mbuf clusters in use (current/cache/total/max)
14/562/8704 sfbufs in use (current/peak/max)
1176K/4760K/5936K bytes allocated to network (current/cache/total)
0 requests for sfbufs denied
0 requests for sfbufs delayed
355 requests for I/O initiated by sendfile
64 calls to protocol drain routines

CoreDumpDirectory が効いて core を取れればどこでコケてるか絞りやすいんでしょうけどね．
それがナゼ効かないのか......

Apache 2.2.0 にしてから試してなかったので、
今、入れてみた。

# XXX
CoreDumpDirectory /tmp

kern.polling.burst_max
Upper bound for kern.polling.burst. Note that when polling is
enabled, each interface can receive at most (HZ * burst_max)
packets per second unless there are spare CPU cycles available
for polling in the idle loop. This number should be tuned to
match the expected load (which can be quite high with GigE
cards). Default is 150 which is adequate for 100Mbit network and
HZ=1000.

うむむむ。

http://lists.freebsd.org/pipermail/freebsd-net/2004-January/002719.html

http://lists.freebsd.org/pipermail/freebsd-net/2004-January/002721.html

# XXX
kern.polling.burst_max=400
kern.polling.each_burst=15

HZ=2000 にするのは、今日寝る前あたりにトライで。

こんどは、HDDに負荷かけてみる。

fsck -n /home とか find /home -ls とかやってみたけど、
苦しい状況は再現されず。

前に make -j 4 で再現した「ぐにゃぐにゃ」も、再現されない模様。

# 負荷が低いせいかも。

ハードウェア的な問題はないのでしょうか？
具体的にはHDDとかメモリとか。

FreeBSDではなくてLinuxの話ですが、HDDが死にかけの時は、
コマンド入力したらSIGBUSで落ちたりしてました。
今回の件とは違うので、参考にならないかもですが。

>>81
ハードですか、、、。
一応、ないとは思いますけど、、、。 < 症状から

# そういえば某飲み会で、コマンドを入力すると全部バスエラーになるサーバの対応を
# していたような、していないような。(その時の原因はHDDのI/Oエラーだったみたいです)

人為的にやるなら，ab 攻撃 + >>79 みたいなのとか．

>>83
やはりそれですかね。

HZ=2000 なカーネルに入れ替え。@ live22

%sysctl kern.clockrate
kern.clockrate: { hz = 2000, tick = 500, profhz = 1333, stathz = 266 }

read.cgi再開発スレ Part2
http://qb5.2ch.net/test/read.cgi/operate/1105909861/518-521

今見ていますが、_datArea の rsync が、とっても負荷が高いですね。

どうせ不安定なんだから(おい)、ここをread onlyのNFSにしてみるとか。
やってみるか。

@ live22

/etc/rc.conf:
# NFS for _datArea
nfs_server_enable="YES"
nfs_server_flags="-u -t -n 8"
rpcbind_enable="YES"
rpc_statd_enable="YES"
rpc_lockd_enable="YES"

@ live22x1

/etc/rc.conf:
# NFS for _datArea
nfs_client_enable="YES"

/etc/fstab:
# NFS for _datArea
192.168.100.1:/home/ch2live22/_datArea /home/ch2live22x/_datArea nfs ro,bg,mntudp,intr,nosuid 0 0

>>87 の前に、今ある _datArea の rsync 止めて、
ディレクトリを mv した。

@ live22
/etc/exports: 設定。

>>87 を、live22x2 と live22x3 にも適用。

結局、_datArea の rsync をとりあえずやめることにして、
プライベートネットワーク経由での NFS (read only) にしてみた。

フロントで動く read.cgi バイナリや offlaw.cgi バイナリは
NFS 経由で、dat を読みに行くと。

他の部分(SETTING.TXT等)は、NFS使用せず(rsyncで運ぶ)。

ということで、以前のNFS利用と異なるのは、

・生datやSETTING.TXTはNFSしない

かな。

ようは、NFSするのは過去ログ関係だけにしたと。
で、代償に過去ログの rsync が不要になったと。

このぐらいの頻度なら、NFSの発狂やrace conditionもないといいなぁ、と。

ちなみに _datArea という名前は非公開だったり

>>93
あ、、、そうでしたか。
ごめんなさい。


例のPIEへの大引越しの際に、_datArea という名前で
過去ログを公開していたので、公開情報だと思ってしまいました。
すみません。

…管理人にメールしておきます。
(´･ω･｀)

>>95 done.

|´･ω･)ゝ

いくつか有る壁の一つだから
大きなことは起こらないとおもいますー

2002年でしたっけ
三台ほどデータ消されたの

たぶんそれ以降強固になっているはずですんで、
そのうち壁を一つ増築するということで、

>>98

はい。

http://kaba.2ch.net/test/read.cgi/accuse/1025091914/934

http://qb5.2ch.net/operate/kako/1085/10852/1085244404.html
>>10とか>>14とか

|´･ω･)ゝ　緊急時だから記憶しないであげて

>>96
つ　▲

あれって非公開だったんだ、

rsync の負荷がおそろしく軽くなった。

「だんだん弱くなってきた」傾向からいっても、
これまでの観測結果からしても、過去ログの再帰的な rsync をやめたのは、
相当効果が大きいと思う。

あとは、この部分が NFS でうまく動いてくれれば。

株式会社jig.jpの菊池です。
弊社サービス「jigブラウザ」から２ちゃんねる掲示板への書き込みの件ですが、
弊社テストサーバでの対応が完了致しましたので技術情報を公開致します。

IPアドレス：210.153.93.58

携帯側のIPアドレスはX-Forwarded-Forヘッダーで端末固有情報は
X-Subscriber-IDヘッダーで送信するようにしています。

テストサーバでの書き込みの確認ができましたら、全サーバのIPを公開したいと考えております。

宜しくお願い致します。

>>106
了解です。
まずは、テストサーバの仮登録ということですね。

X-Forwarded-For: xxx.xxx.xxx.xxx
X-Subscriber-ID: serial_string

という形であると想定して bbs.cgi に組み入れ、
このサーバ(qb5)に入れます。

こちらの作業ができたところで、このスレで連絡します。
よろしくお願いいたします。

早速の回答ありがとうございます。
ご連絡お待ちしております。

あと、X-Subscriber-ID: 情報を送信いただくにあたっての確認です。

http://br.jig.jp/session_XA2HSjsCa3SdTu3V/pc/model.html

# 対応機種が多いですね。

いい機会なので、個別の方法をまとめておきます。

1) DoCoMo

User-Agent: の serXXXXXXXXXXXXX を、加工せずそのまま送ってください。

2) au

X_UP_SUBNO の情報を、加工せずそのまま送ってください。

3) Vodafone

User-Agent: の SNxxxxxxxxxx を、加工せずそのまま送ってください。

4) Willcom

うーむ、とりあえず保留にさせてください。
仕様がわからないと、対応のしようが。

逆に仕様がわかれば、これを機会に対応できるのかな。

>>109 は、ser や SN を＊つけたままで＊、という意味になります。
よろしくおねがいします。

いい機会だから、菊池さんにひとつ質問してしまいます。

Willcom 版 jig ブラウザは、

1) ２ちゃんねるには御社ゲートウェイ経由でのアクセスになるのですか。
2) それとも、携帯電話につく IP アドレス直でアクセスされるのでしょうか。

[FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:14.fpu
http://lists.freebsd.org/pipermail/freebsd-announce/2006-April/001061.html

お、ひょっとして、

> IPアドレス：210.153.93.58

は、逆引きできない IP アドレスかしら。

だとすると、
> X-Forwarded-Forヘッダー

との兼ね合いで、ちといまいちかもです。
(全然別のProxy判定にひっかかる可能性がある)

DNS逆引きが設定されていれば問題ないので、
テストの際には逆引きを正しく指定いただくか、
あるいは他のヘッダでIPアドレス情報を渡す必要があります。

…というか、こっちで対応すればいいのか。>>113

該当部分、IPアドレス 210.153.93.58 だけ一時的にスルーにします。

>>109
了解致しました。
>>111
ゲートウェイ経由でのアクセスになります。
端末情報を送っていいかWILLCOMの方に確認致しますので、こちらの対応は保留とさせていただきます。

>>115
Willcom の端末情報は、
一般的な方法では素の Willcom 電話からは得られないはずです、、、。

ということで２ちゃんねるには、送っていただかなくて問題ありませんです。
というか、たぶん許可なく送っちゃいけないんだと思います。

# 端末情報とれると＊すんごく＊うれしいけど、たぶん非公開ですね、それ。

# Willcomの対応は、別途考えましょう。

菊池様;

というわけで、qb5 サーバに対応版 bbs.cgi を入れました。

・DoCoMo/au/Vodafone いずれも対応できたはずです。
・Willcom は未対応です(携帯用ブラウザからの情報を取得できない旨のエラーになります)。
・ID の末尾の識別マークは Q になります。
・ID そのものは、携帯の標準ブラウザから書き込んだ場合と同じです。
・規制系(Samba24連投規制、BBM)は、各携帯ごとに個別で規制されます。

ということで、以下のテストを実施していただけますと助かります。

[test] 書き込みテスト 専用スレッド 61 [ﾃｽﾄ]
http://qb5.2ch.net/test/read.cgi/operate/1144376539/

に、
1) jigブラウザ経由で書き込む
2) 携帯の標準ブラウザから書き込む

1) 2) が同じ ID となり、かつIDの末尾が Q と O になれば、実験は成功です。

以上、よろしくお願いいたします。

バーボンも端末個別？

>>118
リロードバーボンは従来通りですね。ゲートウェイ型の宿命かと。
書き込みバーボンは、携帯と同じ扱いになるはず。

(´-｀).｡ｏO（しかし対応キャリアが多いと、テストも大変だなと。）

キャリアごと(計６回)の書き込みテストですね。

>>112
SAですか。
cobraだけ該当すると。

>>117
素早い対応ありがとうございます。
確認致します。

既に設定済みかわかりませんが、、

FreeBSDで、apacheのようにsetuid,setgidしているプロセスにcoredumpさせるためには、
sysctl kern.sugid_coredump=1
とする必要があります。

また、必須ではありませんが、
sysctl kern.corefile=%N.core.%P
として、コアファイル名にプロセスIDを含めるようにすれば、
複数のプロセスがSIGBUSで落ちたとしても、コアファイルが上書きされることはないでしょう。

StartServers 16
ServerLimit 16
ThreadLimit 128
ThreadsPerChild 128

に変更。(8/256から)

なるほど、LA が高く出ているだけなのね。

しばらく、これで。
さっきは umtx がいっぱい出ていたけど、128 にしたら落ち着いたみたい。

>>124
どうもです。設定しました。

>>49
入れてみた。 @ live22

よくわからないながらいつも思うのですが
>>124さんのような名無しさんこそが 動け動けウゴウゴ２ちゃんねる を支えていると思う今日この頃
ほんと深いですよね、rootさん(*´Д`)ﾉ

kern.polling.burst が結構上がることがあるみたい。

kern.polling.burst_max=800 にした。

>>129
…ですね。

みんなで踊るから、面白いと。

>>130
em1 1500 <Link#2> 00:30:48:53:ec:67 138923795 2181 150931418 0 0

Ierrs が出ていました(少なくとも18:00ぐらいまでは出ていなかった)。
オーバーランかなと。

【封印】封印されし神々の復活Ver4【解除】
http://hobby7.2ch.net/test/read.cgi/occult/1143562352/333-334

マジですか。
本当ならrootたんが家庭の保守に専念できる。

/tmp に core ができていました。

%gdb /usr/local/sbin/httpd httpd.core.46382
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)...
Core was generated by `httpd'.
Program terminated with signal 10, Bus error.
Reading symbols from /lib/libm.so.4...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.4
...
Reading symbols from /usr/local/libexec/apache22/mod_cgidso.so...(no debugging symbols found)...done.
Loaded symbols for /usr/local/libexec/apache22/mod_cgidso.so
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x2828a593 in accept () from /lib/libc.so.6
[New Thread 0x8263600 (LWP 101485)]
[New Thread 0x8263500 (LWP 101482)]
[New Thread 0x8263400 (LWP 101479)]
...
(続く)

(gdb) where
#0 0x2828a593 in accept () from /lib/libc.so.6
Cannot access memory at address 0xb787dea0
(gdb)

うーむ。

>>135
変ですね。スタックが破壊されない限り、そうはならないはずなんですが。。
通常は

(gdb) where
#0 0x282b0c67 in accept () from /lib/libc.so.6
#1 0x2823ad65 in accept () from /usr/lib/libthr.so.2
#2 0x282152b2 in apr_socket_accept () from /usr/local/lib/libapr-1.so.2
#3 0x08082f76 in unixd_accept ()
#4 0x0807fe41 in listener_thread ()
#5 0x28219ee8 in dummy_worker () from /usr/local/lib/libapr-1.so.2
#6 0x2823d5c7 in pthread_create () from /usr/lib/libthr.so.2
#7 0x00000000 in ?? ()

のような感じになるはず。

>>136
> 変ですね。スタックが破壊されない限り、そうはならないはずなんですが。。

そうなんですよね。
とりあえず、観察を続けようかと。

株式会社jig.jpの菊池です。

お待たせしておりまして申し訳ございません。
書き込みテストが完了致しました。
問題ないようです。
DNSの逆引き設定がされておりませんでしたので、現在対応中です。
設定終了後、全IPを公開致します。

下記テスト結果になります。

http://qb5.2ch.net/test/read.cgi/operate/1144376539/826-845

【DoCoMo】
826（jigブラウザ）
827(ネイティブ）
828（jigブラウザ）
829（jigブラウザ）
830（ネイティブ）
832（ネイティブ）
835（jigブラウザ）
833（ネイティブ）
827（ネイティブ）

【au】
829(jigブラウザ）
830(ネイティブ）

【ボーダフォン】
844(jigブラウザ）
845(ネイティブ）

宜しくお願い致します。

>>138
書き込みテストの内容を確認しました。
DoCoMo/au/Vodafone、全て問題ないようですね。

IPアドレスの情報をいただいた後 bbs.cgi への組み込みを行い、
全サーバに反映します。

なお、今後御社側でサーバの追加・変更等があった場合、
お手数ですがその都度お知らせいただけますと助かります。

それでは、よろしくお願いいたします。

>>137
ちなみに、gdbで info threads した時に

...
2 Thread 0x82b6c00 (LWP 100348) 0x28322363 in kill () from /lib/libc.so.6
* 1 Thread 0x82b6d00 (LWP 100349) 0x282d7c67 in accept () from /lib/libc.so.6
..

のように in kill の状態になっているスレッドはないでしょうか?
あったら、そのスレッドのスタックトレースを見てみると良いかも。。

>>140
10 Thread 0x8242d00 (LWP 101459) 0x28289973 in poll () from /lib/libc.so.6
9 Thread 0x8242e00 (LWP 101461) 0x282884d3 in _umtx_op ()
from /lib/libc.so.6
8 Thread 0x8242f00 (LWP 101464) 0x2828a4b3 in kill () from /lib/libc.so.6
7 Thread 0x8263000 (LWP 101467) 0x282884d3 in _umtx_op ()
from /lib/libc.so.6
6 Thread 0x8263100 (LWP 101470) 0x282884d3 in _umtx_op ()
from /lib/libc.so.6

これか。

で、このスレッドのスタックトレースを見るには、どうすれば。

(gdb) thread 8
(gdb) where

です。

自分でも調べて、やってみたです。>>142
が、いまいちみたい。

(gdb) thread 8
[Switching to thread 8 (Thread 0x8242f00 (LWP 101464))]#0 0x2828a4b3 in kill
() from /lib/libc.so.6
(gdb) where
#0 0x2828a4b3 in kill () from /lib/libc.so.6
Cannot access memory at address 0xb7f84a3c
(gdb)

>>143
そんな感じですか。。
本来なら

(gdb) where
#0 0x28322363 in kill () from /lib/libc.so.6
#1 0x0807958b in sig_coredump ()
..

というように、sig_coredump()からkill()が呼ばれるはずなんですけどね。


とりあえず、thread 8 で落ちてますので、
listenerスレッドではなく、workerスレッドで落ちていることはわかりました。
あとは、、
やっぱり CFLAGS=-g でコンパイルしないと、わかり難いんじゃないかなぁと個人的には思います。

netstat -i でカウントが増えています。
とりこぼしかな。

ログインしていても、そう感じる。

mbuf は余裕ありか、、、。

%netstat -m
1845/2535/4380 mbufs in use (current/cache/total)
665/2231/2896/32768 mbuf clusters in use (current/cache/total/max)
292/356/8704 sfbufs in use (current/peak/max)
1791K/5095K/6887K bytes allocated to network (current/cache/total)
0 requests for sfbufs denied
0 requests for sfbufs delayed
197 requests for I/O initiated by sendfile
41 calls to protocol drain routines

で、LAが急上昇。
CPU idle time はまだ相当ある。

load averages: 40.84, 53.78, 34.102

少し設定変えたけど、もう下がっちゃったのかな。

>>139
ご確認ありがとうございます。

>>138の書き込みの内容に一部間違いがございましたことをお詫び致します。
誠に申し訳ございませんでした。

下記に訂正させていただきます。

【DoCoMo】
826（jigブラウザ）
827(ネイティブ）
828（jigブラウザ）
832（ネイティブ）
833（jigブラウザ）
835（jigブラウザ）

【au】
829(jigブラウザ）
830(ネイティブ）

【ボーダフォン】
844(jigブラウザ）
845(ネイティブ）

サーバの追加・変更等があった場合の報告の件了解致しました。
弊社バージョンアップの準備ができ次第IPの公開をさせていただきます。

宜しくお願い致します。

sysctl kern.polling.user_frac=20

とかしてみた。

kern.polling.user_frac
When polling is enabled, and provided that there is some work to
do, up to this percent of the CPU cycles is reserved to userland
tasks, the remaining fraction being available for polling pro-
cessing. Default is 50.

>>148
了解です。わざわざ訂正ありがとうございました。

これ (banana238 に昔入れたもの、今でも入っている)を入れていなかったのを
思い出して、入れてみた。 @ live22

# increase network send/receive buffer
net.inet.tcp.sendspace=131072
net.inet.tcp.recvspace=131072
net.inet.udp.maxdgram=131072
net.inet.udp.recvspace=131072

さらに、
net.local.stream.sendspace=131072
net.local.stream.recvspace=131072

を追加。

net.inet.tcp.delayed_ack=0

は、live22 バックエンドではしない方がよさげですね。

http://www.jp.freebsd.org/QandA/HTML/1926.html

net.local.dgram.maxdgram=131072
net.local.dgram.recvspace=131072

を追加。

で、これらは、

%netstat -s -p udp
udp:
1826031 datagrams received
0 with incomplete header
0 with bad data length field
0 with bad checksum
15 with no checksum
36 dropped due to no socket
0 broadcast/multicast datagrams dropped due to no socket
1055 dropped due to full socket buffers
0 not for hashed pcb
1824940 delivered
1824924 datagrams output

> 1055 dropped due to full socket buffers

これを見つけて、やることにした。
(フロント <=> bbsd は udp で通信)

【実況】　live22x　Part17
http://qb5.2ch.net/test/read.cgi/operate/1145104439/936-938

帰宅途中に「banana403/404はパブリック側でmatしているから、
全部Gigabit通信になるはずで、それならプライベート側にはjumbo frame入れられるはず」
と気がつき、live22/live22x[123] に導入してみた。

ifconfig em1 mtu 9000 を設定し、/etc/rc.conf に記述を追加。

%ifconfig -a
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=4b<RXCSUM,TXCSUM,VLAN_MTU,POLLING>
inet6 fe80::230:48ff:fe53:ec66%em0 prefixlen 64 scopeid 0x1
inet 206.223.150.54 netmask 0xffffff00 broadcast 206.223.150.255
ether 00:30:48:53:ec:66
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 9000
options=4b<RXCSUM,TXCSUM,VLAN_MTU,POLLING>
inet6 fe80::230:48ff:fe53:ec67%em1 prefixlen 64 scopeid 0x2
inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255
ether 00:30:48:53:ec:67
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff000000

live22x[45] の em1 にも入れた。
cobra2247 は、、、なぜか、ping かからない模様。

よく見てみたところ、

arplookup 206.223.151.3 failed: host is not on local network
arplookup 206.223.151.4 failed: host is not on local network
arplookup 206.223.151.2 failed: host is not on local network
...

こりゃ、携帯用のVLANですね。

…なるほど、雪だるまのVLANのプライベート側は、
携帯用VLANのパブリック側と同居なのか。

だとすると(携帯用サーバにはbanana = 100Mbps)がいるから、
ジャンボフレームの設定は現時点では無理ですね。(´･ω･｀)ｼｮﾎﾞｰﾝ

中の人にVLANをきちんと分けてもらえば、可能なのかしら。

TCPなら、ジャンボ設定してもネゴ時にMSS調整して、小さいほうに合わせてくれますけど。

あ、HUBの問題か。

>>159
えぇ、TCPは大丈夫でした。

UDP (NFSとかbbsdとか)が、のきなみだめぽ。

今、 live22 はほとんど遊んでいて、idile timeもちゃんと90%ぐらい。
で、load averages: 1.38, 1.18, 1.16 な状態。

DEVICE_POLLING ありにすると、LAが1つ高めに出るのかしら。

比較対象として、ifconfig em[01] -polling にしてみた。
午前中これで動かしてみる。

systat -v で割り込みで動いているのを確認。

%uptime
7:31PM up 2 days, 10:57, 1 user, load averages: 0.71, 0.64, 0.68

なるほど。

いつでも「あり」「なし」を変えられる状態だから、
負荷がかかった時に、また試してみるか。

再度「あり」に戻しておこう。

> SunOS さん

ちと、別件でメールさせていただきましたです。

また、パケットのとりこぼし系かしら。

で、チューニングが不十分なせいかもしれないけど、
DEVICE_POLLINGありのほうが、限界が早い気がするなぁ。

重い状態を人工的に作り出せるようにしないと。

ちょっと負荷をかけてみたけど(数回)、
このぐらいだとびくともしないなぁ。

いくつかのサーバから同時にしかけないと、だめなのかな。

>>165 メール受け取りました．内容が内容だけに，お返事はしばしお待ちを......

>>166-168 異常のきっかけがパケットの取りこぼしって感じなんですかね．
人為的に実験するとなれば，やはり複数鯖から一斉に，の方が再現しやすいのかもですね．

thttpd

イオナズンのボットのみなさんに協力していただくとか

>>169
第一段落: 了解しました。

第二段落: そうですね。
同じファイルばかりものすごい勢いでアクセスしてもだめぽなのは、
既に以前に実験済みだったり。

>>170
thttpd って、cgi とかさっくり動くんでしたっけ。
というか、ポートとかIPアドレスを変えてフロントとの通信用の thttpd を動かす、とかいう
手はあるのかも。そっちは基本的に、cgi 動かさないわけだし。

で、実験的に device polling をオフにしてみた。
HZ=2000 のままで、ネットワーク系のバッファのパラメータをでかくした状態かなと。

>>158
L2SWの方にジャンボフレームを通す設定が入っているのですかね。
紫箱はデフォルトは通さないような。

>>135
live22ってFD_SIZEをかえているから、カーネル/ライブラリ/アプリの
間でサイズの不整合がおきているとか、スタックサイズオーバに
なっているとかですかね。

>>173
> 紫箱はデフォルトは通さないような。

なるほど、ありえますね。

> live22ってFD_SIZEをかえているから、カーネル/ライブラリ/アプリの
> 間でサイズの不整合がおきているとか、スタックサイズオーバに
> なっているとかですかね。

ex11 (6.1-RC, worker MPM + libthr) でも起きています。
というか、２ちゃんねるのサーバ全体でみても、かなり昔から、
それこそ mod_cgidso とか入れる前から、散見していたき駕します。 < signal 10

【 MACKEREL HAS BEEN DOWN 】リブート部隊連絡所 -- Count 02
http://qb5.2ch.net/test/read.cgi/operate/1122567937/100

cobra2247 のカーネルパニックメッセージ:

spin lock smp rendezvous held by 0xffffff00f3600be0 for > 5 seconds
cpuid = 1

>>166
パケットのとりこぼしというか、Outputの段階でdropされてるかも。
netstat -sp ip
で
output packets dropped due to no bufs, etc
が結構出てるとか…。

>>176
live22:
%netstat -sp ip
ip:
569814333 total packets received
0 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with ip length > max ip packet size
0 with header length < data size
0 with data length < header length
0 with bad options
0 with incorrect version number
44404 fragments received
4 fragments dropped (dup or out of space)
17 fragments dropped after timeout
22094 packets reassembled ok
569779481 packets for this host
12392 packets for unknown/unsupported protocol
0 packets forwarded (0 packets fast forwarded)
0 packets not forwardable
0 packets received for unknown multicast group
0 redirects sent
614399657 packets sent from this host
0 packets sent with fabricated ip header
600 output packets dropped due to no bufs, etc.
0 output packets discarded due to no route
623622 output datagrams fragmented
3611880 fragments created
0 datagrams that can't be fragmented
0 tunneling packets that can't find gif
0 datagrams with bad address in header

live22x1:
%netstat -sp ip
ip:
1369507060 total packets received
0 bad header checksums
7 with size smaller than minimum
1 with data size < data length
0 with ip length > max ip packet size
0 with header length < data size
0 with data length < header length
0 with bad options
0 with incorrect version number
1585871 fragments received
11 fragments dropped (dup or out of space)
39 fragments dropped after timeout
273775 packets reassembled ok
1368170580 packets for this host
24340 packets for unknown/unsupported protocol
0 packets forwarded (0 packets fast forwarded)
0 packets not forwardable
0 packets received for unknown multicast group
0 redirects sent
1254082254 packets sent from this host
0 packets sent with fabricated ip header
960 output packets dropped due to no bufs, etc.
164 output packets discarded due to no route
26692 output datagrams fragmented
53608 fragments created
0 datagrams that can't be fragmented
0 tunneling packets that can't find gif
0 datagrams with bad address in header

live22x2:
%netstat -sp ip
ip:
1941558663 total packets received
0 bad header checksums
4 with size smaller than minimum
1 with data size < data length
0 with ip length > max ip packet size
0 with header length < data size
0 with data length < header length
0 with bad options
0 with incorrect version number
1600442 fragments received
4 fragments dropped (dup or out of space)
28 fragments dropped after timeout
276242 packets reassembled ok
1940200297 packets for this host
34122 packets for unknown/unsupported protocol
0 packets forwarded (0 packets fast forwarded)
0 packets not forwardable
0 packets received for unknown multicast group
0 redirects sent
1773064829 packets sent from this host
0 packets sent with fabricated ip header
724 output packets dropped due to no bufs, etc.
16 output packets discarded due to no route
38083 output datagrams fragmented
76529 fragments created
0 datagrams that can't be fragmented
0 tunneling packets that can't find gif
0 datagrams with bad address in header

live22x3:
%netstat -sp ip
ip:
1942658831 total packets received
0 bad header checksums
0 with size smaller than minimum
2 with data size < data length
0 with ip length > max ip packet size
0 with header length < data size
0 with data length < header length
0 with bad options
0 with incorrect version number
1577166 fragments received
0 fragments dropped (dup or out of space)
36 fragments dropped after timeout
271920 packets reassembled ok
1941319657 packets for this host
33893 packets for unknown/unsupported protocol
0 packets forwarded (0 packets fast forwarded)
0 packets not forwardable
0 packets received for unknown multicast group
0 redirects sent
1776610741 packets sent from this host
0 packets sent with fabricated ip header
656 output packets dropped due to no bufs, etc.
76 output packets discarded due to no route
38092 output datagrams fragmented
76529 fragments created
0 datagrams that can't be fragmented
0 tunneling packets that can't find gif
0 datagrams with bad address in header

>>177-180
UDPで再送してないとdropされた時点でOUTだけど、
ん〜、でも意外?にdropされてないですね。。

>>181
> ん〜、でも意外?にdropされてないですね。。

そうなんですよね。ううむ。

お世話になっております。
株式会社jig.jpの菊池です。
バージョンアップの準備が完了致しましたので全IPの公開を致します。
バージョンアップは明日を予定しております。

下記URLよりご確認いただけます。
http://br.jig.jp/pc/ip_br.html

宜しくお願い致します。

jigブラウザBREW版に関しましては、KDDIの審査において認可がおりなかった為、
サービス開始時期は未定となっております。なお、今後も申請を続ける予定でございます。

どう考えても政治的理由によるものでは・・・・・w

フルブラがあるのにjig使われたら定額上限アップ出来ないからね。

>>183
情報をありがとうございます。

現時点で、64IPアドレスですか。
これだけあると、use Net::CIDR::Lite; する感じですね。

まずはこれで作業すすめます。
が、もし可能であれば、携帯電話のゲートウェイサーバと同様の形で、
つまり CIDR 表記で指定できる形で公開いただけますと、
大変ありがたいです。

ということで、ご検討をよろしくお願いいたします。

qb5 サーバに >>183 の IP アドレスを組み込んだ
本番用の bbs.cgi を入れました。実験いただけると助かります。

あと >>183 のリンク先に、「2006年4月24日現在」といった形で、
最終更新の日付を入れていただけますと、より作業がしやすくなります。
ご検討いただけますと助かります。

qb5 での動作確認ができ次第、
本 bbs.cgi を全サーバに配布させていただきます。
以上、よろしくお願いいたします。

ふと思ったのですが、
高負荷時にバッファがいっぱいになる前に
bbsd を優先的にスケジュールするように、
bbsd を nice or renice しちゃうというのはどうでしょうか。

>>189
matd と同じ手法ですか。いいかもですね。

#!/bin/sh
exec 2>&1
exec env - TZ="JST-9" PATH="/usr/sbin:/usr/bin:/bin:/usr/local/bin" \
LANG="ja_JP.SJIS" \
/usr/bin/nice -n -20 setuidgid ch2live22 /usr/local/sbin/bbsd -f \
-c -b 192.168.100.1 -d /home/ch2live22/public_html \
-i 2 -I 60 -n 8 -p 2222 -s live22x.2ch.net

こうしてみた。 < live22

>>187
対応ありがとうございます。
実験が終了致しましたらご連絡致します。

>>186
>>188
こちら対応致しました。
http://br.jig.jp/pc/ip_br.html

CIDR表記も追加致しましたが、数は結構多くなっております。
宜しくお願い致します。

>>192
> jigブラウザIP一覧　「2006年4月24日現在」

CIDR表記での表現、助かります。
早速設定させていただきますので、テストはその後にお願いします。
(テストOKになった時点でこちらで連絡いたします)

# 「」 は要らないです(w。

>>193
> 早速設定させていただきますので、テストはその後にお願いします。
> (テストOKになった時点でこちらで連絡いたします)

qb5 サーバの準備完了しました。
それでは、よろしくお願いします。

過去ログ部分は、NFSで問題なく動いている模様。

シビアにアクセスしなければいいっていう感じなのかな。
あるいは6.0Rでは5.4Rにあった虫がとれているとかか。

>>195 まぁ，猛烈にアクセスしても平気なのかは，じっけ(ry

ただ，ファイル更新とバッティングした際の問題は
過去ログではほとんど発生しない，ってのも大きいのかも知れませんね．

>>196 第一段落
過去ログでは、「祭り」はないですからね(あってたまるか（ｗ)。

で、ご指摘のとおり、
基本的にはdatができていくだけなので、
そういう部分では、確かに虫を踏む可能性は少なそうですね。
(というかそう思ったので、NFSにしてみたという側面があります)

>>rootさん

jigブラウザでの書き込みの対応が目前な様ですが、書き込み可能になった場合の
公式p2経由での書き込みに関してはどのような扱いになりますでしょうか？

確か、現在の公式p2ではBBQとBBMの規制データを基に規制をしていたと思うのですが

>>194
書き込みテストが完了致しました。
問題ございません。

■テスト結果
http://qb5.2ch.net/test/read.cgi/operate/1145833088/27-70

【DoCoMo】
27ネイティブ
28jigブラウザ

【ボーダフォン】
30jigブラウザ
32ネイティブ

【au】
69jigブラウザ
70ネイティブ

bbs.cgi全サーバに配布お願い致します。

宜しくお願い致します。

>>199
配布完了しました。10分ほどで有効になります。

>>198
昨日、質雑スレでもこのやりとりあったですね。

通常書き込みについては個別規制できるようになったので、
「BBQ解除して公式p2についてはどんどん芋掘りしてどんどん規制」でも
いいのかな、とは思いますが、芋掘りしなきゃならないというところで、
ちょっとちゅうちょしていたり。

# 私は今のところ「芋掘りはしない」と決めているです。
# 管理人に昔「募集中ですよ」って誘われましたが、唯一、明確にお断りしました。
# どこかに一つぐらい歯止めを持っておかないと、きりがなくなっちゃうし。

そして伝説へ

P2の規制チェックをBBQからBBXにすることはできませんか？
ここではスレ違いかな…

ibisやjig側がp2を作ってアプリで直カキコした時と同じように端末情報などを2ch側に送信するのは？

>>202
Proxy + p2 で、荒らしツールとして使われまくった過去があるですね。
ようは「規制回避ツール」「荒らしツール」として使うのは、おことわりってことで。

で、たぶんスレ違いな肝。

# 上にも質雑スレにも書いたように、ibis と jig については迷っているので、
# 気まぐれに解除を依頼するかも。

>>203
そういう形での解決は、ありえますね。

p2(相当)のしくみを各アプリのベンダーさんが持って
技術情報を開示 => ２ちゃんねるでうまく対応

みたいな解決パターンは、じゅうぶん考えられると思います。

前スレでもちょっと議論しましたが、一般論だと、

・荒らしツール、規制回避ツールとして使うのはおことわりです
・携帯の場合、個別規制ができる形がいいなぁ(= 端末固有情報を２ちゃんねる側で得られる)
・２ちゃんねるから見て、コスト的に大きくないのがいいなぁ(= 大きな負荷や手間がかからない)

ってかんじなのかなと。

Hello, Sean-san, Jim-san,
Cc: related folks,

This is Mumumu. Genki-desuka?

Now several XO 2ch servers, cobra2247, tiger503, and tiger507 are
'almost idling'. So, we need to verify the current electric power
status before these servers working well.

I want to know the current status of power circuit configuration.

I think that if cobra2247 works well, it will use the electric power
almost the same as oyster901. Is the current electric power
configuration of XO enough for it?

And if tiger503 and tiger507 work well, they will use the electric
power almost the same as tiger2523 and tiger2524.

If the power is not enough for them, we can move out some servers of XO,
they are tiger504, tiger509, tiger510 and cobra2245.

We want to advance the power up of the server of 2ch by "The Snowman"
clustering technology. The "Snowman" system is now working on tiger2522,
tiger2523, tiger2524 and tiger2525.

I think it is an ultimate server system for 2ch. I will describe to you
details of it.

Thank you for your cooperation.
Regards,

菊池様;

202.181.98.242
202.181.98.243
202.181.98.244
202.181.98.245
202.181.98.246
202.181.98.247
202.181.98.248
202.181.98.249
202.181.98.250

これらの御社のサーバは、DNSの逆引きがエラーになっているようです。

>>207 続き、
こちらで確認してみたところ、

%dig -t ptr 242.98.181.202.in-addr.arpa. @ns1.dns.ne.jp.

; <<>> DiG 9.3.2 <<>> -t ptr 242.98.181.202.in-addr.arpa. @ns1.dns.ne.jp.
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61718
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;242.98.181.202.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
242.98.181.202.in-addr.arpa. 3600 IN NS dns1.jig.jp.98.181.202.in-addr.arpa.
242.98.181.202.in-addr.arpa. 3600 IN NS dns2.jig.jp.98.181.202.in-addr.arpa.

;; Query time: 110 msec
;; SERVER: 210.188.224.9#53(210.188.224.9)
;; WHEN: Tue Apr 25 00:31:48 2006
;; MSG SIZE rcvd: 90

となっており、DNSサーバの指定が適切ではない状態にみえます。

# たぶん上位ISP(ns1.dns.ne.jp)において、NS 指定の末尾に "." を付け忘れていると思われ。
# 以上、老婆心ながら。

>>205
ご指摘ありがとうございます。
DNSの逆引きエラーに関しましては弊社方でも認識しておりまして
現在対応しております。

宜しくお願い致します。

>>181>>195
気になったのは、ネットワークのどこかでドロップされている、ということはありませんか？

例えば、1000Mbpsで繋がっているポートと100Mbpsで繋がっているポートがあると、
帯域が狭くなるところでスイッチのバッファに一時貯められるわけですけど、
バッファ容量以上のパケットが押し寄せてくると、パケットは捨てられてしまうわけです。
TCPなら再送されますが、UDPだと取りこぼしてしまいます。

・切り分け
サーバのアクセスが集中しているときに、NFSやbbsdをTCPにしてみる。

>>210
>サーバのアクセスが集中しているときに、NFSやbbsdをTCPにしてみる。

ん......問題の切り分けという点では興味深いですが，bbsd は UDP に依存した
造りになってるんで，TCP で扱えるようにするのはちょっと大変かも......

あと，アクセス集中でおかしくなる時はバックエンドへの HTTP アクセス，
つまり TCP でもどん詰まりになってるんで，パケットのドロップ自体より，
ドロップをきっかけに別の異常が発生しているという感じなのかな，とも......

＞あと，アクセス集中でおかしくなる時はバックエンドへの HTTP アクセス，
＞つまり TCP でもどん詰まりになってるんで，パケットのドロップ自体より，
＞ドロップをきっかけに別の異常が発生しているという感じなのかな，とも......
詳しくどうもです。
もうちょっと詳しい観察と切り分けが必要ってことなんですね。

>>206 の件、Jim さんから「調べさせる」という返事あり。
結果も来てました。別途、報告入れます。

Jim-san, Ryan-san, Tom-san,

Thank you for your help.
I have more questions.

1) I want to know which circuit following servers are connected to
precisely.

tiger503
tiger507
cobra2247

I think MS VM 1 and MS VM 2 in MS-XO-9 are almost full. If these
servers are connected to their circuit, we have to change the circuit
configuration. So, please tell us the information.

2) What time do you measured the amp usage? The amp usage of 2ch
servers are vary. 22:00-24:00 JST (it is equal to 6:00;8:00 PDT)
is the maximum time. We need to check the actual usage at that time.

Regards,

> MS-XO-2
> MS VM 1 Load: 8 of 20 amps [39%]
> MS VM 2 Load: 3 of 15 amps [17%]
> MS-XO-9
> MS VM 1 Load: 11 of 15 amps [73%]
> MS VM 2 Load: 17 of 20 amps [87%]
> MS VM 3 Load: 6 of 20 amps [31%]
> MS VM 4 Load: 5 of 15 amps [32%]

do you measuredって何だよ、、、。ううむ。

>>215
ibis+公式p2書き込みの件で返事来ました

いつもお世話になっております。アイビスサポート係です。

p2の管理者様が
「ibisBrowserから2chに書き込むために出力しているUserAgent」
への有効化を行っていただければ、
ibisBrowser側のアップデートで実現可能と思います。
実装については前向きに検討してまいります。

今後ともよろしくお願い申し上げます。

↑をあきさんに伝えれば宜しいのでしょうか？

>>216
ですね。
既にこちらにも貼られているようです。

p2.2ch.net不具合報告スレ Part10
http://qb5.2ch.net/test/read.cgi/operate/1141521195/

>>217
向こうに詳しい人が来てくれたみたいですね
色々ありがとうございましたm(__)m

あ、そうだ。一応念のため。

ibis さん、jig さんとも、相手方のドメイン名を見て、固有情報を送っているのかしら。
だとすると、2ch.net に加えて、bbspink.com に対しても同じ動作をする必要があると思います。

>>219
確認してみました。

ibis、jigともにbbspink.comの場合は固有情報を送っていないようで、
「携帯用ブラウザからの情報を正しく取得できませんでした。(2)」が表示されました。

p2.2ch.net のほうでは、対応が終わったとのことです。

p2.2ch.net不具合報告スレ Part10
http://qb5.2ch.net/test/read.cgi/operate/1141521195/675

ということで、p2.2ch.net 経由での書き込みについても、
通常の bbs.cgi 経由での書き込みと同じ形で
固有情報を送っていただくように設定された時点で、
同様に書き込みができるようになるはずです。 > ibis/jig とも

# この場合のIDの末尾は、通常のp2での書き込み同様に P となります。

>>220
了解。やはりそうですか。
これは、それぞれの中の方々の対応待ちですね。

お手数ですが、もし公式 p2 のアカウントをお持ちであれば、
>>221 についても、＊以下のスレでの解除作業が終了後に＊
お試しいただけますと助かります。

【BBQ＆BBM14本目】公開串登録所【ピンポイント規制】
http://qb5.2ch.net/test/read.cgi/sec2chd/1145893627/

>>222
p2で試してみました。

ibis、jigともに
「p2 error: 携帯の固有端末IDを送信しないと書き込みできません。。(携帯の設定で、固有端末IDを送信するようにしてください)」
が表示されました。

・・・あれっ？

どうやらjigも通常の書き込み時"のみ"固有情報を送信しているようですね。

・・・ということはjig側の対応も必要ということですね。

西村様、菊池様;

p2.2ch.net不具合報告スレ Part10
http://qb5.2ch.net/test/read.cgi/operate/1141521195/686

ということで、jig, ibis とも、現時点では p2.2ch.net 経由では
固有情報を送信しないように設定されている模様です。

p2.2ch.net は２ちゃんねる公式のサービスですので、
こちらでの書き込みの際にも、同様の形式で送るように
設定をいただけますと大変助かります。

なお、>>221 にあるように、p2.2ch.net での設定は完了している旨、
連絡をもらっています。

>>219 の件とあわせ、お手数ですがよろしくお願いいたします。

>>223-224
そのようですね。
ということで、>>225 と。

jig さんについては、続報が。
ちと、向こうのスレの動きを観察します。

p2.2ch.net不具合報告スレ Part10
http://qb5.2ch.net/test/read.cgi/operate/1141521195/687

p2.2ch.net不具合報告スレ Part10
http://qb5.2ch.net/test/read.cgi/operate/1141521195/700-702

jig については、p2.2ch.net 側の対応により
書き込みが可能になったようです。

ということで残作業は、

jig: >>219
ibis: >>219 >>216

になります。お手数ですがよろしくです。

# 今日はそろそろ、寝る時間で。

>>228
お疲れさまでした
ibisにはメールしたので後は対応してもらえる事を願いつつ待ちます
本当にありがとうごさいましたm(__)m

一応こちらにも報告します。

>>222
解除作業が終了しました。

いつのまにかeAccelerator-0.9.5-beta2になってます

>>219に関してibisから返事来ましたー


いつもお世話になっております。アイビスサポート係です。

情報提供まことにありがとうございます。ご連絡いただいたページも参考にさせていただきます。

今後とも宜しくお願い申し上げます。


との事です
もー1通はp2スレに貼ります
ありがとうございましたm(__)m

>>219
書き込み先のドメインを確認して端末情報を送信しているのですが
2ch.net,bbspink.com以外に端末情報を送信する必要のあるドメインは
ございますでしょうか？

>>233
そういえば、u.la もですね。
よろしくお願いします。

現在のところは、この3つ以外には必要ないはずです。
状況が変化したらその都度ここでお知らせします。

>>219
bbspink.com に対してのテスト書き込みを行いました。

>>225
p2への書き込みの件、承知しました。
(現在、モリタポの申請中です)

>>234
u.la から bbspink に書き込む際の action属性の中に utn が含まれているため、
404が返されております。(firefoxで確認済)
できれば修正していただけると助かります。

>>235
第一段落、第二段落
よろしくおねがいします。

第三段落
状況確認しました。修正してもらう方向で。

u.la の対応がなされたようです。

雪だるま作戦のスレを待ち続けるスレ　Part6
http://aa5.2ch.net/test/read.cgi/nanmin/1144142021/946

確認をお願いいたします。

u.la から bbspink.comの書き込みを確認しました。

http://same.u.la/test/r.so/sakura02.bbspink.com/pinkqa/1142871332/481

478: bbspink.com からibisBrowserで直接書き込み
479: c.2ch.net からibisBrowserで書き込み
480: (PCから書き込み)
481: u.la からibisBrowserで書き込み

以上の通り、書き込みできましたことを報告いたします。

>>238
了解しました。

公式 p2 以外は対応できたということですね。
向こうの様子をみていると、公式 p2 ももうすぐ対応できそうな感じで。

>>239
ありがとうございました。
公式p2への書き込みも無事終了しました。
今後ともよろしくお願い申し上げます。

皆さんに質問ですウイルスの作り方知ってる人カキコおねがいします
(＊´д｀)ハァハァ

>>241
まずメモ帳を開く
↓

そしてお湯を沸かす
↓

VIPでやれ

怒られる
↓

讃岐あぼん

出来上がりです！

蒸らしが足りないので失敗でした。。

rootさん・西村さん、お疲れ様でしたm(_ _)m

さっき、live22 が重くなった時。

症状は先日と同じで、CPU idle time が 0 になり、
umtx という状態の httpd が多数発生して、httpd 自体が signal 10 でダウンするもの。

httpd の数を少なくしておくと、操作できなくなるほどの重さにはならない。

core 吐いているので、gdb の出力をこれから調査。

(gdb) where
#0 0x282884d3 in _umtx_op () from /lib/libc.so.6
Cannot access memory at address 0xb787de80

で、top で見ると、
"stopped" なスレッドが山ほどいた。

明らかに、挙動不審だ。

もう1回堀江被告が出るようなので、

/etc/libmap.conf を /etc/libmap.conf.SAVE に mv して、
Apache と bbsd をリスタートし、
libthr => libpthread に戻してみた。

#XXX#MaxKeepAliveRequests 100
↓
MaxKeepAliveRequests 0

これはあんまり効果ないかなぁ。
やはり、mod_cache とかか。

桃の毛が明晩に迫ってて，バック増設も間に合いそうにない，となると
やはり mod_cache か......

桃の毛は5/12だからそこまで急がなくても。

>>255 なるほど......金曜日とかどっかで見たような気がして，てっきり明日かと......

Apache2.2.0で起こるフロントの暴走って結局どうなりました？
mod_proxyで子プロセスがCPUを100%つかうバグが2.2.0にあるみたいですけど

http://svn.apache.org/viewcvs.cgi?rev=390724&view=rev

>>257
今フロントは Apache 2.0.55 + libpthread です。
特に暴走問題はその後起こってない模様。

2.2.0じゃないの？


GET /ootoko/subject.txt HTTP/1.1
If-Modified-Since: Thu, 27 Apr 2006 14:27:26 GMT
Host: live22x.2ch.net
Accept: text/html, */*
Accept-Encoding: gzip
User-Agent: Monazilla/1.00 (JaneStyle/2.23)

HTTP/1.1 304 Not Modified
Date: Thu, 27 Apr 2006 15:22:36 GMT
Server: Apache/2.2.0
ETag: "126a1-3d-63244f80"
Vary: Accept-Encoding

>>259
mod_proxy 経由でバックエンドにいくと、そうなります。
バックエンドは Apache 2.2.0

HEAD / HTTP/1.1
Host: live22x.2ch.net

HTTP/1.1 200 OK
Date: Thu, 27 Apr 2006 15:38:03 GMT
Server: Apache/2.0.55
Last-Modified: Thu, 18 Aug 2005 12:46:12 GMT
ETag: "da84b-8c-9917ed00"
Accept-Ranges: bytes
Content-Length: 140
Vary: Accept-Encoding
Content-Type: text/html

あら、そんな仕様だったのか。失礼しました。

明日以降、mod_cache を入れるべく、
squid と mod_cache あり Apache との間で実際にどんなやりとりがなされているか
調べてみるということで。

Apacheが落ちちゃう問題について。

自宅の6.0-RELEASEマシンで再現したので、いろいろ調べてるんですが、
メモリが破壊されることがある模様。

例:
(gdb) frame 2
#2 0x08095001 in ap_http_header_filter (f=0x819edd8, b=0x819f708) at http_filters.c:1024
1024 send_all_header_fields(&h, r);
(gdb) p r
$31 = (request_rec *) 0x819e050
(gdb) p *r
$32 = {pool = 0x2c746153, connection = 0x20393220, server = 0x20727041, next = 0x36303032,
<長いので省略>
(gdb)

0x2c746153 -> ,taS -> Sat,
0x20393220 -> 92 -> 29
0x20727041 -> rpA -> Apr
つまり Sat, 29 Apr

…というように、本来ポインタ値が入るところに文字列が入ってます。
今のところ、OSの問題なのか、Apacheの問題なのかは不明です。

>>262 この壁を乗り越えると，また一歩前進と......

【BBQ＆BBM14本目】公開串登録所【ピンポイント規制】
http://qb5.2ch.net/test/read.cgi/sec2chd/1145893627/96-97
携帯からなのでbrew.ne.jpと思われる範囲をばっさりしました。
（>>205の考えと宣伝荒らし発生のため）

ご報告まで。

>>263 う〜む......そうなっちゃうとすると SIGBUS 発生も頷けますが，しかしなぜそうなるのか......

メモリが糞で化けてる可能性は無視ですか？そうですか。

きっとアドレスが足りないんだよ、ァ。

再現できるので、多分OSでゴミが貯まっているかも。

二日にいっぺん再起動かけるようにしたらいいかも。
10:55〜11:00までは朝支度をしています。何卒ご了承下さい。

memtestかけて何も問題無かったらapacheの問題かな？

signal 10 で落ちるのは 2ch 全土でかなり昔から観測されているので、
Apache か OS の問題と思いますね。

preform MPM な banana / tiger / cobra でも観測されているです。

>>270 補足

ただ、worker MPM で負荷が高くなった時にまとまって落ちるという
現在の症状のものとは、
原因が異なっているような気もしていたりします。

>>263
こういうのは、普通はAPL側での、メモリの誤解放、
メモリを解放したけどなんらかの検索用のlistからの
削除が漏れていた、listからの削除がメモリ解放より
後になっていてプリエンプションで他のプロセスに
メモリを横取りされた、といったことが多いですね。

でも、ApacheとFreeBSDどっちが信頼がおけるのだろう...

どっちも枯れたとは言い難い最新版だしなぁ

この際他のディストリに乗り換えてみるとか。
debian
fedora
centos
gentoo
ubuntu

あと個人的には理研のKNOPPIXがたしかworkノードを分散処理出来るらしいので気になる。

>>274はなんで2chがFreeBSD採用しているのかわかっているのだろうか
お守りをする人が一番得意としているからだろw

>>263 の問題についてパッチを作ったので、後ほどUPします(現在テスト中)。
パッチを当てる前は結構落ちてましたが、
パッチを当てた後は、今のところ一度も落ちていません。
live22 で落ちる原因がこれと同じかはわかりませんが。。。

なお、これは Apache 2.2.0 worker で落ちる問題の対応で、
prefork で落ちるのは別の原因だと思われます。

長いので、分けてUPします。

--- server/mpm/worker/fdqueue.c.origFri Nov 11 00:20:05 2005
+++ server/mpm/worker/fdqueue.cSun Apr 30 10:37:38 2006
@@ -14,6 +14,10 @@
* limitations under the License.
*/

+#ifdef __FreeBSD__
+#include <sys/types.h>
+#include <machine/atomic.h>
+#endif
#include "fdqueue.h"
#include "apr_atomic.h"

@@ -43,8 +47,14 @@
if (first_pool == NULL) {
break;
}
+#ifdef __FreeBSD__
+ if (atomic_cmpset_ptr((volatile uintptr_t *)&(qi->recycled_pools),
+ (uintptr_t)first_pool,
+ (uintptr_t)first_pool->next)) {
+#else
if (apr_atomic_casptr((volatile void**)&(qi->recycled_pools), first_pool->next,
first_pool) == first_pool) {
+#endif
apr_pool_destroy(first_pool->pool);
}
}
@@ -96,9 +106,15 @@
new_recycle->pool = pool_to_recycle;
for (;;) {
new_recycle->next = queue_info->recycled_pools;
+#ifdef __FreeBSD__
+ if (atomic_cmpset_ptr((volatile uintptr_t *)&(queue_info->recycled_pools),
+ (uintptr_t)new_recycle->next,
+ (uintptr_t)new_recycle)) {
+#else
if (apr_atomic_casptr((volatile void**)&(queue_info->recycled_pools),
new_recycle, new_recycle->next) ==
new_recycle->next) {
+#endif
break;
}
}

@@ -163,7 +179,7 @@
* now nonzero, it's safe for this function to
* return immediately.
*/
- if (queue_info->idlers == 0) {
+ while (queue_info->idlers == 0) {
rv = apr_thread_cond_wait(queue_info->wait_for_idler,
queue_info->idlers_mutex);
if (rv != APR_SUCCESS) {
@@ -190,8 +206,14 @@
if (first_pool == NULL) {
break;
}
+#ifdef __FreeBSD__
+ if (atomic_cmpset_ptr((volatile uintptr_t*)&(queue_info->recycled_pools),
+ (uintptr_t)first_pool,
+ (uintptr_t)first_pool->next)) {
+#else
if (apr_atomic_casptr((volatile void**)&(queue_info->recycled_pools), first_pool->next,
first_pool) == first_pool) {
+#endif
*recycled_pool = first_pool->pool;
break;
}

完了。

変更点は、apr_atomic_casptr() -> atomic_cmpset_ptr() です。
なお、fdqueue.c は以前のパッチがあるので、
このパッチはその変更も取り込んでいます。

>>276-279
ありがとうございます。

ひとつ質問です。
#ifdef __FreeBSD__ となっていますが、
これは FreeBSD に固有の虫さんなんでしょうか。

>>280
#ifdef __FreeBSD__ になっているのは、
対応に、FreeBSD固有の関数(atomic_cmpset_ptr())を使用しているからです。

で、一応、私のところではこれで直ってるんですが、
apr_atomic_casptr()を使用した場合、どこが問題なのかは、まだわかってないです。
わかる人がいたら、教えて頂けると嬉しいです。。

apr_atomic_casptr()に問題があるなら、どのOSでも発生するはずですが、
タイミングに依るので、OSによっては問題が起こらない or 起こり難い
はあると思います。


それにしても、、
Apache の ap_queue_info_set_idle() & ap_queue_info_wait_for_idler()
の条件変数とmutexは、もう少し素直なコーディングにしても良いんじゃないかと思う。
できるだけパフォーマンスをUPさせるためにこうなってるのかな。。。

パッチ適用作業中、、、。 < live22

ftp://ftp.peko.2ch.net/pub/patch/apache22/apache-2.2.0-fdqueue.c.patch

作業完了。< @live22

で、libthr 復活してみるか。 < @ live22

/etc/libmap.conf を元に戻して(有効にして)、
httpd と bbsd を再起動した。 < live22

やはりp2から書き込んでいないのに末尾Pになると悲しくなるのは修正効きませんか？

---

KDDI-HI31 UP.Browser/6.2.0.5.c.1.100 (GUI) MMP/2.0

>>288
それは「公式p2から書き込んでいないのに末尾Pになる」ということですか。

ID末尾に機種判定が出ない板で、たまたま末尾がPになっただけだったりして

PowerDNS recursor 3.0.1
http://downloads.powerdns.com/documentation/html/changelog.html
http://blog.netherlabs.nl/articles/category/powerdns

高パフォーマンスか。
試してみる価値はあるかも。

live22系での使用とかを考えると、レイテンシが高いといいかな。

mutex が怪しい？

void *apr_atomic_casptr(volatile void **mem, void *with, const void *cmp)
{
    void *prev;
#if APR_HAS_THREADS
    apr_thread_mutex_t *lock = hash_mutex[ATOMIC_HASH(mem)];

    CHECK(apr_thread_mutex_lock(lock));
    prev = *(void **)mem;
    if (prev == cmp) {
        *mem = with;
    }
    CHECK(apr_thread_mutex_unlock(lock));
#else
    prev = *(void **)mem;
    if (prev == cmp) {
        *mem = with;
    }
#endif /* APR_HAS_THREADS */
    return prev;
}

ex11, ex14 にも適用しておこう。< 上記Apache2.2のパッチ

>>292
ううむこれって、特に高負荷時に apr_thread_mutex_{,un}lock() が怪しい動きをする、
という話なのかしら。

>>293 done.

全OS対応の汎用パッチも作ってみました。
このパッチでも、Apacheが落ちずに使えてます。

>>292 >>294
下記パッチで修正されることから考えるに、apr_atomic_casptr()自身よりも
その使い方に問題があると思われます。
apr_atomic_casptr()が成功した場合、new_recycleがキューにpushされたということであり、
一旦キューに入ったからには、apr_atomic_casptr()からreturnしてきた段階で、
既にpopされて別のところで使われているかもしれません。
そういう意味で、new_recycle->nextを比較演算子の右辺として使うのは
よろしくないんじゃないかと思います。

なお、このパッチは汎用なので、
FreeBSDの場合は >>277-278 のパッチを使用した方がちょっとだけ速いです。

--- server/mpm/worker/fdqueue.c.origMon May 1 05:56:14 2006
+++ server/mpm/worker/fdqueue.cMon May 1 06:08:02 2006
@@ -95,10 +95,10 @@
sizeof(*new_recycle));
new_recycle->pool = pool_to_recycle;
for (;;) {
- new_recycle->next = queue_info->recycled_pools;
+ struct recycled_pool *prev;
+ prev = new_recycle->next = queue_info->recycled_pools;
if (apr_atomic_casptr((volatile void**)&(queue_info->recycled_pools),
- new_recycle, new_recycle->next) ==
- new_recycle->next) {
+ new_recycle, prev) == prev) {
break;
}
}
@@ -163,7 +163,7 @@
* now nonzero, it's safe for this function to
* return immediately.
*/
- if (queue_info->idlers == 0) {
+ while (queue_info->idlers == 0) {
rv = apr_thread_cond_wait(queue_info->wait_for_idler,
queue_info->idlers_mutex);
if (rv != APR_SUCCESS) {

>>296
おつです。
ftp://ftp.peko.2ch.net/pub/patch/apache22/apache-2.2.0-fdqueue.c.patch

を更新しました。
FreeBSDのやつは、こちらにリネームしました。

ftp://ftp.peko.2ch.net/pub/patch/apache22/apache-2.2.0-fdqueue.c-freebsd.patch

で、今 live22 を見ると、また core dump していました。
通常状態でのものなので原因違うかもですが、一応。

(gdb) info threads
130 Thread 0x809c000 (LWP 100274) 0x2828a833 in read () from /lib/libc.so.6
129 Thread 0x809c500 (LWP 100368) 0x282884d3 in _umtx_op ()
from /lib/libc.so.6
128 Thread 0x809c600 (LWP 100369) 0x282884d3 in _umtx_op ()
from /lib/libc.so.6
127 Thread 0x809c700 (LWP 100371) 0x282884d3 in _umtx_op ()
from /lib/libc.so.6
126 Thread 0x809c800 (LWP 100374) 0x282884d3 in _umtx_op ()
from /lib/libc.so.6
...
67 Thread 0x81de400 (LWP 101244) 0x282884d3 in _umtx_op ()
from /lib/libc.so.6
66 Thread 0x81de500 (LWP 101248) 0x28289973 in poll () from /lib/libc.so.6
65 Thread 0x81de600 (LWP 101252) 0x28289973 in poll () from /lib/libc.so.6
...
23 Thread 0x8241000 (LWP 101964) 0x282884d3 in _umtx_op ()
from /lib/libc.so.6
22 Thread 0x8241100 (LWP 101965) 0x2828a4b3 in kill () from /lib/libc.so.6
21 Thread 0x8241200 (LWP 101966) 0x282884d3 in _umtx_op ()
from /lib/libc.so.6
...

2 Thread 0x8262500 (LWP 102200) 0x28289973 in poll () from /lib/libc.so.6
1 Thread 0x8262600 (LWP 102201) 0x2828a593 in accept () from /lib/libc.so.6
(gdb) thread 22
[Switching to thread 22 (Thread 0x8241100 (LWP 101965))]#0 0x2828a4b3 in kill
() from /lib/libc.so.6
(gdb) where
#0 0x2828a4b3 in kill () from /lib/libc.so.6
Cannot access memory at address 0xb8d92a3c
(gdb)

ううむ。

signal 10問題、簡単なまとめ

1) 通常状態で散発的に発生(全サーバ)

httpd子プロセスの一つが散発的にsignal 10で落ちる
負荷にあんまり関係ないっぽい

2) 高負荷状態で集中的に発生(live22)

httpd子プロセスがたくさんsignal 10で落ちる
高負荷時に発生している模様

ということで上のほうのパッチで 2) が直るといいかなと。

>>300
1)はたぶん虫さんでしょうね・・・・

libcの虫さんでなければいいのですけど。

6.1-RC2

%uname -a
FreeBSD banana273.maido3.com 6.1-RC2 FreeBSD 6.1-RC2 #3: Sun Apr 30 22:25:34 PDT 2006 [email protected]:/var/src/sys/i386/compile/I386_BANANA_61 i386

RCといえば、やっと取れたみたい（苦笑）@ProFTPD 1.3.0

thttpdはcgiをBasicサポトしてます。
というのを知ったがどうにも私ゃ知らん。
明日からCプログラミングを習います、はい。

>>304
thttpd をバックエンドで試してみる、という選択肢はあるかもですね。

If-Modified-Since やら差分転送やらが、きちんと動くのかがポイントかしら。

Apache 2.0.58と2.2.2がリリースされました。
http://www.apache.org/dist/httpd/Announcement2.0.html
http://www.apache.org/dist/httpd/Announcement2.2.html

2.2.2のほうはmod_proxyにいっぱい修正が入ってます。

>>306
%cat /usr/ports/www/apache22/distinfo
MD5 (apache22/httpd-2.2.2.tar.bz2) = 9c759a9744436de6a6aa2ddbc49d6e81
SHA256 (apache22/httpd-2.2.2.tar.bz2) = 51f8e00ca27ba4d4259daeff30ce6efcdcf086d277ffb7130e215b492a6f77cc
SIZE (apache22/httpd-2.2.2.tar.bz2) = 4851887
MD5 (apache22/apr_dbd_mysql.c) = 59d26a91cb7f1492fea9ab3e6cd054fc
SHA256 (apache22/apr_dbd_mysql.c) = db204a0e9a89620bf890985383b637d201b418002a0976a2476c0c58783cc3a3
SIZE (apache22/apr_dbd_mysql.c) = 18999

対応早。< ports

ぼちぼち、入れてみるか。

./srclib/apr/dso/unix/dso.c と
./server/mpm/worker/fdqueue.c へのパッチは、
そのまま必要がありそうですね(変わっていない)。

食事の後ででも、ごにょごにょと。

live22 を Apache 2.2.2 + >>308 のパッチに更新した。

電源ですが、各方面からの情報により以下のことがわかりました。

1) 現在、以下のサーバが同じ主幹(MasterSwitch)からとられている。

live22, live22x1, live22x2, live22x3, live22x4, live22x5, cobra2247(= live22-2 候補),
news19, hobby7

2) この主幹の電源は現在、ほぼおなかいっぱいの状態である。

3) live22x4, live22x5, cobra2247 は現在遊んでいる。
フル稼働させるには、電源系統のリアレンジが必要と考えられる。

4) XOロケーションには、余裕のある主幹が別にある。

で、最初は、news19 と hobby7 の XO 外への移設を考えていました。

しかし、今後これらのサーバもかなり近い近未来に雪だるまの一員になることが
じゅうぶんありうるのかなと、思いました。

ということで現在サービスインしていない 3) のサーバ3台を、
4) の主幹に移動するのが、いちばんよい気がしてきました。

問題なければ、この路線で Jim さんと Ryan さん(現地電源関係担当)に、
相談してみようかなと。

これは、ひどいと思う。http://pc8.2ch.net/test/read.cgi/hosting/1123324035/560

pid 92982 (httpd), uid 2001: exited on signal 10
pid 92988 (httpd), uid 2001: exited on signal 10
pid 92987 (httpd), uid 2001: exited on signal 10
pid 92992 (httpd), uid 2001: exited on signal 10
pid 92984 (httpd), uid 2001: exited on signal 10
pid 94520 (httpd), uid 2001: exited on signal 10
pid 23880 (httpd), uid 2001: exited on signal 10
pid 92983 (httpd), uid 2001: exited on signal 10
pid 92986 (httpd), uid 2001: exited on signal 10
pid 92989 (httpd), uid 2001: exited on signal 10
pid 92990 (httpd), uid 2001: exited on signal 10
pid 23822 (httpd), uid 2001: exited on signal 10
pid 23763 (httpd), uid 2001: exited on signal 10
pid 92994 (httpd), uid 2001: exited on signal 10
pid 12481 (httpd), uid 2001: exited on signal 10
pid 92995 (httpd), uid 2001: exited on signal 10
pid 24104 (httpd), uid 2001: exited on signal 10
pid 92980 (httpd), uid 2001: exited on signal 10

いつもの現象か。
Apache 2.2.2 + patch でも、発生すると。

>>312
ここのスレでの話題ではないので、
sec2chd 方面でたんたんと報告していただければと。

>>313
corefileも、やっぱり同じ感じで役に立たないですか?

>>315
状況は全く同じですね。
まだ core 一つしか調べてないですが。

今の方針は明確に「勝ちに行く」なので、
修正が入っているはずの、最新の OS にバージョンアップをする予定。
ゴールデンウィーク明けまでに 6.1R が出ない場合、
6.1-RC2 でいこうと。

>>316
なるほど。
ちなみに、gdb で in kill 状態のスレッドで
info frame
info registers
したら、どんな感じなんでしょう?

了解しました

乗り遅れ…
>>310
電源について,主幹と有りますが,そう呼んでしまうとトランス2次側からの電源が別系統で と
受け取ってしまいます。
要は「分電盤のブレーカーに空きがある」ということで良いのかしら？

という前提で 3)ですが,フル稼働時で万が一落ちた時に切り離し及び復帰が
問題なく行えるのか心配だったり。
逆に,x1〜x5がひとつのバックエンドとして利用でき,切り離し・復帰が問題なく行えるであろうと言うのであれば,
─live22
┌live22x1
├live22x2
└live22x3
┌live22x4
└live22x5
という具合に3系統に分けられると,フロントが落ちた時以外は冗長化が容易では無いかと。

>>319
> 電源について,主幹と有りますが,そう呼んでしまうとトランス2次側からの電源が別系統で と
> 受け取ってしまいます。

すみませんです。
私の電気屋的知識は、所詮門前のなんたら。

> 要は「分電盤のブレーカーに空きがある」ということで良いのかしら？

です。

> という具合に3系統に分けられると,フロントが落ちた時以外は冗長化が容易では無いかと。

なるほどです。
ただまだ全貌を掌握しているわけではないので、
まずは一歩ずつ進めていこうかなと。

>>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 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

とりあえず、二つ分。

>>320
> ただまだ全貌を掌握しているわけではないので、
> まずは一歩ずつ進めていこうかなと。
あいあい。いまはそれで。

>>321-323
情報どうもです。
ちょっとだけ光が見えてきたような気がします。

こうなるとVMのマップ状態が知りたくなってくるんですが、
/usr/ports/sysutils/procmap を使用して、現在稼働中のhttpdのマップ状態を
見ることは可能でしょうか?
なお、procmapはprocfsを必要としますので、現在mountしてないのでしたら、
一時的にでもmountする必要があります。

あと、kern.dflssiz, kern.maxssiz, kern.sgrowsiz等は設定されてますでしょうか?
また、Apacheの設定でThreadStackSizeは設定されてますでしょうか?

あと、>>321-322 のcoreについて、以下の方法でトレース可能か試してみてください。

>>321について、ebpが0xbc0c5a58なので、そこからebpの流れを追ってみる。
(gdb) p/x *0xbc0c5a58
$1 = 0xXXXXXXXX
(gdb) p/x *0xXXXXXXXX <- 上記で表示されたアドレスを入力
$2 = 0xYYYYYYYY
(gdb) p/x *0xYYYYYYYY <- 上記で表示されたアドレスを入力
...
これを10回程度繰り返す。

次に、>>326の結果を利用して、関数呼び出しの流れが取得可能か試す。

(gdb) p/a *(0xbc0c5a58 + 4)
$11 = ...
(gdb) p/a *(0xXXXXXXXX + 4)
$12 = ...
(gdb) p/a *(0xYYYYYYYY + 4)
...

うまくいけば、関数名が表示されると思います。

tiger503, tiger507 and cobra2247 の3台は本日電源系統移動作業の予定。
さきほど私のほうで halt -p を実行し、作業可能を伝えました。

>>325
ありがとうございます。
本日中にやってみるです。 < procmap

> あと、kern.dflssiz, kern.maxssiz, kern.sgrowsiz等は設定されてますでしょうか?
> また、Apacheの設定でThreadStackSizeは設定されてますでしょうか?

このへんはデフォルトのままです。
というか、スタックオーバーフローの疑いですか。

>>325-327
これも別途やってみるです。

外からですが、
見ていると、プロセスあたりのスレッド数が32の時のほうが、パフォーマンスは出るような感じですね。

でもそれだと、虫を踏んだ時にLAがめちゃくちゃ上がって、瀕死状態になってしまうと。

まずは。

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

ex14は大きな破綻なしか。
cobra、強いなぁ。

live22x3、また変なリブート入った。
おかしいな。

live22x3 は、ログインして状況確認中。

メールチェックしてきます。
作業終わっているといいな。

live22x3、いけませんね。

受付嬢の設定変えて、フロントエンドからはずします。

live22x3 は、ハードウェアトラブルっぽいですね。
いろいろ手配します。

matd の設定いじって、とりあえずフロントエンドからはずしました。

live22x4, live22x5, cobra2247(= live22-2 予定)
電源移設作業完了したとの連絡が入りました。

ということで、雪だるま作戦本格再開です。
OSバージョンアップ、設定仕込み等、たんたんとすすめるということで。

tiger2525(= live22x3)、remote KVM でチェックしました。
HDD コントローラからエラー出まくり。
HDD or HDD コントローラがあぼーんした模様。

tiger503/507/cobra2247 の作業ありがとうメールに、
tiger2525 の緊急対応を依頼しました。

# ちなみに、tiger2525 はフロントの1台なので、
# 仮に HDD 完全あぼーんでも、交換して OS 入れれば問題なし。

tiger2525 (= live22x3) は、HDD あぼーんとのこと。
HDD 交換・OS 再インストールで中の人と調整中。

もののけ姫までに、

・live22x3 復活 & フロントに再投入
・live22x4, live22x5, live22-2 投入 with FreeBSD 6.1-RC2 or 6.1R
・live22, live22x[12] OS バージョンアップ + Apache 更新

をめざすことにしよう。

>>325-327 は、ちと予想外の障害対応のため、明日にでも。
(core は保存しました)

今日は、そろそろこのへんで。

過去ログ(NFS経由)を、すいているlive22のパブリック側で
アクセスするようにしてみた。

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 [email protected]:/var/src/sys/i386/compile/I386_TIGER_61 i386

・Apache 2.2.2 + patch + worker MPM + libthr

・カーネルパッチ(FD_SETSIZE) とりあえず導入せず

・PREEMPTION とりあえず有効

以降の予定

cobra2247 稼動
フロントエンドを切り替えつつ、バージョンアップ
バックエンドバージョンアップ(この際にはサービス停止)

cobra2247、バージョンアップの準備していたら
いきなりハングアップした。

KVM 画面もフリーズしている模様。ううむ。

見たところ、カーネルパニックしている模様。
ううむ。

ちょっと、しらべてみます。

savecore: reboot after panic: spin lock held too long

ううむ、これって。

いったん single CPU の kernel に替えてみるか。
なんだかだけど。

>>347
まだソースがガシガシ更新されているから虫がいるんですかね？

>>348
まだ 6.0R のままなんですよ。< cobra2247
make buildworld の間に panic したという。

ほぼ同じハードウェア構成で 6.0R な ex14 はちゃんと動いているので、
ハードウェア障害の予感も。

カーネル作っている間にまた固まった、、、。 < cobra2247

メモリかな？

しばらく待ってだめなら、リブート要請を再度出すということで。
(さっき一度出したのですが、その後ちゃんとパニックしてくれたので
いったんキャンセルした)

>>351
ありえますが、、、。どうなんだろう。

だめなようですね。

リブート要請します。< cobra2247

>>325
> あと、kern.dflssiz, kern.maxssiz, kern.sgrowsiz等は設定されてますでしょうか?
> また、Apacheの設定でThreadStackSizeは設定されてますでしょうか?

http://httpd.apache.org/docs/2.2/ja/mod/mpm_common.html#threadstacksize

スタックオーバー風呂ということなら、
大きくする、という手はあるのかも。

>>355
ありゃ、変な変換。

ま、いっか。もちょっとしたらお風呂の時間で。

<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倍にしてみたつもり。

%uname -a
FreeBSD tiger2524.maido3.com 6.1-RC2 FreeBSD 6.1-RC2 #0: Thu May 4 10:04:11 PDT 2006 [email protected]:/home/src/sys/i386/compile/I386_TINYTIGER_61 i386

@ live22x2

>>357
FreeBSD 6.x のデフォルトのスレッドスタックサイズは1MBです。

>>355 >>357
リンク先を読んでみると、

スレッドスタックサイズのデフォルト値が比較的小さく設定されている プラットホーム
(例えば HP-UX) では、自動変数用の領域で大きな容量を 使用するサードパーティ製
モジュールのために Apache がクラッシュする 場合もあります。そのモジュールは他の
プラットホームでは スタックサイズが大きいために、快調に動作するかもしれません。
このタイプのクラッシュは、ThreadStackSize で OS のデフォルト値より大きな値を指定
することで解決します。 サードパーティ製モジュールでこの処置が必要であると記載
されている 場合か、Apache の出力するメッセージでスレッドスタックサイズが
小さすぎると指摘されている場合にのみ、この調整をしてください。

デフォルトスレッドスタックサイズが、Web サーバ用途に必要な量よりも 明らかに
大きすぎる場合、ThreadStackSize を OS のデフォルト値よりも小さな値にすることで、
子プロセスあたりの スレッド数をより多く持たせられるようになります。 このタイプの
調整は、テスト環境でウェブサーバを完全に テストできる場合に限って行なうべきです。
まれに多数のスタックが要求されるリクエストを受けることがあるかも しれないからです。
Web サーバの設定を変更すると、現在の ThreadStackSize の設定が取り消される
場合があります。

…ううむ、大きくするのがよいのか、小さくするのがよいのか。
あるいは実はあまり効果がないのか。

とりあえず、今は >>357 にしておくか。

>>359
1000000 かな。それとも 1048576 ?

スタックは誰が使うスタックですか?

だんだん、思い出してきました。

前は、dso 版 read.cgi でこの局面になったですね。
auto 変数で 512M のバッファとかとっていて、
それが Apache 2.0 の worker MPM ではうまく動かなかったんでした。

ちょっと、過去ログを見てみるか。

>>362
httpd の 1 スレッドのはず。

512M?

で、>>363 は、
SunOS さんのアドバイスで、apr_palloc() を使って動的にとるようにして、
解決したのでした。

× 512M
○ 512K

それはヒープ? >>366

>>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と同じになるみたいです)

私の中ではスタックは 1M はあるという意識で組んでいたり、

read.cgi の件は、これですね。

read.cgi再開発スレ Part2
http://qb5.2ch.net/test/read.cgi/operate/1105909861/428 あたり。

>>368
そのはずです。
向こうの read.cgi スレでやったはず。

>>369
なるほど、5.4R までのデフォルトと変わっているですか。

>>370
そんなわけで、64k しかなかったと。

1スレッドのスタックとすると
.dso 等にはどれくらいの残りがあるんですかねぇ

ということは、これではないっぽい、、、のかな。
あるいは 1M にしたことが、副作用を呼んでいるのか。< live22x

# ってことは、Apacheのドキュメントにあるように
# あえて少なくする(5.4Rの時のように)ことも、ありなのかしら。

>>374
ん、ちとはっきりとはわからんです。
(そこに来るまでにどこまで消費されているか、ってことですね)

どれだけ同時に起動されていて
どのように使っているのかわからないので、一概には言えないけど、
もと　65536 を read.dso に渡していたならそれを巨大にするのはかなり危険かも、
ただし Apache等で必要ならまた別の話ですが、

>>377
live22 は read.cgi 動いてないですが、
フロントにも同じことがいえるのかもですね。 < read.cgi の話

で、FreeBSD 6.0R で変わった(でかくなった)とすると、
そこの部分を元のように＊減らして＊みる、というのは、
意味があることなのかも。

FreeBSD 6.0R では、こうか。

/*
* Miscellaneous definitions.
*/
#define THR_STACK_DEFAULT (sizeof(void *) / 4 * 1024 * 1024)

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

ということですか。

…ということは今の設定(>>357)は結果として、
1スレッドあたりのスタックサイズを 1/4 にしたことになるのかな。

という前提で >>360 を読むと、

> ThreadStackSize を OS のデフォルト値よりも小さな値にすることで、
> 子プロセスあたりの スレッド数をより多く持たせられるようになります。

が、とても気になりますね。

なるのではないかと、

通常、減らすのは、
ThreadsPerChild に 3000 とか、大きな値を指定する場合で、
普通なら減らす必要はないと思います。

つまり、これで試してみることには、おおいに意味があるかもしれないと。

>>384
ふむ、、、。

でも問題きりわけのためには、意味があるのかもですね。< 今の設定

スタック使いすぎでスワップが発生しているなら意味があるのではないかなぁ
そうでないなら意味ないと思う

>>387
メモリは余裕ある状態と思います。< live22

「スタック使いすぎで」はランボーないい方か、

子供たちにスタックを与えすぎて合計のメモリが逼迫しているならってことです

…さて、そんななか明日以降の予定。

○ live22x4, live22x5 フロントに再投入(済)
○ live22x2 OS・Apache 更新(済)
・live22x3 復活 & フロントに再投入
・live22-2 (= cobra2247) 投入 with FreeBSD 6.1-RC2 or 6.1R => まずは問題解決しないと
・live22, live22x1 OS バージョンアップ + Apache 更新

>>389
なるほど。そういう意味ですか。

…このへん、状況の整理が必要そうですね。
>>325 >>328 の kern. なんたらの話も含めて。

で、今日はちとエネルギー切れという感じです。
といったわけで、そろそろ店じまいの時間で。

>>325は私の書き込みですが、
procmapを使用して、VMのマッピング状態をみることにより、
Cannot access memory at address 0xXXXXXXXX の
0xXXXXXXXX がマッピングされているのか、
そのアドレスがスレッドスタック領域内か付近か見たかったわけです。

FreeBSDはgrow stackを使用するので、スレッドスタックが1MBだとしても、
最初は128kの領域しか取りません。以後は必要において1MBまで拡張されます。
通常の状態であれば、procmapを使って稼働中のhttpdの状態を見たときは、
下の方に多くの128kの領域があるはずです。
もし、スタックが拡張されていれば128k+拡張された領域が見えます。

スタックを小さくするのは、単にアドレス空間の枯渇を防ぐためですよ。

例えば某OSのデフォルトだと、スタックは1スレッドあたり10M程。
ということは、32bit環境では、どんなに頑張っても
400スレッド(事実上200以下)しか出来ないわけですね。

これを増やすために、1スレッドのサイズを減らすということで。

kern.dflssiz, kern.maxssiz, kern.sgrowsiz は、
これらを設定した方が良いという意味ではなくて、
設定することにより動きが変わってくるので、確認の意味で書きました。
特に、kern.sgrowsizは、上記の最初の128kというサイズに影響を与えます。

kern.dflssiz, kern.maxssiz は、limit などで表示されるスレッドの制限に
影響を与えますが、これは最初の main スレッドの制限なので、
worker の場合はあまり関係ありません。

ちなみに、今話しているのはPentinumなマシンなんですよね?

>>393
そうですね。
FreeBSDはi386(32bit)だと、デフォルトのサイズは1MBなので、
デフォルトでは2500弱のスレッドしか作れないです。
よって、ThreadsPerChildもそのあたりが限界。
もし、ThreadsPerChildを3000とかにすると、pthread_create()が失敗するので、
Apacheが起動できません。

>>395
それは、amd64(64bit)ではなくて、i386(32bit)の話という意味でしょうか?

x86といったほうがいいのだろか、

設定うんぬんということならば、
同じFreeBSDである限り、i386でもamd64でも変わらないでしょうが、
amd64だとVMのアドレス空間が莫大になるので、
アドレス空間の枯渇の問題は、ほぼ起こらないと思っていいでしょう。

おふろを出ると、話が進んでいるですね。

>>392
ふむふむ。

>>393
なるほど、わかってきました。

>>394
そういうことでしたか。

なんか「おいでよどうぶつの森」の博物館の
フクロウさんを思い出したのは内緒です。

あと、kern.sgrowsizを設定しているかどうかにより、
Red Zone が作成されるかどうかにも影響を与えます。

FreeBSDは Thread A のスタックと Thread B のスタックの間に
Red Zone と呼ばれるアクセス読み書き不可の領域をわざとつくり、
Thread A が Thread B のスタックを破壊するのを防ごうとします。
ただ、grow stack のせいで、デフォルトの設定だと
Red Zone が作成されないんですね。

kern.sgrowsizの設定を尋ねたのは、Red Zone が作成される設定になっているか
確認する意味もありました。

>>402
なるほど、
ということは、Red Zone を作る設定にすると、grow stack ではなくなる、
ということですか。

>>401
そのこころは、、、。

なんか　何十年たっても結局同じ話をしているんだなぁ
面白いっすね、

これからプログラムを書こうという人は是非ここを学んで欲しいと思ったりなんかして、
hehehe

>>404
> hehehe

表情が思い浮かんだですよ。

で、live22x3 HDD 交換完了とのこと。
これは明日以降、たんたんと。

>>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 を設定した方が良いという
意味ではないです。

cobra2247 ですが、oyster901 = ex14 でコンパイルした
GENERIC カーネルでブートしたところ、make buildworld buildkernel 通りました。

# -j 4 つけると 1 error になり、
# /usr/obj の下にひとつ usr -> var なシンボリックリンクが必要だった。

live22x3 6.1-RC2 で復活。
これで、フロントはとりあえずの完成形に。

cobra2247 をやるか。

>>408
いや、live22x1 のバージョンアップがありますね。
live22 もか。

>>409
姉（live22）のバージョンアップ作業ですが今日の深夜が無難な時間帯です。
明日はＦ１にダイバスターとサッカー、明後日はＦ１とサッカーがあります。

>>410
んじゃ、そうしますかね。

2時間程度、全部止める必要があるので。

【実況】　live22x　Part18
http://qb5.2ch.net/test/read.cgi/operate/1145623625/253

スケジュールしました。
準備しておくか。

-i 2 -I 60 → -i 10 -I 120 にした。 < bbsd

signal 10 で落ちる症状は変わらない模様ですね。

バージョンアップ前に、
いったん、 ThreadStackSize 262144 を元に戻すか。
他もいったん、設定の棚卸というかんじで。

>>322の
> esp 0xb858aa3c 0xb858aa3c
> ebp 0xb858aa58 0xb858aa58
ってのは、スタックオーバーフローなんですかね？

まあ、スタック領域がこの辺にあってもおかしくは無いのですが
むしろ、バッファオーバーフローで変な領域にspが設定されている気もします。
(ebpの退避されている領域にゴミが書かれると、espにも伝播して壊れるはず)

実行環境(FreeBSD/amd64)での、スタック/ヒープ/コード(リテラル)/静的データ(bssが別ならそれも)の
それぞれのおよその配置と比べてみて
esp/ebpに設定されているのがどの領域なのかは
確認してみたいところですが。

それと、
関連スレは全然チェックしてないのですが

Signal10の原因はOSかApacheのコアだというのは間違いないのですかね？
SpeedyCGIとmod_cgidso、及びdso版read.cgiが原因という可能性は？

というのは、もし単純なバッファオーバーフローがapacheのコア部分にあったら
簡単に発見されて修正されそうな気がするので
もしバッファオーバーフローであれば、追加モジュールに原因があるのではと。

<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

>>416
live22 は read.cgi 動かしてないので read.cgi (cgidso) 動いてないです。

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

で、live22-2 を動かすには、
read.cgi と bbs.cgi を更新する必要があるですね。

もちろん、掲示板システムの入れ込みとか F22 (F15?) の起動とか、
そのへんも必要で。

なんでなんで?

前回その話になったとき、 live22x? を使うんじゃなく
別のvirtualをどんどん追加していくと言っていたような、

>>421
なるほどなるほど。

live22x っていう名前、変えてもいいんだった。
うっかりしていました。

news20 でよいですかね。

つまり、

cobra2247 = news20
tiger2523, 2524, 2525, 503, 507 = news20x1 〜 news20x5

というわけで >>419 はとりさげて、申請出しなおしますです。

というわけで、

live22x という名前で、複数バックエンドにする

もんだと、勘違いしていました。すんません。
news20(x) のつもりで、設定ごにょごにょしてくるです。

なんだか様子が変ですー
http://sv2ch.baila6.jp/server.cgi?server=memories.2ch.net

>>426
んーむ、httpd の暴走ですね。
これも原因つきとめないとなぁ。

ということで、改めて 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

>>390
○live22x3 復活 & フロントに再投入(済)
○live22 OS バージョンアップ(済)

・news20 構築 DNS 変更依頼中、DNS 登録完了後作業継続予定
・live22x1 OS バージョンアップ + Apache 更新 これから

#!/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 なし以外は、概ね通常のサーバ設定。

寝る前に、news20 関連のアカウント情報をメールしておくです。

私の環境では見えるみたい。
http://news20.2ch.net/

そのうち、done. が来るかなと。

# 掲示板システムは、news20b に作ることになるです。 > かっこいいおにいさん

news20ﾐｴﾀ＼(^o^)／

(ﾟ∀ﾟ)

おらわくわくするぞ

6.1-RELEASE タグ来てますね。
ちょっとだけ遅かった?

きましたか。
ということは今週中にはアナウンス出る感じかしら。

>>437
むむむさん、memoriesが例によって例の調子です。

uptimeをみるとクローラさんがどかどかとかっさらっている最中にhttpdがあっぷっぷしたみたいな。。。
＠牡蛎902

news20b は最初から 6.1R でいけるのかな。

memories は OS 更新したいところだけど、
センシティブな構成だから、リモートコンソールがないと微妙かも。
まずは Apache とか更新しておくか。

そろそろ削除呪文系も対応しないと、バックエンドが
2つ(以上?)になるともっと大変になるかも。

おじさんのいう勝ちに行くっていうのは、やっぱり
WCUPに対してなんですよね。
サーバ群(7台)の機能分担が鍵ですよね。今のところ、
単機能のフロント側の負けはないようなので、mod_cacheを
導入しない場合は、正直フロントは3台で十分のような。
live22x1のbbsdを単独サーバにしたほうがよいのかも。

>>441
呪文は、例のとりあえずmod_proxyでフォワードするというのを、
ちと試してみるです。

で、news20 がうまく稼動したら、たぶん news19 を空けることできて、
news19 は既に XO ロケーションに、、、とか、いろいろと。

cobra2247 を 6.1R にすべく、make buildworld を流していたら、
突然ハングアップしました。

ううむ、、、。

・ping かからない
・KVM で見ると画面が出たまま凍っている

…とりあえず、リブート要請出します。ううむ。

とりあえず、Apache2.0 と PHP4 をそれぞれ最新にしてみた。 < memories

本日準備できたら、live22x1 のバージョンアップ作業する予定。
規制系 DB 用の bbsd は、一時的に live22 へと(作業済)。

%uname -a
FreeBSD banana273.maido3.com 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sat May 6 08:05:11 PDT 2006 [email protected]:/usr/obj/var/src/sys/I386_BANANA_61 i386

cvsup.peko.2ch.net、特に問題なく。

>>444
リブートしてもらいましたが、
ログインして操作しているうちに、またハングアップしました。

ちと、まじめに調べてみます。 < cobra2247

リモートコンソールで操作中。

一世代前のカーネルに戻してみる。

一世代前のカーネルだと、ちゃんと動くようだ。
微妙だ、、、。

もう1回 make buildworld buildkernel からじっくりやろう。

>>445
改善しないっすね。

apache2limits_args="-e -t 600"

にしてみた。< 前は 1800 だった。

bbs.cgi 等配布リストに、live22x4/live22x5 を追加した。

もう1回、教科書どおりのほうほうでカーネルとユーザランドを更新しなおしてみた。
普通に 6.1R になったところで、SMP ありのカーネルに差し替え。 < cobra2247

無事に上がったので、make -j 4 buildworld (負荷試験のかわり)を実施中。

死にました、、、。

SMP なカーネルに問題があるのか。
あるいは CPU が片方いまいちなのか。

このカーネル config は、ex14 のと同じなので、
問題があるとはちと考えにくいが、、、。ううむ。

リブート要請と、調査依頼を出しておくです。

>>429
○live22x1 OS バージョンアップ + Apache 更新 … 済 6.1R
・news20 システム構築 … DNS 登録 done 後作業継続予定、ただしトラブル解決後
・news20b = cobra2247 トラブル中、調査依頼中 … 土曜日なので週明けからか
・memories = oyster902 httpd が暴走する問題 … とりあえずその場しのぎを入れてみた
・削除の呪文の mod_proxy でのフォワード … 別途すすめる

違うとは思えないけど、
config ...; make cleandepend; make depend; make で作ったカーネルと、
make buildkernel KERNCONF=... で作ったカーネルでやってみた。

しかし、やはりだめだった。

リブート依頼と調査依頼(一時的に作業依頼止めていた)出します。

# 今日は、ここまでで、、、。ううむ。

>459
お疲れ様でした〜
原因は指摘してるＣＰＵ１発あぼ〜ん説に一票
ＳＭＰ無しで動くのに有りにするとこけるなんて１発壊れてるとしか思えない

>>460
前の謎のパニックメッセージ (>>175) とかを見てみると、
その可能性は高いかもしれないですね。

現地に、その旨もメールして置きました。

乙です。

live22のOS version up後もsignal 10で
落ちていますか？

>>462
まだ一度も落ちていません。
負荷がかかっていなくてもたまーに落ちてたんですが。

いずれにせよ、このまま観察します。

6.0R の頃は >>463

フロントエンド5台も、signal 10 は現在まで一つも観測していない模様。

今見てみましたが、signal 10 がひとつもありませんね。< live22/live22x1

これは、バージョンアップが有効だったということなのかしら。

6.1R にして、全体的に明らかに軽くなった気がするんだけど、
何が変わったんだろう。

5.4R → 6.0R の時は、ファイルシステム周りが劇的に軽くなった気がしたんですが、
6.0R → 6.1R では、全体になんとなくっていう感じ。

ぢぇんぬさんに教えてもらった削除系標準呪文セットを、
mod_proxy で live22 にとばすようにしてみた。

これで、うまくいくといいけど。

そういえばいただきオンラインって、
live22x => live22 という処理入れていたんでしたっけ。

もし入れていたら、解除をお願いしますです。 > いただきさん

お知らせしてきました。

☆ 連絡＆報告 6 ☆
http://qb5.2ch.net/test/read.cgi/saku/1127100825/940

>>469 をいただきさんに知らせるには、
どうすればよいのかしら。

>>428
done

>>470
たもんくんのスレで告知してる人がいらっしゃいました。

>>471
どもです。

>>472
どもです。

>>458
・news20 システム構築 … DNS 登録済、ただしトラブル解決後
・news20b = cobra2247 トラブル中、調査依頼中 … 週明けからの見込み
○memories = oyster902 httpd が暴走する問題 … その場しのぎはとりあえず機能している模様(後述)
○削除の呪文の mod_proxy でのフォワード … 設定済、異常報告があれば対応
・なにやら大きな引越しがあるとかなんとか … 動きが決まってきたらということで

こんなかんじ @ 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

>>470 修正しました。

>>476
ありがとうございました。

>>474
> ・なにやら大きな引越しがあるとかなんとか … 動きが決まってきたらということで

【365Main】 回線増速(ニュー速とかお引越しのご案内)
http://qb5.2ch.net/test/read.cgi/operate/1147078648/

はてさてふふ〜ん♪ ってかんじで。

でっきるかなー。

FreeBSD 6.1 Released
http://lists.freebsd.org/pipermail/freebsd-announce/2006-May/001064.html

ということで、正式アナウンス出ました。

>>480
おお。さっそくex14(ry

news20b が退院したという情報が入りました。
負荷テスト後問題なければ、news20 本格稼動へと。

負荷テスト(make -j 4 buildworld) を流して数分もたずにハングアップしました、、、。
中の人と調整中。

冷却ファンが動いていないとか言うオチはないですよね。

今回の修理は、ファンの交換だったと聞いているです。

…しかし、CPUの温度は確かに高いです。

ファン交換前は CPU #0 が52℃、CPU #1 が58℃でした。
今は CPU #0 が49℃、CPU #1 が53℃のようです。

ううむ。

センターうんこじゃないとか

ちょっと、他の cobra サーバの様子をみてみるか。

ちょっと BBQ サーバ、リブートします。
BBQ2 があるので、システム自体は止まらないはず。

BBQ = cobra2245 は、#0 #1 とも 55℃ ですね。

でも、数ヶ月以上問題なく動いていました。
つまり、CPU ファンの異常とは思えない。

BIOS のスクリーンショットを保存して、立ち上げなおし中。
…これは、原因は温度上昇ではないですね。

BBQ ブートアップしました。

…まさか、とは思うものの、
ex14 から /boot/kernel/kernel だけ抜いてきて、
その環境で動かして、負荷テストしてみることにした。

amd64 な FreeBSD 6.1R は初体験のはずなので。

なんか、止まらないや、、、。
うーむうーむ。

FreeBSD for AMD64(and for oyster901)
http://pc8.2ch.net/test/read.cgi/unix/1075691732/804

804 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2006/03/15(水) 09:50:47
X2 4200+ 6.1-PRERELEASE だけど、
options SCHED_ULE
options ADAPTIVE_GIANT
を共に有効にしたカーネルのとき、/をマウントするところで凍ったことはある。
どちらか一方なら平気だけど。

今は ADAPTIVE_GIANT を切って様子見ているけど。

SCHED_ULE は有効にしていないので、大丈夫だとは思うんですが、
ううむ。

6.1R で入った機能というと、kbdmux か。
はずしてみます。

ばりばり make 流してますが、落ちる気配ないですね。

これは、何らかのソフトウェア上の問題で確定かなと(まじかよ)。
>>497 を試すべく、準備中。

あるいは、これだとちといやだなぁ、、、。

http://www.freebsd.org/releases/6.1R/todo.html
UFS deadlocks on amd64
Needs testing
Tor Egge Seen by Kris Kennaway. This problem seems MI.

kbdmux を外したカーネルにして、make -j 4 buildworld を実行。

動いてます、、、。

make は好調に続いています。

#device kbdmux # keyboard multiplexer

これをカーネル設定ファイルから外したら、動きました。

この設定(キーボードマルチプレクサ)は 6.1R から、
i386 と amd64 では、標準で有効になっています。

i386 では、これまで問題は起こりませんでした。
banana, 旧tiger, 新tiger いずれも。

amd64 (cobra) で、かつデュアルCPU有効のカーネルの場合にのみ、
このオプションがあると、ちょっと負荷をかけると、ハングアップするようです。

で、この機能は２ちゃんねるのサーバでは使用していないので、
無効にしても、特に問題はないです。

# はまった、ってことか。

…ということで make -j 4 buildworld が完走したら、
問題解決ということでよいと思います。

あとはたんたんと構築して、第二の雪だるまデビューということで。

kbdmux ってキーボードの抜き刺しが出来るってやつ？
コンソールと相性が悪いのかな？

>>504
BIOS かもしれないし、ACPI かもしれないし、
KVM との相性なのかもしれないし、他の問題かもしれないですね。

デュアルCPUの時だけ再現するというあたりが、なんとも。

再現 → 発現

http://pc8.2ch.net/test/read.cgi/hosting/1123324035/
ネタだと思いますがrootたんのフルネームばらすとかなんとか言ってるので一応反応お願いします。

make -j 4 完走しました。
原因確定・問題解決ということで。

セッティング作業の続きは、帰宅後にでも。
かっこいいおにいさんとタイミングが合えば、
今日明日にも本格稼動可能と思います。 < news20

>>507
反応

>>495
のわっ、このスレまだ1000いってなかったのか・・・・

>>507
なにこのネタスレと反応してみる

ネタスレに見えますがこのスレがGW中に規制された●+公開p2の発祥地です。

bbsd の nice -20 を復活。< live22, news20b

続いて、

# StartServers 96
# ServerLimit 96
# ThreadLimit 32
# ThreadsPerChild 32

を、

StartServers 192
ServerLimit 192
ThreadLimit 16
ThreadsPerChild 16

に変更。< @live22

今日のサッカーでは、2回しか落ちなかったそうですが、
やっぱり今までと同じsignal 10でcoreも同じところを
さしているんですかね。

>>514
2回目の時に httpd が二つ落ちました。
今 news20 のフロント作っているので、それができたら解析をば。

news20 フロント側、準備できたはず。

バックエンドを、かっこいいおにいさんに作ってもらおうと。

いよいよニュースな雪だるま本格始動ですか
予定としてはnew18と19ついでにlive22からnewsを移転させる形になるんでしょうか？

>>517
私の皮算用はそんなかんじですが、さて、どうなることやら。
まずは「勝ちに行く」ために、news を移転するかんじかなと。

>518
昨日のデータ

live22x　513,616
news　78,380


※約１５％程度減るのでかなり楽になるんじゃないかと思います。

>>514
(gdb) thread 31
[Switching to thread 31 (Thread 0x809d700 (LWP 100452))]#0 0x282fc363 in kill
() from /lib/libc.so.6
(gdb) where
#0 0x282fc363 in kill () from /lib/libc.so.6
Cannot access memory at address 0xbf6fba0c
(gdb) info frame
Stack level 0, frame at 0xbf6fba10:
eip = 0x282fc363 in kill; saved eip Cannot access memory at address 0xbf6fba0c
(gdb) info registers
eax 0x0 0
ecx 0x1be42ad0 467938000
edx 0x691 1681
ebx 0xa 10
esp 0xbf6fba0c 0xbf6fba0c
ebp 0xbf6fba28 0xbf6fba28
esi 0x285d9000 677220352
edi 0x5af 1455
eip 0x282fc363 0x282fc363
eflags 0x296 662
cs 0x33 51
ss 0x3b 59
ds 0x3b 59
es 0x3b 59
fs 0x3b 59
gs 0x1b 27
(gdb)

>>519
15% もさることながら、
やっぱりでっかい subject.txt と subback.html と index.html の作成コストですね。
このへんは bbsd になっても、根本的には変わらないところだから。

>>520 乙です。

>>325-327 の手順で解析できればもう少し何かわかるんですかね。

ちなみに落ちたときのbbsdのインターバルは10秒のままなんですか。

>>522
>ちなみに落ちたときのbbsdのインターバルは10秒のままなんですか。

5秒ですね。

たまたま
はげしく酔っ払いなんで、明日の昼にでも。。。

>>521 ドバッっと来た時にやっぱ苦しそうですか？＜bbsd　それともディスク I/O かな？
subject.txt は内部的に linked list で持ってるんで，並べ替えはスレ保持数にかかわらず
ポインタ3つ変更するだけなんで，配列をごっそり動かすのに比べれば軽いかとは思うんですが......

>>524
了解です。

>>525
ディスクI/Oかなとみています。

あと bbs.cgi における経験的には、index.html と subback.html のコストがでかいかなと。
今 ex14 ではピーク時に 1000res/min ぐらい問題なくさばけているようですが、
これは Saborin (index.html と subback.html の更新をまばらにする)が、でかいようです。

で、ここまで書いていて思ったのは、
subject.txt とそれ以外の動的更新ファイルの更新インターバルを
bbsd で個別に指定できるようになると、うれしいかもですね。

で、live22は既にHDDを54%も使用しているので、
先日別処で話題にしたように、news20 と同じネーミングルールで live23 を作って、
そのうちそっちにごっそり移動する感じで。

やるにしても物の怪のあとにしませう

たぶん、物の怪に備えて、だと思います。

>>170
thttpd
http://www.acme.com/software/thttpd/

ここにすごいことがいろいろ書いてあるですね。
非圧縮の dat のところだけ、これにしてみるとかありなのか。

別途、試すということで。

cobra2244 が上がったら、プライベート側の IP アドレス振ってきます。
(さっきやればよかったんですが、落としてしまってから気がついた)

ping 待ち中。

…って、○○○したっぽいすね。

頑張って下さい。

>>530
lighttpdが忘れ去られているような気もしなくもない。

あと、一時注目された日本製のサーバーソフトのesehttpdぐらいかな。
http://esehttpd.sourceforge.jp/doc/ja/index.html

FreeBSDにはカーネルで動くhttpdは無いのかな。
あればそっち系が最強なんだろうけど。行儀のよさはともかく。

>>534
・読み出しのパフォーマンスが高くて
・gzip 圧縮が動作して
・できれば、cgi が動作する

そんなものがあると、とてもうれしかったりして。

>>536
lighttpdは一応，下の二つに関してはできるようです．
mod_compressとmod_cgiを使えば．

パフォーマンスはどうなんでしょうねぇ
早いとは聞きますけど，実際どうなのかはイマイチ
わかりませぬ……

>>537
おー。

落ち着いたら試してみよう、そうしよう。

>>537
が，動的コンテンツに大しての圧縮に関しては，
PHPはできるようですがそれ以外は　？？
静的なものは出来ますね．

>>539
バックエンドというぐらいで、性的なものだけで十分です。
ようは、datとsubject.txtですね。

read.cgi の場合、フロントが圧縮してくれると。

性的 → 静的

　　_, ._
（　ﾟ Дﾟ）

>>540
なるほろ．

ttp://www.lighttpd.net/documentation/compress.html
とりあえず参考までに．

>>526 最終段落のを反映してみますた．
　　　　-i subject_txt_interval[:subject_html_interval]: subject ファイル更新間隔(秒) [デフォルト: txt = 5, html = txt に同じ]

で，mod_proxy でフロント側に渡すコンテンツについてはバック側の httpd は
ポート 80 にこだわらなくてもよい，つまり呪文 CGI 等は普通に Apache 使って，
一方 dat や subject.txt 等は軽量版 httpd を別ポートで走らせる，ってことでも
いいのではないかと．圧縮もフロント側にやらせればバック側は sendfile() 一発ですね．
プライベートネットワークのトラフィック削減は mod_cache の仕事ってことで．

>>535
OpenKeta というのが一応ある。
http://openketa.sourceforge.net/
使ったことないし、6.1でもそのまま動くかどうかはわからない。

>>544
どもです。

#!/bin/sh
exec 2>&1
exec env - TZ="JST-9" PATH="/usr/sbin:/usr/bin:/bin:/usr/local/bin" \
LANG="ja_JP.SJIS" \
/usr/bin/nice -n -20 setuidgid ch2live22 /usr/local/sbin/bbsd -f \
-c -b 192.168.100.1 -d /home/ch2live22/public_html \
-i 5:30 -I 120 -n 8 -p 2222 -s live22x.2ch.net

live22 こうしてみました。
txt は5秒、html は 30秒間隔。

なお、64bit 環境でコンパイルすると、

bbsd.c: In function `workerloop':
bbsd.c:2958: warning: cast to pointer from integer of different size

となる様子。

>>544
mod_proxy って、こういうのどう動くんでしたっけ。

・back =mod_proxy= front <= dat 直どり、gzip圧縮をリクエスト

このとき、
back で圧縮
front で圧縮

どっちかなと。

# back が圧縮している気がする。

>>548
あ、でも見ていると、ちゃんと倍ぐらい転送量出ているから、
圧縮はフロントでしているのかな。

# ちと寝不足なんで、ぼけてるかな。

>>547 そうか......LP64 だから sizeof(int) < sizeof(void *) と．修正しますた．

>>548 バックの httpd で mod_deflate が働いてればバックが圧縮し，
バックで mod_deflate が働いてなければフロントが圧縮します．

>>550
おー、それって、mod_deflate ないほうがいいのね、バックには。
やるやる。

負荷が下がった♪ @ live22

更新しました。 bbsd @ live22, news20b

おめでとうー。

mod_deflate オフは、live22 と news20b で実施。

>>551-555
麦茶をどうそー

つ　旦

>>551-553 >>555 乙です．が......ひょっとして mod_deflate に AddOutputFilterByType 使ってますか？
コンテンツが圧縮されてないようなんで...... reverse proxy の場合 AddOutputFilterByType は効かないので，
mod_filter 使った方がいいかと． http://httpd.apache.org/docs-2.2/mod/mod_filter.html

FilterDeclare deflate CONTENT_SET
FilterProvider deflate DEFLATE Content-Type $text/
FilterChain deflate

>>557
なるほど。

ばっちり、AddOutputByType 使っているです。

AddOutputFilterByType DEFLATE text/html text/plain text/css text/xml application/x-javascript

上記と等価にするためには、

FilterDeclare deflate CONTENT_SET
FilterProvider deflate DEFLATE Content-Type text/html text/plain text/css text/xml application/x-javascript
FilterChain deflate

これでいいのかしら。

あともうひとつ心配があって、
Apache 2.0 なサーバと .htaccess は共有していたりするわけですが、
2.0 なサーバに悪影響出ないのかなと。

# 出るようなら、とりあえず httpd.conf でやろうかと。

<IfModule ...> </IfModule> で囲めばいいのかな。

いずれにせよ、到着してからということで。

>>558-560 FilterProvider では単純列挙ってのはないので，同じようにやるとしたら regex でやることになるかと．
あと，mod_filter は 2.1 以降しかないんで IfModule で囲めば Ok ですね．

# mod_filter がない 2.0 まで用
<IfModule !filter_module>
    AddOutputFilterByType DEFLATE text/html text/plain text/css text/xml application/x-javascript
</IfModule>

# mod_filter がある 2.1 以降用
<IfModule filter_module>
    FilterDeclare deflate CONTENT_SET
    FilterProvider deflate DEFLATE Content-Type /text\x2F(html|plain|css|xml)|application\x2Fx-javascript/
#    FilterProvider の regex 中の / は \ でエスケープしてもダメポなんで \x2F で......
#    というか text/.... は個別に列挙しなくてもいいかも？
#    FilterProvider deflate DEFLATE Content-Type /text\x2F\w+|application\x2Fx-javascript/
    FilterChain deflate
</IfModule>

<IfModule filter_module>で2.0って誤爆しないの？

あ、そもそも一致しないから誤爆するわけないですね。すんません。

サポート切れるとなると5.5か6へのリプレース計画を立てる必要があるかも


ttp://lists.freebsd.org/pipermail/freebsd-security/2006-May/003695.html

4.10の鯖なんてあったっけ？

>565
問題になってくるのは5.4Rのサポートが１０月で切れちゃうこと
（5.4R使用マシンは多い）

ネットワークトラフィックが多くて、bbsd が通信できなかったのかな。
だとすると、ちと微妙だなぁ。

でも、ピークは「だまれなんたら」じゃないのか。

だとすると、bbsd のスレッド数を最初から多くしておくといいのかな。

【蕨】負荷監視所_20060511
http://live14.2ch.net/test/read.cgi/liveplus/1147326099/230

…やはり「だまれなんたら」らしいみたいですね。

ニュース速報運用情報 4
http://qb5.2ch.net/test/read.cgi/operate/1144597637/947

うーむ、とりあえず後でみてみることにしよう。

liveb1 関連
ex12 削除
news20 追加 済。

>>561- を後で処理する (ちらしのうら)。

>>561
うーん、なんか入れても動かないです。

mod_deflate を httpd.conf 的に mod_filter よりも先に読まないといけないのかと思って、
変えてみたりもしたのですが。

もうちょっと調べてみます。

うーむ、

# for Apache 2.0 (original mod_deflate)
<IfModule !filter_module>
AddOutputFilterByType DEFLATE text/html text/plain text/css text/xml application/x-javascript
</IfModule>

# for Apache 2.2 (emulating mod_deflate for Snowman front-end servers)
<IfModule filter_module>
FilterDeclare deflate CONTENT_SET
FilterProvider deflate DEFLATE Content-Type /text\x2F\w+|application\x2Fx-javascript/
FilterChain deflate
</IfModule>

で、
GET /index.html HTTP/1.1
Accept-Encoding: gzip

は圧縮されるけど、
GET /livecx/index.html HTTP/1.1
Accept-Encoding: gzip

は、圧縮されないみたい。

>>573
# for Apache 2.2 (emulating mod_deflate for Snowman front-end servers)
<IfModule filter_module>
FilterDeclare deflate CONTENT_SET
FilterProvider deflate DEFLATE Content-Type /text\x2F\w+|application\x2Fx-javascript/
FilterChain deflate
</IfModule>

ここをコメントアウトすると、

GET /index.html HTTP/1.1
Accept-Encoding: gzip

も圧縮されなくなるから、上記が効いていることは間違いなさそうだけど、、、。

ローカル？

mod_filter が mod_deflate の上の行で読まれていても大丈夫みたい。
順番は関係ないと。

でも、状況は変わらないなぁ。

>>575
ローカルのものは大丈夫で、
mopd_proxy 経由がだめみたい。

んー、いろいろ試したけど、なんかうまくないすね。
mod_proxy.c もさらっと読んでみてみたんですが。

なんか限界なんで、そろそろオフラインになります。
# しかし、外人どもは元気だ、、、。

お疲れさまです。
ゆっくりとお休みくださいな。

http://httpd.apache.org/docs/2.2/mod/mod_filter.html

FilterProtocolディレクティブは関係ないのかな？

FilterProtocol deflate proxy=yes

いろいろ試してみたんですが、mod_filterがどうたらの問題ではないんでは？

http://orz.stream.st/cache/test.txt　←ローカルのファイル
http://orz.stream.st/cache/subject.txt　←　http://live22.2ch.net/liventv/subject.txt


<Directory /○○/cache/>
AddOutputFilterByType DEFLATE text/html text/plain text/xml image/bmp
</Directory>

↑だとtest.txtは圧縮され、subject.txtは圧縮されません。



<Proxy http://live22.2ch.net/liventv/subject.txt>
AddOutputFilterByType DEFLATE text/html text/plain text/xml image/bmp
</Proxy>

↑だとsubject.txtは圧縮されます。

もしかして・・・と思ったらやっぱり。

http://live22x1.2ch.net/liventv/SETTING.TXT ←バーボンになる
http://live22x1.2ch.net/liventv/subject.txt ←バーボンにならない

>>582
live22 にも配布しないといかんのかな。

mod_rpaf 入れているので、IP アドレスはリモートのものになっているはず。

.htaccessはDirectoryディレクティブと同じだから
ProxyPassで設定したところは有効にならないってことですね。
mod_deflateが効かなかったのはAddOutputFilterByTypeでもmod_filterでも
設定している場所が間違っていたと。

>>583
htaccess使う限り、そうなりますね

>>584
ということは、、、。

<Proxy>〜</Proxy> に入れる必要がある?

>>585
そうですね、それか<Location>〜</Location>。
そうなるとhtaccessじゃなくてhttpd.confに設定することになります。

>>586
なるほど。

Proxy 関連は Include しているので、そっちでやれば OK かな。

あ......そうか，

>>584
>.htaccessはDirectoryディレクティブと同じだから

というのが盲点でした......>>561 は httpd.conf 中でグローバルに定義すべきですね．

ただ......AddOutputFilterByType にはいろいろ問題があったゆえ
mod_filter が作られたって経緯もあって，その一つが

http://httpd.apache.org/docs-2.2/mod/core.html#addoutputfilterbytype
>The by-type output filters are never applied on proxy requests.

ということで（これは ByType ではない AddOutputFilter や SetOutputFilter なら平気です）．

# enable compressing
# http://qb5.2ch.net/test/read.cgi/operate/1145114275/561-588
<Proxy *>
<IfModule filter_module>
FilterDeclare deflate CONTENT_SET
FilterProvider deflate DEFLATE Content-Type /text\x2F\w+|application\x2Fx-javascript/
FilterChain deflate
</IfModule>
</Proxy>

という記述を追加してみた。 @ live22x1〜live22x5

>>589
news20f1 〜 news20f5 にも入れた。

>>589 乙です．ただ，ローカルコンテンツも reverse proxy のコンテンツも
両方圧縮するなら <Proxy *>〜</Proxy> で囲まなくてもいいのかも．

>>591
ローカルコンテンツは mod_deflate が効いていると思うのです( .htaccess の設定そのまま)。

>>592 それならそれでもいいんですが，わざわざ別々に設定しなくても......
とはいえ .htaccess は他の鯖と共通だからそれとの兼ね合いもあるんですね......
まぁ AddOutputFilterByType は今後 obsolete になるということで，
そのあたりの設定も徐々に移行させた方がいいのかも知れませんが．

>>593
> とはいえ .htaccess は他の鯖と共通だからそれとの兼ね合いもあるんですね......

なんですよね。
なんか、圧縮が2回かかってしまいそうで、安全側に倒しました。

Apache 2.2 なサーバが今後増えてきたら、また考えることになるのかなと。

そういえば......以前 bbspink の鯖でエラーページを 2ch のと別のところに飛ばすのに
httpd のコマンドラインで -Dbbspink ってやって，httpd.conf 中で
<IfDefine bbspink>〜</IfDefine> を使うってのやってたような記憶がありますが，
雪だるまでも例えば httpd -Dsnowman で起動して <IfDefine snowman>〜</IfDefine> に
雪だるま用特殊設定を入れる（逆に雪だるまで不要なのは <IfDefine !snowman>〜</IfDefine>
に入れる）っていうような手もありますね．

>>595
なるほど、、、それはいいアイディアですね。

設定の棚卸をする時に、入れるのがよさげ。

SO_RCVBUF を 262,144 -> 2,097,152 にしてみますた＜bbsd.c
この方がドバっと来た時にパケット取りこぼしの可能性が小さくなるだろうということで．
OS 側の設定でこの値に対応できるようになってることが条件ですが（対応してなければ
bbsd 起動時に "warning: setsockopt: No buffer space available" と警告が出ます）．

>>597
@40000000446893d4316e617c warning: setsockopt: No buffer space available
@40000000446893d4316e711c warning: setsockopt: No buffer space available

ふむ。何かカーネルパラメータをいじらないといけないのかな。

/etc/sysctl.conf:

#kern.ipc.maxsockbuf=2097152
↓
kern.ipc.maxsockbuf=3840000

にした。 @ live22, news20b

で、bbsd 入れ替え完了 @ live22, news20b

次の一手はなんですかね。
・mod_cacheリターンマッチ
・live23の追加(365main待ちかも)
・thttpd/lighttpd/esehttpdの評価
とか。

>>598-600 乙です．

>>601 3番目のは，バックエンドの httpd を CGI 用と静的コンテンツ用に分離すれば，
Apache でもまだ改善の余地はありそうですね．

[CGI 用 -> 呪文等]
　　・ 基本的に従来通りの設定．

[静的コンテンツ用 -> dat や subject.txt 等をフロントに転送]
　　・ 別ポート使用（reverse proxy 用なので port 80 である必要はない），
　　　 さらに非特権ポートなら root 権限なしで操作可能になる．

　　・ 徹底的にスリム化（highperformance.conf 等をベースに），
　　　 モジュールをどんどん削ぎ落とし，.htaccess も使用せず
　　　 設定はすべて httpd.conf で行うことで毎リクエストごとに
　　　 .htaccess の読み込み・パースを行わずに済む．
　　　 MultiViews も毎回 readdir(_r) することになるので使わない．

　　・ 上記のような設定により，.htaccess による Deny も効かなくなるとか，
　　　 mod_cgi(d) も外すと外部から直接 CGI を叩かれるとソースを
　　　 垂れ流すとかしてしまうので，扱うファイルを限定する．
　　　 bind() するのもプライベートアドレスに限定した方がいいかも．

        Listen 192.168.xxx.xxx:8080
        <Files *>
            Deny from all
        </Files>
        <FilesMatch "^(\d+\.dat|subject\.txt|(subback|index)\.html|)$">
            Allow from all
        </FilesMatch>

>>602 事故レス
>[CGI 用 -> 呪文等]
>　　・ 基本的に従来通りの設定．

もちろんこれは，プロセス数・スレッド数なんかはずっと少なくしていいでしょうけど．

>>601
まずは、旧 ex12 を生かす(live23bにする)方向かなと。
他のものも、適宜。

お世話になっております。株式会社jig.jpの菊池です。
一部IPを変更致しましたのでご連絡致します。

【CIDR表記】
210.188.220.168/29を追加

【IPの変更】
br1007　210.166.210.223　→210.188.220.169
br1008　210.166.210.224　→210.188.220.170
br1009　210.166.210.232　→210.188.220.171
br1010　210.166.210.225　→210.188.220.172
br1011　210.166.211.32　 →210.188.220.173
br1012　210.166.210.227 →210.188.220.174

一覧も更新致しました。
http://br.jig.jp/ip_br.html

ご対応宜しくお願い致します。

>>605
了解しました。

しかし、以前お教えいただいたこちらのページは更新されていないようです。
http://br.jig.jp/pc/ip_br.html

すみませんがあわせて更新いただきますよう、よろしくお願いいたします。

>>605
> 【CIDR表記】
> 210.188.220.168/29を追加

上記追加作業、完了しました。

素早いご対応ありがとうございます。

http://br.jig.jp/pc/ip_br.html
こちらのURLの方の更新がされておりませんでしたので
先ほど更新致しました。

宜しくお願い致します。

>>608
更新を確認しました。

どの部分がいつ変更されたかが明確で、非常に助かります。
今後ともよろしくお願いいたします。

BG3, BG4 (携帯用バックエンド)、PREEMPTION なしの設定にした。
少しでもパフォーマンスアップすればなと。

で、このへんを設定。 < BG3/4

# Thank you for AC, http://qb5.2ch.net/test/read.cgi/operate/1140540754/676
net.isr.direct=1
# increase network send/receive buffer
net.inet.tcp.sendspace=131072
net.inet.tcp.recvspace=131072
net.inet.udp.maxdgram=131072
net.inet.udp.recvspace=131072
net.local.stream.sendspace=131072
net.local.stream.recvspace=131072
net.local.dgram.maxdgram=131072
net.local.dgram.recvspace=131072
net.inet.raw.recvspace=131072
net.inet.raw.maxdgram=131072
#net.inet.tcp.delayed_ack=0

バックエンドを追加したら，本稼働の前にまた最速1000やってみるとか．

abでread.cgi叩きながらやりましょう

>>612
cobra & セッティング詰め後 & 6.1R で最速1000ですか。ちょっと面白そう。

BSDCan 2006 発表資料:
http://www.bsdcan.org/2006/papers/

どれもすごく面白いけど、一番すごかった kris の資料がまだないみたい。
Filesystem Performance on FreeBSD
http://www.bsdcan.org/2006/activity.php?id=89

ちょっと前のバージョンだけど、paper:
http://people.freebsd.org/~kris/filesystem-performance.pdf

ex12に入れていた設定を、ex13に反映した。

#
#
# Currently, cobra2246.maido3.com serves a virtual host of ex13.2ch.net and
# it is exclusively assigned for soccer bulletin boards in 2ch.
#
# And European large soccer games are sometimes held at early morning time
# in Japan. That is, I rearranged daily data backup time of this server
# for avoiding an increase of system load.
#
# -- Mumumu
#
#0 13 * * * /usr/local/bin/home-backup.sh /home
0 16 * * * /usr/local/bin/home-backup.sh /home

exclusively じゃないのかな。今は。
あとでコメントを変えておこう。

>>615 の kris の発表に、
6.0R では swap-backed で async な md の性能がいい、ってあったので、
ex14 で試してみることにした。
(5.4R でパフォーマンスが出なくて、一度負けている)

#/sbin/mdmfs -M -s ${_MDSIZE} -i 2048 -o noatime md /md
↓
/sbin/mdmfs -S -s ${_MDSIZE} -i 2048 -o async,noatime md /md

に変更。

live23 関連、DNS 登録申請します。

以下の追加をお願いします。

+live23b.2ch.net:206.223.150.61
+live23f1.2ch.net:206.223.150.64
+live23f2.2ch.net:206.223.150.74
+live23f3.2ch.net:206.223.150.84
+live23f4.2ch.net:206.223.150.110
+live23f5.2ch.net:206.223.150.42
+live23.2ch.net:206.223.150.96

>>618
ex14 ですが、若干負荷が下がった様子。

以前にあった、SMP だと async モードでの md への書き込みパフォーマンスが上がらない
という症状は、なくなったみたい。

>>619
done

>>621
確認しました。

作業入ります。
ログイン情報は別途。
live23 バックエンドを作れる状態になったら、あちらにて。

対ワールドカップ体制ということで、
live22, live23b, ex13 のシステムバックアップ時間を
通常より3時間遅くし、16:00 PDT としました。

<チラシの裏>
・NFS を soft mount に変更した。今後はそれで。
・mod_proxy の設定でタイムアウトするようにする。
・環境変数で雪だるまかどうかとか、いろんな情報を渡すようにする。
・あとで、914 緊急対応した bbs.cgi を元に戻す。
</チラシの裏>

ProxyTimeout 300 がデフォルトなのね。
そりゃ、いかんわ。

ProxyTimeout 3 にしよう。

http://www.maido3.com/server/nextstep.html

コアルータも更新するのね。他にもいろいろ。

<チラシの裏>
いつもチラシの裏だと思っていたけど強調する意味は何だろう・・・？
</チラシの裏>

<IfModule proxy_module>
# Shorten proxy timeout
ProxyTimeout 3
</IfModule>

を、フロント5台の httpd.conf に追加した。

めしにしよう。

各種呪文が引っかかったりしないのかな？

>>629
3秒だと、微妙ですかね。
でも調整したとしても、せいぜい5秒ぐらいかな。

>>627
TODO が入っている時は、チラシの裏って書くことが多いかも。

>>624 の残りは、これかな。
> ・環境変数で雪だるまかどうかとか、いろんな情報を渡すようにする。

あと、これも。

【365Main】 回線増速(ニュー速とかお引越しのご案内)
http://qb5.2ch.net/test/read.cgi/operate/1147078648/407

1000に1001が書かれた。珍しいパターンかも。

http://live23.2ch.net/test/read.cgi/livetbs/1148131755/1000-

NFS の件。

-s A soft mount, which implies that file system calls will fail
after retrycnt round trip timeout intervals.

softmount すると retrycnt 回 "round trip timeout intervals" が発生すると fail になると。
で、

-D Set the ``dead server threshold'' to the specified number of
round trip timeout intervals before a ``server not responding''
message is displayed.

-R Set the mount retry count to the specified value. The default is
a retry count of zero, which means to keep retrying forever.
There is a 60 second delay between each attempt.

ということは、softmount に変更して、かつこのへんも変えないとだめですね。

-R は関係ないですね。(mount の時だけか)

-D を調整すればいいのかな。

>>632 そこ透明あぼーんか何かありましたかね？
呪文が bbsd 未対応な現状では透明あぼーんがあれば起こり得ますが......

>>633-634 -x も関係ありそうですね．
http://www.freebsd.org/cgi/man.cgi?query=mount_nfs
-x　　　Set the retransmit timeout count for soft mounts to the specified value.

>>635
なるほど。削除入っているっぽいと。

-D -x のデフォルト値はいくつだろう。

>>624
わかりやすくするために変数名は「YUKIDARUMA_HOGE」みたいなのににされてもいいかも、といってみる
まあ内部的なお話なんでどうでもいいっちゃいいんですが

以下の DNS サーバへの設定追加をお願いします。

(新規追加)
+aas.u.la:206.223.157.22:300

雪だるま作戦のスレを待ち続けるスレ Part9
http://aa5.2ch.net/test/read.cgi/nanmin/1148041416/601-602

これの話について。

まず、これを実現するためには、携帯の場合 jig さんや ibis さんのように
固有情報を送っていただくか、AIR-EDGE / PHS の場合、リモート IP アドレスの
情報を送ってもらうことが必須条件になります。つまり、jig さんや ibis さんと
同じことになるわけです。

もちろん技術的には、特に難しいことはありません。
讃岐君のことですから、携帯の固有情報をきちんと送る方法で実装しようと
思ったんだと思います。

で、通常の場合は、たぶんこれで問題ないでしょう。
しかし、何かあった時が問題になります(例えば犯罪予告とか訴訟ネタとか)。

この場合２ちゃんねるからみるとたぶん、書き込みログを警察や裁判所等の
要求に応じて公開するだけで、あとは当事者間でやってください、
ということになることでしょう。

つまりこの場合２ちゃんねるは「讃岐君が中身をみているサーバから
所定の書き込みがあった」ということまでしか、責任を持つことが出来ないことになります。

(続く)

で、讃岐君はきっと「固有情報を送っているじゃん。その固有情報の人が悪いんだよ」
と言うことになるでしょう。

でも、その固有情報が２ちゃんねるから見た場合、
本当に携帯側から送られてきたものそのままかどうかについては、
全く保証できません。

つまり、ここは讃岐君がきちんと責任を担保しなければならないことになります。

担保する、というのは、例えば仮に警察等から照会があった場合には
必要に応じてアクセスログを提出したり公開したりする必要が生じるし、
場合によっては裁判にも行かなきゃいけないかもしれないし、
あるいはもし必要になれば、必要に応じて各携帯キャリアに問い合わせたりして、
本当にその固有番号が捏造ではないことをきちんと証明する必要が生じたりする
可能性がある、等々、といったことです。

だらだらと書きましたが、つまり、２ちゃんねるから見た場合、

「s2ch.netからの書き込みは、すべて讃岐君の責任になります」

ということが、最大にして唯一のポイント、ということになるわけです。

もちろん讃岐君が「s2ch.net 経由でどのような内容が２ちゃんねるに書き込まれても、
私が全責任を負います」ということであれば、話は別です。

以上、root ★ としての個人的な意見。

(まだ続く)

で、「banana637 を又貸ししているいちお友達」としては、
ちょっとさすがに、そこまでの責任を讃岐君にかぶせちゃうのは、
とてもとても、気が進まなかったりします。

もしどこか違うところのサーバを借りてでもやりたい、ということであれば、
私はあえてそれを止めはしませんが、
自分が又貸しているサーバ上ではちょっと、、、って感じです。

で、ibis さんや jig さんは、事業として同様のサービスをされているので、
たぶんきっと、こういった体制や対策はきちんと考慮されていると思いますし、
ノウハウも数多く持たれているでしょう。
責任主体(会社)への連絡先等も明確ですし。


…といったわけで、オトナって、なんかムズカシイんですよ。きっと。

以上、ごめんなさいです。
でも、これからもがんがってくださいな、と。

讃岐さんに責任負わせた方が遊ばなくていいのでは？と思う。

お友達感覚かぁ。

s2chからの書き込みの犯罪予告はそれがs2chからのものであるか証明してまた讃岐さんに渡す作業が必要になるならば
2chのサービスの一つとしてその部分を讃岐さんが主導して行っているとしてroot▲氏の介入を許す必要があるのか。

ふむふむ。

>>643
わたしゃたんなる、おせっかいやきで。

例えば仮に、
管理人と讃岐君が(公式p2みたいな形で)アライアンス組むとかすれば、
その時はたんたんとやるだけです。はい。

技術的にはこのブラウザとか、どうやってるのかなとか。
↓
FOMA90x専用2chブラウザ 「W2Ch」 part3
http://hobby7.2ch.net/test/read.cgi/chakumelo/1146696612/

書き込みのたびにアプリ終了して書き込みするですよ。

>>645
なるほど、iMona (でしたっけ)とかと同じですか。

そうです。ドコモのは全部そんな感じです。

iMonaと基本的に変わらないかと。

読み込み･キャッシュ
書き込みフォームは中間鯖

主な中間鯖を必要とする理由は
1、パケ代節約
→定額制の導入により解消可
2、自作アプリは接続可能な鯖が3つ程度に限られている。
→例外的にvodafoneは制限無し
→FLASHは処理が遅く使い物にならない。

アプリから書き込み出来る物は接続可能な鯖にあらかじめ組み込んで特定の鯖だけだが書き込み出来るようにしたもののはず(^^;

当方C言語習得中なのですがコロンやらセミコロンつけすぎたり忘れたり複合演算子の順番間違えたりとまだまだどシロウトでプログラミングにビギナーズラックはないのだなぁとしみじみしてみたりと、ちらうらになってすいませんでした。

あちこち混乱してそうなので、ここに。

news20b、syslog 的には何のログも残ってないなぁ。
突然電源をバチンてされた感じ。

でも、ハングアップの時もそうなるから、わかんないなぁ。
リブート要請出したんでしたっけ。

瞬間的な電気トラブル？
電気工事で電圧が瞬間的に下がったとか。
変圧器機の切り替えによる瞬断とかな気がしますね。

しゅんだんなら、2時間とか止まらないと思うんですよね。
で、2時間ぐらいで(何もせずに)復旧したというのも解せないし。

というか、これから2週間ぐらいは天狗がたくさんいるので、
どのようなことも、正直起こりうるわけで。

あ、だったらみんな落ちるか。

ハードが悪いかもと私の勝手な憶測をしているとスレ汚しになるので撤退します。

あ、実はLANケーブルが二時間抜けていただけ。

>>653
サーバ自体は、リブートかかっているです。
ケーブルが抜けた旨のログもなしで。

【実況】　live23+24　Part19【新体制始動】
http://qb5.2ch.net/test/read.cgi/operate/1148046382/436

read.cgi だけ詰まったということか。

Apache status log を見る限り、httpd は売り切れになってないので、
影響はないはず、、、ですが、何かあったのかもしんないですね。

一度バックエンドをわざと止めて、実験してみる必要がありそう。

Benchmarking mpsafevfs with parallel tarball extraction
http://lists.freebsd.org/pipermail/freebsd-smp/2005-May/000792.html

> Kernel was built without INVARIANTS and other debugging options,
> without ADAPTIVE_GIANT (which causes about a 200% performance penalty
> on system time in my testing, and has marginal impact on real or user
> time)

options ADAPTIVE_GIANT # Giant mutex is adaptive.

は、ないほうがいいのかしら。

だいちくんの記事。32プロセッサか。
http://journal.mycom.co.jp/news/2006/05/22/014.html

例の貸し出しに応募してみる手もあるのかな。

>>657
これですね。前に質雑スレで振ったけど、反応がなかったのがむなしかった・・・・(涙)
http://jp.sun.com/promotions/trybuy/

>>638
ぶひー

>>659
http://aas.u.la/

次のステップへと。

aas.u.la

アース裏？

あーすら？あしゅら？

【amour】AASで携帯からも長編AAを楽しもう―Ascii Art Scope Part2
http://qb5.2ch.net/test/read.cgi/operate/1116860602/

>>655 snow.2ch.net あたりで NFS や reverse proxy も localhost 上でやってみるとか．

# ついでに，autopurge の ENOENT でないエラーの正体も突き止めたいところですが......

>>664
># ついでに，autopurge の ENOENT でないエラー(ry

これは，とりあえず単に "print" の一語だけ入れてもらえれば...... sage 復帰 CGI で
    bbsd($bbs, 'autopurge', 'hoge');
のようにやってる部分で
    print bbsd($bbs, 'autopurge', 'hoge');
にするだけでも，何が起こってるかわかるだろうと．

>>664-665
別途やってみるですか。

blackgoat4.2ch.net の panic:
そろそろ、6.1R にする時期か。

Dump header from device /dev/da0s1b
Architecture: i386
Architecture Version: 2
Dump Length: 2146500608B (2047 MB)
Blocksize: 512
Dumptime: Wed May 24 06:19:03 2006
Hostname: tiger512.maido3.com
Magic: FreeBSD Kernel Dump
Version String: FreeBSD 6.0-RELEASE-p4 #0: Tue May 16 02:33:11 PDT 2006
[email protected]:/var/src/sys/i386/compile/I386_TIGER_60_BLACKGOAT_NOPREEMPTION
Panic String: page fault
Dump Parity: 543720299
Bounds: 5
Dump Status: good

【365Main】 回線増速(ニュー速とかお引越しのご案内)
http://qb5.2ch.net/test/read.cgi/operate/1147078648/869

＊全サーバ＊、default gateway の変更が必要と。

206.223.146.xx ->2
206.223.147.xx ->2
206.223.148.xx ->2
206.223.149.xx ->2
206.223.150.xx ->2
206.223.151.xx ->2
206.223.152.xx ->2
206.223.153.xx -> 3 * this is the only one that is .3
206.223.154.xx -> 2
206.223.157.xx -> 2

なので、

・153 村だけ *.3
・他の村は *.2

に変更と。(ちなみに今は全部 *.1)

banana637 と tiger2526 で実験。

route コマンドに change があるから、リブートしなくても変えられそうね。
ほっ。

(tiger2526 の例)

% vi /etc/rc.conf

以下のように変更
#defaultrouter="206.223.157.1"
↓
defaultrouter="206.223.157.2"

% route change -net default 206.223.157.2

さて、ということで変更対象サーバが全部とわかったので、
root 権限ありサーバについては、こちらでたんたんと洗い出しをやっていこうと。

＜戦略＞

1) XO にないサーバは、移動日に変更を仕込む。
次にサーバがリブートしたら、設定が変わるようにする。

2) 既に XO にあるサーバは、ここでリストアップし、
たんたんと作業をすすめていく。

ということで、root 権限ありサーバのうち、既に XO にある(はずの)サーバのリスト:

cobra2244
cobra2245
cobra2247

banana307
banana402
banana403
banana404
banana405
banana406
banana2848

tiger503
tiger504
tiger507
tiger509
tiger510
tiger511
tiger512
tiger2507〜2512
tiger2513
tiger2514
tiger2522
tiger2523〜2525

stiger100〜stiger105 (未確認だが、いずれにせよ変更必要)

>>670 のリストを一部修正。

cobra2244
cobra2245
cobra2247

banana402
banana403
banana404
banana405
banana406
banana2848 ここまで済

tiger503
tiger504
tiger507
tiger510
tiger511
tiger512
tiger2507〜2512
tiger2513
tiger2514
tiger2522
tiger2523〜2525

2ｃｈの動作報告はここで。 パート19
http://qb5.2ch.net/test/read.cgi/operate/1140600013/888

>>672 の残りも作業完了。

>>669 のこれを、忘れないこと。

> 1) XO にないサーバは、移動日に変更を仕込む。
> 次にサーバがリブートしたら、設定が変わるようにする。

おつかれさまです

´∀｀）つ旦~~

検索していて、このスレに行き当たりました。

キャッシュ型負荷分散システム開発スレッド
http://pc8.2ch.net/test/read.cgi/unix/998908154/

このスレで Perler さんが開発されていた mirror.pl の最終版って、
どなたか、お持ちではないですかね。

# 上からちょっと拾い読みしてみましたが、いろんな意味で参考になるスレでした。

>>675
なんどかakiさん方が書き込んでいますね。
P2のakiさんかな？

ひっそりと 5.5R。
http://www.freebsd.org/releases/5.5R/announce.html

5系はこれで打ち止め。
ようやく通常の開発体制になるのかな。

(X-1)R はメンテナンスだけして、
(X)R を release & stable で開発して、
(X+1)R を -CURRENT でがんがると。

2.2.10ﾏﾀﾞｰ

【365Main】 回線増速(ニュー速とかお引越しのご案内) Part2
http://qb5.2ch.net/test/read.cgi/operate/1148497454/192-196

通信速度が十分出ないサーバがあったらしいとのこと。
(ifconfig 的には問題なくても、パフォーマンスが出なかったらしい)

ネットワーク機器の設定修正で直ったらしいですが、
100Mbps 接続の機器については、私のほうでもチェックを依頼されました。
ということでこれは別途。

これってもう設定しちゃってますか？

=========================================================================
http://qb5.2ch.net/test/read.cgi/operate/1121886018/841

841 名前：root▲ ★[sage] 投稿日：2006/02/13(月) 17:47:18 ID:???0 ?#
(略)
ということは、/etc/make.conf に、

# added by mumumu, for Apahce 2.2 -- 2006/2/13
USE_APACHE=common22

を追加でいいのかな。
=========================================================================


どうもこれはユーザーが設定するべきものではないみたいです
=========================================================================
http://pc8.2ch.net/test/read.cgi/unix/1140542841/589

589 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2006/03/15(水) 12:35:54
>584
うむ。
USE_* は、ports に依存関係を指定するための変数で、apache で言えば
USE_APACHE は、ports が Makefile 内で Apache のバージョンいくつが
必要かを明示するための変数であって、外から与えるものじゃない。

ports の要求に対してユーザが特定の apache を提示するには >576 のように
APACHE_PORT でどの apache ports を使用するかを教えてやるのが正しい。
しかも、>575 の common* って指定は、apache 本体の Makefile で指定する
値であって、mod_* などで指定するものではない。

ttp://lists.freebsd.org/mailman/htdig/freebsd-ports/2005-November/027182.html
=========================================================================

mod_○○とかのMakefile見ると、確かにそんな感じですし

>>680
あれこれ不具合が出て、既にやめているです。
報告がなくてごめん。

サーバダウン(鯖落ち）情報　part103
http://qb5.2ch.net/test/read.cgi/operate/1147529669/810

comic6 がうーむな状況らしい。
別途、対応で。

>>682 mogera が図らずもウィルスによるカキコをブロックしてる形なんですかね．
しかしそれが DoS になってしまうのは......バーボンがうまく効いてない？

>>683
きっとウイルスのコードが、そういうつくりなんでしょう。
つまり、異常終了すると無限ループになっちゃうとか。

>>684 バーボンは効いて httpd の段階で Deny できてるんですかね？
それなら仕方ない，っていうかそれに対処するとなると ipf レベルでって話になっちゃいますが．

>>685
たぶんね、まずは mod_authz_iplist あたりだと思うんですよ。

bbs.cgi再開発プロジェクト7
http://qb5.2ch.net/test/read.cgi/operate/1130918407/706

別途対応で。

CGI.pmって重くないですか？

書き込みバーボン(レス)は BBS を使ってるから、書き込みが成功しないと
読み込みバーボンまでDenyにならないといううわさがあるんですが、あれって改選したんですかね

△読み込みバーボンまで
○読み込みバーボンが発動するまで

>>688
comic6 と tmp6 は、両方とも今回の件で
ウイルスがバグってループになったっぽい気がしますね。
bbs.cgi 叩かれまくりか。

新しい環境でも書けているウイルスは存在するのかしら。

アンカーミスりました。>>688

>>688 については、CGI..pm は bbs.cgi の他の部分で既にロードして
使っていたりして。

>>691
>bbs.cgi 叩かれまくりか。

ってことは >>689 のように httpd 段階で Deny されてないってことですか．
まずはバーボン改良ですかね．

http://sabo2.kakiko.com/pageview/hourdata.cgi?date=20060527&server=comic6.2ch.net
を見ると、htmlが激しく叩かれているように見えますが、何か関係ありですか？

>>694
あまり関係ないっぽいです。

パソコンで人間ができてプログラムが出来ないようなこと
例えば連想とかを書き込みに入れられたらウイルスによる書き込み減るかも

>>696
それをいうなら画像でできた文字を入力するほうがいいだろ？

>>696-697
書き込み時Captcha（画像）認証制導入議論スレ
http://qb5.2ch.net/test/read.cgi/operate/1144071322/

SDｇｓｄｆ

とりあえず現在無限ループになってるのは，書き込めた“フリ”だけすればお引き取り願えるかな......
まぁどっちにしろ DoS 対策はしなきゃならんでしょうけど．

live23b = cobra2244 ダウンの件
疑うべきは、

電源問題
FreeBSD 6.1R + amd64 固有の問題 (news20b, live23b で起きている気がする)

あたりか。

フロントの Apache status を見ると、
フロントの httpd のコネクションが完全に詰まることは、避けられている模様。

フロントにログインして確認してみると、
F22, offlaw.cgi が刺さった状態になっている。
バックを NFS で参照している部分。

NFS の I/O 待ちになったものが、正しくタイムアウトしない様子。
df すると、刺さってしまうみたい。

read.cgi は、

例えば適当に、
http://live23.2ch.net/test/read.cgi/livecx/1111111111/

と入れると、詰まってしまう模様。

つまり、read.cgi 的にはうまく ProxyTimeout が働いていないっぽい。

http://live23.2ch.net/livecx/a/b/c/ とかは、すぐに 503 エラーになる模様。

GET /livecx/index.html HTTP/1.1
Host: live23.2ch.net

は、すぐにエラーがかえってくる。

つまり、ダウンを検出して「ダウンな状態」を
キャッシュしているように見える。

GET /バックにフォワードされる呪文 HTTP/1.1
Host: live23.2ch.net

もすぐに 503 になるので、>>705 と同じように検出はしている。

GET /test/read.cgi/livecx/1111111111/ HTTP/1.1
Host: live23.2ch.net

は、止まったままになる。（ううむ）

read.cgi は，ライブな dat が存在しないと過去ログ調べるのでは？
（つまり NFS でマウントされてるところ）

で，問題はその NFS なわけですが...... soft mount でも retrans とか timeout とか
そのあたり要調整ってことですかね．

>>708
なるほど、まさにそれですね。< NFS mount を調べる

read.cgi は、確かにそういうコードになっているです。
つまり、原因は同じか。

NFS の設定は、まだまだ調整が必要な予感。

ということで、>>701-709 のまとめとしては、

ProxyTimeout は、うまく動いているらしい。
で、いったんタイムアウトの状態になると、フロントは状況をある程度覚えるらしい。

Apache status を見ると、dat 直読み系はうまくタイムアウトしているので、
503 エラーになっている。(観測結果)

で、「覚える」までの間、たぶんぐぐぐと詰まるので、
一時的にフロントの httpd が満員になり、それで雪だるま全体が繋がりにくく
なったと考えられる。(これは推測)

「覚えた」あとは速攻でタイムアウトするので、現状では httpd の開きスロットは
ある程度確保されている。(観測結果)

NFS 系は、状況がまったく変わっていない。
つまり /etc/fstab に soft を追加しただけでは、何も変わらない。

別途他の調整を実行する必要ありということで。

ということで、ひととおりチェックしたいところは調べたので、
liveb1 の dat バックアップを固めて、
あとはたんたんとリブート要請へと。

>>712 done.

で、ここまでのチラシの裏リストの棚卸:

とりあえず >>600 あたりから。

・>>601-602

・>>615 kris の資料も置かれた模様。>>656 とかも参考に。

・>>618 の変更が 6.1R cobraダウンの原因っていう感じでもないみたい。
(ex14 は問題ないし)

・>>629-630 は問題なさげなのかな。

・バックエンドが落ちても、NFS が刺さらないようにする
>>633-635 あたり。fstab に書かずに直接 mount_nfs で試してみるか。

・Apache 的に SetEnv し、cgi でそれを参照する

・復帰の呪文の問題 (>>665)

・引越しに伴う default gateway の変更 (*.1 => *.2、153村は *.3)(>>667-668)
手順は >>669 だが、ping が通るなら先回りも。

・live23b/news20b がたまに落ちる(だまる)
>>649 でも落ちている(news20b)。しかも自分でリブートしたっぽい (>>650-652)
で、今日は live23b。

・>>679 の速度チェック
概ね問題なしという噂もありますが、一応。

・>>682 comic6 の問題(ウイルスのbbs.cgiへのDoSによる負荷)

続き

・>>687 クッキー問題
use CGI あたりで、ごにょごにょ。

以上、とりあえず。

【365Main】 回線増速(ニュー速とかお引越しのご案内) Part2
http://qb5.2ch.net/test/read.cgi/operate/1148497454/458

やっぱ、i386 と amd64 が活発なようですね。

最近では、big endian でも問題ないことや、
CPU が多くても(例えば14CPUとか)スケールすることの検証などに、
sparc64 も活用されているようです。