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

**root▲ ★** · NG

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

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

等を取り扱います。

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

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

**root▲ ★** · NG

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

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

**root▲ ★** · NG

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

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

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

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

ｵﾒ

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

**root▲ ★** · NG

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

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

**root▲ ★** · NG

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

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

**root▲ ★** · NG

**root▲ ★** · NG

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

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

**root▲ ★** · NG

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

ですが、

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

となっていた模様。

**root▲ ★** · NG

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

**root▲ ★** · NG

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

**root▲ ★** · NG

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

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

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

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

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

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

**root▲ ★** · NG

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

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

**root▲ ★** · NG

SYSCTL_INT ですか。

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

**root▲ ★** · NG

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

で、

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

が動きました。

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

**root▲ ★** · NG

topでみると:

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

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

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

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

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

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

**root▲ ★** · NG

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

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

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

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

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

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

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

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

**root▲ ★** · NG

>>22-23
なるほど。

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

**root▲ ★** · NG

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

にした。@ live22

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

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

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

**root▲ ★** · NG

>>26
ですね。

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

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

>>22

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

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

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

**root▲ ★** · NG

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

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

**root▲ ★** · NG

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

**root▲ ★** · NG

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

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

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

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

**root▲ ★** · NG

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

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

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

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

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

**root▲ ★** · NG

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

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

**root▲ ★** · NG

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

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

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

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

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

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

**root▲ ★** · NG

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

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

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

**root▲ ★** · NG

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

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

**root▲ ★** · NG

>>39
WBCの時ですね。

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

**root▲ ★** · NG

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 しても、何も出てこないし。

**root▲ ★** · NG

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

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

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

ですね。

**root▲ ★** · NG

>>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
(以下略)

**root▲ ★** · NG

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

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

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

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

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

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

**root▲ ★** · NG

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 を読めと。

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

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

お疲れさまでした。

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

株価【650】 ▲ ◆cZfSunOs.U · 2006/04/16(日) 10:19:07

乙でした．

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

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

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

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

**root▲ ★** · NG

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

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

**root▲ ★** · NG

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>

**root▲ ★** · 2006/04/17(月) 22:45:42

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

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

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

**root▲ ★** · 2006/04/17(月) 22:50:22

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

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

**root▲ ★** · NG

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

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

ううむ。

株価【666】 ▲ ◆cZfSunOs.U · 2006/04/17(月) 23:25:56

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

**root▲ ★** · NG

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

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

libthr とかかしら。

**root▲ ★** · NG

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

# 今日はもうだめぽ。

株価【666】 ▲ ◆cZfSunOs.U · 2006/04/17(月) 23:34:08

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

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

**root▲ ★** · NG

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

**root▲ ★** · NG

リブート入ったので、

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

に変更。 < ex14

**root▲ ★** · NG

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

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

**root▲ ★** · NG

で、
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 で動かすと、ちと危険かもですね。
やはり、もうちょっと減らそう。

株価【666】 ▲ ◆cZfSunOs.U · 2006/04/18(火) 00:00:30

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

**root▲ ★** · NG

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

こうしてみた。

**root▲ ★** · NG

>>64
ありえますね。

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/18(火) 18:11:36

GFSはないか、ないな

**root▲ ★** · 2006/04/18(火) 21:23:34

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

ううむ。

**root▲ ★** · 2006/04/18(火) 21:34:22

とりあえず、

# XXX
kern.maxvnodes=200000

にしてみた。@ live22

**root▲ ★** · NG

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

%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

**root▲ ★** · NG

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

%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

株価【600】 ▲ ◆cZfSunOs.U · 2006/04/18(火) 22:25:21

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

**root▲ ★** · NG

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

# XXX
CoreDumpDirectory /tmp

**root▲ ★** · NG

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.

うむむむ。

**root▲ ★** · NG

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

**root▲ ★** · NG

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

**root▲ ★** · NG

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

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

**root▲ ★** · NG

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

**root▲ ★** · NG

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

**root▲ ★** · NG

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

# 負荷が低いせいかも。

**動け動けウゴウゴ２ちゃんねる** · 2006/04/19(水) 00:19:26

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

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

**root▲ ★** · NG

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

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

株価【600】 ▲ ◆cZfSunOs.U · 2006/04/19(水) 00:23:17

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

**root▲ ★** · NG

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

**root▲ ★** · NG

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

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

**root▲ ★** · NG

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

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

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

**root▲ ★** · NG

@ 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

**root▲ ★** · NG

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

**root▲ ★** · NG

@ live22
/etc/exports: 設定。

**root▲ ★** · NG

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

**root▲ ★** · NG

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

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

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

**root▲ ★** · NG

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

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

かな。

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

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

◆SSu.zv/rvs · 2006/04/19(水) 04:31:06

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

**root▲ ★** · NG

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

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

**root▲ ★** · NG

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

**root▲ ★** · NG

>>95 done.

**動け動けウゴウゴ２ちゃんねる** · 2006/04/19(水) 04:43:12

|´･ω･)ゝ

◆SSu.zv/rvs · 2006/04/19(水) 04:44:38

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

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

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

**root▲ ★** · NG

>>98

はい。

[―{}@{}@{}-] ◆5/PMDV3/0o · NG

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/19(水) 06:30:31

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/19(水) 06:42:22

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/19(水) 10:06:16

>>96
つ　▲

▲ ◆SANUKI/VII · NG

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

**root▲ ★** · NG

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

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

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

◆XejmK2zG7E · 2006/04/19(水) 16:35:51

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

IPアドレス：210.153.93.58

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

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

宜しくお願い致します。

**root▲ ★** · NG

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

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

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

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

◆XejmK2zG7E · 2006/04/19(水) 16:59:45

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

**root▲ ★** · NG

あと、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

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

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

**root▲ ★** · NG

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

**root▲ ★** · NG

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

Willcom 版 jig ブラウザは、

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

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

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

**root▲ ★** · NG

お、ひょっとして、

> IPアドレス：210.153.93.58

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

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

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

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

**root▲ ★** · NG

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

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

◆XejmK2zG7E · 2006/04/19(水) 18:05:58

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

**root▲ ★** · NG

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

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

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

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

**root▲ ★** · NG

菊池様;

というわけで、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 になれば、実験は成功です。

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/19(水) 19:06:43

バーボンも端末個別？

**root▲ ★** · NG

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

**root▲ ★** · NG

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/19(水) 19:27:42

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

む P061198250129.ppp.prin.ne.jp · 2006/04/19(水) 19:48:09

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

◆XejmK2zG7E · 2006/04/19(水) 20:04:42

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/19(水) 21:13:35

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

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

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

**root▲ ★** · 2006/04/19(水) 21:45:23

StartServers 16
ServerLimit 16
ThreadLimit 128
ThreadsPerChild 128

に変更。(8/256から)

**root▲ ★** · 2006/04/19(水) 21:48:52

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

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

**root▲ ★** · 2006/04/19(水) 22:06:12

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

**root▲ ★** · 2006/04/19(水) 22:14:49

>>49
入れてみた。 @ live22

◆qb.x27/m96 · 2006/04/19(水) 22:15:41

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

**root▲ ★** · 2006/04/19(水) 22:22:27

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

kern.polling.burst_max=800 にした。

**root▲ ★** · 2006/04/19(水) 22:25:04

>>129
…ですね。

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

**root▲ ★** · 2006/04/19(水) 22:33:46

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

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/20(木) 09:17:30

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

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

**root▲ ★** · NG

/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)]
...
(続く)

**root▲ ★** · NG

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

うーむ。

**動け動けウゴウゴ２ちゃんねる** · 2006/04/20(木) 17:02:13

>>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 ?? ()

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

**root▲ ★** · NG

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

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

◆XejmK2zG7E · 2006/04/20(木) 17:39:19

株式会社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(ネイティブ）

宜しくお願い致します。

**root▲ ★** · NG

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

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

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

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/20(木) 19:02:56

>>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 の状態になっているスレッドはないでしょうか?
あったら、そのスレッドのスタックトレースを見てみると良いかも。。

**root▲ ★** · NG

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

これか。

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/20(木) 19:11:26

(gdb) thread 8
(gdb) where

です。

**root▲ ★** · NG

自分でも調べて、やってみたです。>>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)

**動け動けウゴウゴ２ちゃんねる** · 2006/04/20(木) 19:27:25

>>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 でコンパイルしないと、わかり難いんじゃないかなぁと個人的には思います。

**root▲ ★** · 2006/04/20(木) 20:50:11

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

**root▲ ★** · NG

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

load averages: 40.84, 53.78, 34.102

**root▲ ★** · NG

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

◆XejmK2zG7E · 2006/04/20(木) 21:02:42

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

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

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

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

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

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

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

宜しくお願い致します。

**root▲ ★** · NG

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.

**root▲ ★** · NG

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

**root▲ ★** · NG

これ (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

**root▲ ★** · NG

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

を追加。

**root▲ ★** · NG

net.inet.tcp.delayed_ack=0

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

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

**root▲ ★** · NG

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

を追加。

**root▲ ★** · NG

で、これらは、

%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 で通信)

**root▲ ★** · NG

【実況】　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

**root▲ ★** · NG

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

**root▲ ★** · NG

よく見てみたところ、

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をきちんと分けてもらえば、可能なのかしら。

**動け動けウゴウゴ２ちゃんねる** · 2006/04/21(金) 00:51:51

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/21(金) 01:00:32

あ、HUBの問題か。

**root▲ ★** · 2006/04/21(金) 02:03:24

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

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

**root▲ ★** · 2006/04/21(金) 11:07:28

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

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

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

**root▲ ★** · NG

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

**root▲ ★** · NG

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

なるほど。

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

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

**root▲ ★** · NG

> SunOS さん

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

**む＠携帯** · 2006/04/21(金) 21:45:46

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

む P221119009130.ppp.prin.ne.jp · 2006/04/21(金) 22:11:09

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

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

**root▲ ★** · NG

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

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

株価【650】 ▲ ◆cZfSunOs.U · 2006/04/21(金) 23:58:52

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

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/22(土) 00:04:29

thttpd

**動け動けウゴウゴ２ちゃんねる** · 2006/04/22(土) 00:05:32

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

**root▲ ★** · 2006/04/22(土) 00:59:26

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

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

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

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/22(土) 23:37:45

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

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

**root▲ ★** · NG

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

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

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

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

**root▲ ★** · NG

【 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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/23(日) 00:31:02

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

**root▲ ★** · NG

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

**root▲ ★** · NG

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

**root▲ ★** · NG

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

**root▲ ★** · NG

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

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

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

**root▲ ★** · NG

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

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

◆XejmK2zG7E · 2006/04/24(月) 11:26:21

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

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

宜しくお願い致します。

**動け動けウゴウゴ２ちゃんねる** · 2006/04/24(月) 11:35:56

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

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/24(月) 11:43:34

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

**root▲ ★** · NG

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

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

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

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

**root▲ ★** · NG

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

**root▲ ★** · NG

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

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/24(月) 17:39:39

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

**root▲ ★** · NG

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

**root▲ ★** · NG

#!/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

◆XejmK2zG7E · 2006/04/24(月) 18:48:02

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

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

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

**root▲ ★** · NG

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

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

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

**root▲ ★** · NG

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

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

**root▲ ★** · NG

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

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

株価【800】 ▲ ◆cZfSunOs.U · 2006/04/25(火) 02:00:31

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

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

**root▲ ★** · NG

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

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/25(火) 09:16:41

>>rootさん

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

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

◆XejmK2zG7E · 2006/04/25(火) 11:02:17

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

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

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

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

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

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

宜しくお願い致します。

**root▲ ★** · NG

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

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

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

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