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

**root▲ ★** · NG

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

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

等を取り扱います。

現在、複数サーバによる連携により、
サーバ能力のさらなるスケールアップをめざすための「雪だるま作戦」が進行中です。

また、次世代の携帯アクセス環境をめざした「べっかんこ作戦」も稼動しはじめました。
「２ちゃんねる証券取引所」や、「Be」の機能強化等、
２ちゃんねるは今日も変化し続けています。

前スレ:
2ch特化型サーバ・ロケーション構築作戦 Part19
http://qb5.2ch.net/test/read.cgi/operate/1121886018/

**root▲ ★** · NG

(zzz-matd-up.sh)
#!/bin/sh

_LIP="127.0.0.1"
_VIP="206.223.150.96"
_CFFILE="/usr/local/etc/matd.cf"
_CFFILE_SKEL="/usr/local/etc/matd.cf.skel"

ifconfig fxp0 $_VIP netmask 255.255.255.255 alias
sed -e "s/%%IPADDR%%/${_VIP}/" < $_CFFILE_SKEL > $_CFFILE
svc -h /var/service/matd

(zzz-matd-down.sh)
#!/bin/sh

_LIP="127.0.0.1"
_VIP="206.223.150.96"
_CFFILE="/usr/local/etc/matd.cf"
_CFFILE_SKEL="/usr/local/etc/matd.cf.skel"

sed -e "s/%%IPADDR%%/${_LIP}/" < $_CFFILE_SKEL > $_CFFILE
svc -h /var/service/matd
ifconfig fxp0 $_VIP delete

**root▲ ★** · NG

観察中、、、。
問題なさげなので、これでしばらく動かしてみるです。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/10(金) 02:28:23

>>391 乙でした。

http://www.freebsd.org/releases/6.1R/todo.html を
みると、とても3月中にリリースされるとは思えない状態ですね。

次は、mod_cacheですかね。

**root▲ ★** · NG

>>398
どもです。
ちょっと某所で聞いてみたんですが、どうも10日ぐらいはかかるっぽいみたいな。
でもとても出そうもない状態、というのもまぁ、いつものことっぽいらしいので、
見切り発車で出るのかもしんないですね。

うまく matd に乗せ換えられれば、フロントのメンテやバージョンアップも楽になります。
例えば mod_cache を入れた個体と入れない個体を準備しておくとかすれば、
テストもやりやすいのかなと。

株価【】 ▲ ◆cZfSunOs.U · 2006/03/10(金) 10:26:54

>>390-399 乙です．ucarp の README 見ると，

And last, but not least, you can use a script that will connect to your switches
and flush their ARP cache. Some users reported that transitions were way faster
when also switching MAC addresses.

ってことも書いてありますね．

**root▲ ★** · 2006/03/10(金) 11:12:55

>>400
なるほど、これは確かheartbeatでも使われているテクですね。

あと、VRRPで話すのに専用チャンネル(直結のところ)を使うとよさげなので、
おいおい、それにも挑戦してみるです。

**root▲ ★** · NG

信頼性を上げるため、相手方のチェックを直結I/Fに変更。

(banana403:/var/service/ucarp/run)
#!/bin/sh
exec 2>&1
exec env - TZ=JST-9 PATH="/usr/sbin:/sbin:/usr/bin:/bin:/usr/local/bin:/usr/local/sbin" \
ucarp --preempt --interface=vr0 \
--srcip=10.0.0.1 \
--vhid=1 --pass=むぎゅ \
--addr=206.223.150.96 \
--upscript=/usr/local/etc/zzz-matd-up.sh \
--downscript=/usr/local/etc/zzz-matd-down.sh \
--shutdown

(banana404:/var/service/ucarp/run)
#!/bin/sh
exec 2>&1
exec env - TZ=JST-9 PATH="/usr/sbin:/sbin:/usr/bin:/bin:/usr/local/bin:/usr/local/sbin" \
ucarp --preempt --interface=vr0 \
--srcip=10.0.0.2 \
--advskew=128 \
--vhid=1 --pass=むぎゅ \
--addr=206.223.150.96 \
--upscript=/usr/local/etc/zzz-matd-up.sh \
--downscript=/usr/local/etc/zzz-matd-down.sh \
--shutdown

**root▲ ★** · NG

>>395 を >>402 に変更。
リブートテスト良好。

これで、ほぼ理想的な姿になりました。< banana403/404
同時に働くことはできませんが、当初の目的は十分果たせたなと。

ここで思案のしどころですが、

1) 今 live22x も受付嬢に収容して実験する
2) 今日はこれで動かしてピークを越えられることを確認し、明日じっくりと

さて、どっち。↓

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

>>403
いきなり実験も2ch的で面白いですけど，rootさんのこと
考えると2の方がいいと思います……

**root▲ ★** · 2006/03/10(金) 19:10:22

バーチャルIPアドレスを変えて(例えば206.223.150.97)もう一組、
matd+ucarpのペアを動かして、
そっちはbanana404スタメン・banana403ピンチヒッターに設定して
動かすってのはどうだろうか。

**root▲ ★** · NG

>>405 は直感的にはよさげだけど、
いろんなことを考えると、一長一短かもしんないですね。

今の段階ではフォワーディング能力的には十分余裕なので、
そこまでする必要もなさそうですし。

**stream** ◆PNstream2s · NG

>>403
(1)

**root▲ ★** · NG

BG3/BG4、live22系と同じように /etc/libmap.conf を設定した。

マルチスレッドで動いている squid の効率が、少しでもよくなれば。

%cat /etc/libmap.conf
libpthread.so.2 libthr.so.2

**root▲ ★** · NG

とりあえずメモ

マスター側のリブートでは、まったく問題なし。
しかしバックアップ側をリブートすると、微妙なことが起こった。< ucarp

一瞬マスターモードになり、すぐにバックアップモードに。
で、その影響でちょっとの間マスターが2匹になり、www2がつながらなく。

バックアップ側は、--preempt をやめればいいのかな。

**root▲ ★** · NG

ついに掲示板サーバで(プライベート側だから圧縮なしだけど)、
1サーバの転送量だけで、トラフィックの32ビットカウンターがあふれる日がやってきた。

【ひなあられ】負荷監視所_20060301
http://live14.2ch.net/test/read.cgi/liveplus/1141207819/383

後で、雪だるま系のMRTGは別系統にする予定。

**root▲ ★** · NG

live22
httpd が signal 10 でダウン。

pid 41367 (httpd), uid 2001: exited on signal 10
pid 25496 (httpd), uid 2001: exited on signal 10
pid 25531 (httpd), uid 2001: exited on signal 10
pid 25484 (httpd), uid 2001: exited on signal 10
pid 25523 (httpd), uid 2001: exited on signal 10
pid 25488 (httpd), uid 2001: exited on signal 10
pid 25476 (httpd), uid 2001: exited on signal 10
pid 25475 (httpd), uid 2001: exited on signal 10
pid 25541 (httpd), uid 2001: exited on signal 10
pid 25520 (httpd), uid 2001: exited on signal 10
pid 25495 (httpd), uid 2001: exited on signal 10
pid 25527 (httpd), uid 2001: exited on signal 10
pid 25562 (httpd), uid 2001: exited on signal 10
pid 25535 (httpd), uid 2001: exited on signal 10
pid 25506 (httpd), uid 2001: exited on signal 10
pid 25533 (httpd), uid 2001: exited on signal 10

**root▲ ★** · NG

>>411 は、例の虫を踏んだ時ですね
libmap.conf 設定。

パッチあてて以降は、calcru: .. のメッセージは出なくなりました。

**root▲ ★** · 2006/03/11(土) 04:37:10

>>410
ということでlive22系のトラフィックだけ、別にとることにした。
http://mumumu.mu/mrtgs/mrtg-rrd.cgi/traffic/

**root▲ ★** · NG

live22x.2ch.net を matd (受付嬢)環境に移行します。

以下のDNSサーバの設定変更をよろしくお願いします。

(現在)
Clive22x.2ch.net:live22y.2ch.net:300

(変更後)
+live22x.2ch.net:206.223.150.96:300

株価【】 ▲ ◆cZfSunOs.U · 2006/03/11(土) 21:17:29

>>414 いよいよですか．

>>405 各仮想アドレスには DNS RR で割り振って，それぞれを ucarp で冗長化するって感じですか．
今後受付1台だけでは手に余るようになったら，その方向でってところですかね．

**root▲ ★** · 2006/03/12(日) 13:33:56

【実況】　live22x　Part13
http://qb5.2ch.net/test/read.cgi/operate/1141564207/397

(gdb) where
#0 0x283b04d3 in _umtx_op () from /lib/libc.so.6
#1 0x2836d066 in _thread_bp_death () from /usr/lib/libthr.so.2
#2 0x2836c5bd in pthread_cond_destroy () from /usr/lib/libthr.so.2
#3 0x28329a2d in apr_thread_cond_wait ()
from /usr/local/lib/apache2/libapr-0.so.9
#4 0x080688b7 in ap_queue_info_wait_for_idler ()
#5 0x080666bd in listener_thread ()
#6 0x283277e8 in dummy_worker () from /usr/local/lib/apache2/libapr-0.so.9
#7 0x2836c05d in pthread_create () from /usr/lib/libthr.so.2
#8 0x00000000 in ?? ()
(gdb)

前のと同じか。

**root▲ ★** · 2006/03/12(日) 13:49:06

サーバダウン(鯖落ち）情報　part95
http://qb5.2ch.net/test/read.cgi/operate/1141569018/918-924

ううむ。

**root▲ ★** · NG

BETA4 か。
今月中には、出ないっぽいかも。
http://www.freebsd.org/releases/6.1R/schedule.html

**動け動けウゴウゴ２ちゃんねる** · 2006/03/12(日) 23:37:20

一瞬今年中にみえますたw

**動け動けウゴウゴ２ちゃんねる** · 2006/03/13(月) 17:46:47

特化型サーバスレのこともたまには思い出してあげてください

◆TWARamEjuA · NG

つ http://search.cpan.org/~ingy/orz-0.10/lib/orz.pm

**root▲ ★** · NG

>>421
↓が最新みたいですが、これはいったい、、、。

http://search.cpan.org/~ingy/orz-0.11/lib/orz.pm

◆hikArinCL2 · 2006/03/13(月) 22:45:24

>>422
"use orz"から"no orz"までソースをコメントするAcme::的なモジュールです
0.10から0.11の変更点は"orz !!!"を"orz..."に変更しています

Module::Compileのお遊び的な使い方としてのモジュールでしょうね

**root▲ ★** · 2006/03/14(火) 00:05:54

>>423
なるほど、そういうものですか。

しかしなぜorz、、、。

◆TWARamEjuA · NG

今からでも間に合うかも！？
ttp://tokyo.yapcasia.org/blog/ja/sessions.html

**root▲ ★** · 2006/03/14(火) 10:25:25

>>425
おー、これは。

しかし、超いそがしい時期かも。

**ピロリ** · NG

>>414
done

**root▲ ★** · NG

>>427
正しく変わったのを確認しました。
特に問題は観察されていません。

これで、雪だるまシステムは「形として」、描いたとおりのものになりました。
構想から1年以上ですか。

あとは、より磨いていくことになります。

とりあえず、虫を踏まないようになってほしいとか、
フロントやバックを増やすにはもうちょっと作業が必要とか、
過去ログ関係とかをもっとスマートにやりたいなとかありますが、
このあたりは、例によってぼちぼちすすめていこうかなと。

**root▲ ★** · NG

で、本気モードでパケットが来た時に、matd がどうなるかということですね。

あとで matd.stats を外から見られるようにしておくか。

**root▲ ★** · NG

とりあえず、今の状態(matd.stats)。

[matd statistics] Tue, 14 Mar 2006 15:41:47.105 (JST)
user CPU time = 0:02:24.583, system CPU time = 0:20:11.934
elapsed time = 95:34:27.758, CPU load = 0.39%

minor page faults = 231, major page faults = 0, swaps = 0
block inputs = 0, block outputs = 0
messages sent = 2, messages received = 0
signals = 2, vol ctx switches = 32584418, invol ctx switches = 2811721

forwarded packets:
00:30:48:53:ec:20 = 47641159
00:30:48:83:ab:30 = 47656010
00:30:48:83:a6:2a = 47658945
elapsed time (configuration age) = 95:34:26.741

**root▲ ★** · NG

1:1 スレッド (-lthr) にしてから明らかに負荷が下がって、パフォーマンスが上がりました。

LA
http://mumumu.mu/mrtgc/mrtg-rrd.cgi/load/blackgoat4load.html
プライベート側のトラフィック(c-xxxxからの要求を処理できるようになった)
http://mumumu.mu/mrtgc/mrtg-rrd.cgi/traffic/blackgoat4-privatetraf.html

さて、どこまで延命できるのか。< BG3/4

**動け動けウゴウゴ２ちゃんねる** · 2006/03/14(火) 20:18:39

>>428
ということは雪だるま作戦プロジェクトはリリース版稼動開始ってことでよろしいのでしょうか。

**root▲ ★** · NG

>>432
実験はずっと続きますが、
ネットワークの形というか各サーバの論理構成(≠台数)としては、
メンバーがそろったという認識です。

・ロードバランサ(受付嬢: ユーザからの接続要求を各フロントに振り分ける)
・フロントエンド(ユーザからの要求の処理: bbs.cgi、read.cgi、削除系の呪文(未対応…)が動作)
・バックエンド(フロントエンドからの要求の処理: フロントにdat提供、実際の書き込み処理)

**root▲ ★** · NG

超簡便な図を描くと、今の構成こんなかんじ。

クライアントたち　Webブラウザとか専用ブラウザとかBG3/4とか
│　　　　　↑
↓　　　　　│
b1⇔b2　　│　　　ポイント: 帰りのトラフィックはb1(b2)を経由せず、x1～x3から直接届く
├┬┐　　│　　　b1が落ちるとb2に自動切換え、x1～x3が落ちると自動切り離し(未実装)
↓↓↓　　│
x1 x2 x3─┘　　各種cgiはここで動く
│││　　　　　　dat/index.html/subject.txt/subback.htmlはlive22から必要に応じてすぐもらう
│││　　　　　　SETTING.TXTやdat落ちした過去ログはlive22から定期的にゆっくりもらう
↓↓↓
live22　　　　　　　実際の書き込み処理を受けつける
　　　　　　　　　　　ここではcgiは動かない(今はまだ削除系cgiとかが動いている)
　　　　　　　　　　　x1～x3にdat/index.html/subject.txt/subback.htmlを提供する

Samba24やtimecount/timecloseのための規制系データは、
live22x1が上記のlive22の位置にいて、そこで一元管理
もし仮にlive22x1が落ちてもこれらの規制がスキップになるだけで、動作は継続

**root▲ ★** · NG

今の構成はlive22が落ちると全滅。

live22のところの冗長化・強化手段の例とか。

↓　　　　　　　　 ↑
B1⇔B2　　　　　│
├─┬─┐　　│　　　B1が落ちるとB2に自動切換え、SV1～SVnが落ちると自動切り離し
↓　 ↓　 ↓　　│
SV1 SV2 ... SVn┘
│　 │　 │
外部HDD　　　　　　　　　FC-AL等でSV1～SVnが外部HDDを共有
　　　　　　　　　　　　　　　HDDはRAID 5構成

**root▲ ★** · NG

昔やったおまじないを思い出したので、
banana403/banana404 の matd 起動スクリプトを nice してみた。
とりあえず WCPU がちょっぴり増えたので、それなりに動いているかなと。

苦しくなったら、BG3/4 の squid もやろうかと。

#!/bin/sh
exec 2>&1
exec env - TZ=JST-9 PATH="/usr/sbin:/usr/bin:/bin:/usr/local/bin" \
/usr/bin/nice -n -20 /usr/local/sbin/matd -F \
-f /usr/local/etc/matd.cf \
-s /var/log/matd.stats

**動け動けウゴウゴ２ちゃんねる** · 2006/03/14(火) 22:03:07

>>435
問題は冗長化通信部分の実装ですね
NFSがいまいちって前におっしゃってましたけど、クラサバどちらとも？それとも片方でしょかね？

**root▲ ★** · NG

>>437
同じ外部ストレージの中身を(FC-ALとかで)共有する路線かなと。

そうしておいて SV1 ～ SVn を並列で稼動できれば、
HDDのI/Oキャパが板一枚でいっぱいになるか(2chではありえないと思う)、
帰り側のネットワークがいっぱいになるまでは、スケールするんじゃないかなと。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/14(火) 22:22:23

>>438
そうなるとSumaみたいなのが必要になってくるわけですな・・・

**root▲ ★** · NG

>>439
そういうことになるですね。

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

>>440
前からきになっていたのですが、SumaってFCにつながっている
複数のサーバから同一ファイルをアクセスできるのですか？
箱物のみ共有で、ファイルの共有はできないと思っていたのですが。
(AppleのXsanみたいなソフトがサーバ側に必要と思っていました。)

**root▲ ★** · 2006/03/15(水) 01:31:12

>>441
なるほど、SV1でmountしたファイルシステムを
SV2からも普通にmountしようとすると、EBUSYとかになったりするのかしら。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/15(水) 02:06:07

>>442
普通は排他処理が働いて書き込みできないかと

リードオンリーならNFSマウントみたいな形で十分対処できますがね・・・
書き込みありだから何か工夫がいると思います

今までにrootさんがお守り修行で培ってきた経験が生かせるか、それとも新しい修行が必要かはわかりませんがね

**動け動けウゴウゴ２ちゃんねる** · 2006/03/15(水) 02:11:11

>>443
+ 普通のマウント方法だと排他処理が働いてマウントできないかもですね
- 普通は排他処理が働いて書き込みできないかと

**root▲ ★** · NG

質問・雑談スレ218＠運用情報板
http://qb5.2ch.net/test/read.cgi/operate/1142144559/347

うーむ、またこのエラーが。
Apache 2.2 + 64bit 版のみなのかなぁ。

>>443-444
ro で複数ホストから mount できるなら、読ませるほうを分担させることは可能かもですね。
書き込みは(とりあえず)1箇所でやることにして、読み出しを別のやつらに分業させるとか。

株価【】 ▲ ◆cZfSunOs.U · 2006/03/15(水) 11:16:11

とうとう matd 本格稼働ですか．とりあえず今のところ異常なしで一安心ですかね．

>>429
>で、本気モードでパケットが来た時に、matd がどうなるかということですね。

というのは確認しておきたいところですが．

で，>>435 >>438 というのはバック側をフェイルオーバだけじゃなく
ロードバランスするって意味ですか？そうなると......bbsd では
subject データなどをオンメモリ管理してるので，remote shared memory
とか使わないとつじつまが合わなくなってしまいますね．単一鯖の shared memory
でも処理が煩雑になるので，それを避けるためマルチプロセスでなく
シングルプロセスにしてるんですが．というか，単一鯖での bbsd の限界が来る前に
ユーザが追随できなくなりそうな気もしますが......今のところ最速 1000 は
4秒ですが，1スレを数秒で使い切るようなレス速度になれば，現実的には
次スレを探すのにある程度時間がかかるとか，一方みんながスレを立てようとすれば
スレ立て制限に引っかかるとか，そういう部分で必然的にブレーキがかかりそうな気もします．

ということで，bbsd についてはフェイルオーバだけ考えればいいのではないかと思います．
httpd の方は，フロント側で mod_cache を使ってもなお不足であればロードバランスも
考えた方がいいのかも知れませんけど．

pthread_cond_wait() が実行されるべきところで pthread_cond_destroy() が
実行されてしまうとか(>>416)，dlopen() or dlsym() が失敗してるらしいとか(>>445)，
このあたりは不可解ですね...... OS の虫なのか libapr が腐ってるのか......

**root▲ ★** · NG

>>446
> とうとう matd 本格稼働ですか．とりあえず今のところ異常なしで一安心ですかね．

ですね。
今実況が盛り上がっていますが、問題なく動作しています。

> ということで，bbsd についてはフェイルオーバだけ考えればいいのではないかと思います．

そですね。
そのほうが(= 書く人は一人にする)いろんな意味でよさそうなかんじ。

最終段落は、確かにってかんじかなと、、、。

ex14 (64bit) も Apache 2.0.55 ではこの現象は発生しなかったので、
apr 問題なのかもしれないですね。

**root▲ ★** · NG

【実況】　live22x　Part13
http://qb5.2ch.net/test/read.cgi/operate/1141564207/414

32bit でも発生。つまり、32bitか64bitかは無関係と。
Apache 2.0系では発生したことがないので、それ系か。

…Apache 2.2系でmod_cgidsoを作る時ですが、

gcc -c read.c -I`apxs -q INCLUDEDIR` `apr-1-config --includes` -O2 -Wall -funsigned-char -fPIC -o read.o
gcc -shared read.o `apr-1-config --link-ld` `apxs -q LIBS` -Wl,-S,-soname,read.so -o read.so

とやっていますが、これではだめとか、
あるいはApacheのほうで、

#if defined(AP_SERVER_MINORVERSION_NUMBER) && AP_SERVER_MINORVERSION_NUMBER >= 2
ap_filter_rec_t frec = {"READDAT", {rdat_filter}, NULL, AP_FTYPE_RESOURCE, NULL, NULL, 0, 0};
#else
ap_filter_rec_t frec = {"READDAT", {rdat_filter}, NULL, AP_FTYPE_RESOURCE, NULL};
#endif

に類似するような変更が、実は他にも存在しているのかとか。

# でもそれだと、途中からおかしくなる理屈が、、、。

**root▲ ★** · NG

今見たらex14でも再発していた。(httpd restart)
ううむ。

**root▲ ★** · NG

あとひょっとすると、libthr なコンディションの時だけ発生するのかな。
ex14で設定変えて試してみるか。

**root▲ ★** · NG

>>450 done.

**root▲ ★** · NG

libmap.conf を mv して、Apache をリスタートした。

今の ex14 の状況下なら、
数日この状況が再現しなかったら、libthr がらみな予感。

株価【】 ▲ ◆cZfSunOs.U · 2006/03/16(木) 16:03:12

>>448 そのあたりの理由だと，

># でもそれだと、途中からおかしくなる理屈が、、、。

ということで最初からおかしくなると思うんですよね......
となると，>>450 ですかね......

**動け動けウゴウゴ２ちゃんねる** · 2006/03/16(木) 17:29:59

libpthreadを使うんならこのスレッドにSTABLE向けだけどpatchあり。
http://lists.freebsd.org/pipermail/freebsd-threads/2006-March/003411.html

◆BFzK/mtqM2 · 2006/03/17(金) 00:45:16

eAccelerator 0.9.5-beta1　来ましたね。

**root▲ ★** · NG

>>454
さっき外から読んでました。
前に当てたパッチの延長線上のやつっぽいですね。
帰宅後に適用へと。

>>455
ふむふむ。

**root▲ ★** · 2006/03/17(金) 03:24:25

すみませんが今日はもう電池切れなので、
>>456 やepg のシングルスレッド(prefork MPM)化などは、あとで。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/17(金) 10:11:31

FreeBSDのdlopen() & dlclose()は完全にはスレッドセーフではないので、
mod_cgidsoはworkerだとうまく動かないと思います。。。
libthrよりlibpthreadの方が問題が起こり難いのは確かですが、
それでも問題が起こることは変わらず。

**root▲ ★** · NG

>>458
うーむ、、、。

で。メモメモ。

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

**root▲ ★** · NG

ずれたので、再度メモ。

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

株価【】 ▲ ◆cZfSunOs.U · 2006/03/17(金) 13:36:06

>>458 なるほど．Solaris 流に MT-Safe かと思ってましたが......
こんなのを httpd 起動時に LD_PRELOAD とかすれば何とかなるのかなぁ......？

#include <dlfcn.h>
#include <pthread.h>

static pthread_mutex_t dlmutex = PTHREAD_MUTEX_INITIALIZER;

void *dlopen(const char *pathname, int mode)
{
static union {
void *v;
dlfunc_t d;
void *(*f)(const char *, int);
} o_dlopen;
void *rv;

pthread_mutex_lock(&dlmutex);
if (!o_dlopen.v)
o_dlopen.d = dlfunc(RTLD_NEXT, "dlopen");
rv = o_dlopen.f(pathname, mode);
pthread_mutex_unlock(&dlmutex);
return rv;
}

int dlclose(void *handle)
{
static union {
void *v;
dlfunc_t d;
int (*f)(void *);
} o_dlclose;
int rv;

pthread_mutex_lock(&dlmutex);
if (!o_dlclose.v)
o_dlclose.d = dlfunc(RTLD_NEXT, "dlclose");
rv = o_dlclose.f(handle);
pthread_mutex_unlock(&dlmutex);
return rv;
}

void *dlsym(void *handle, const char *name)
{
static union {
void *v;
dlfunc_t d;
void *(*f)(void *, const char *);
} o_dlsym;
void *rv;

pthread_mutex_lock(&dlmutex);
if (!o_dlsym.v)
o_dlsym.d = dlfunc(RTLD_NEXT, "dlsym");
rv = o_dlsym.f(handle, name);
pthread_mutex_unlock(&dlmutex);
return rv;
}

**root▲ ★** · 2006/03/17(金) 13:52:35

http://people.freebsd.org/~bsd/prstats/topN_r_np_idx7

Problem Report threads/89262 : [kernel] [patch] multi-threaded process hangs in kernel in fork()
http://www.freebsd.org/cgi/query-pr.cgi?pr=89262

**root▲ ★** · 2006/03/17(金) 14:02:09

うーむうーむ。特にkern_fork.c.patch
http://people.freebsd.org/~davidxu/patch/?M=D
http://people.freebsd.org/~davidxu/patch/kern_fork.patch
http://people.freebsd.org/~davidxu/patch/calcru.patch
http://people.freebsd.org/~davidxu/patch/atfork.patch

**root▲ ★** · NG

ある携帯用アプリを作っている業者の担当さんから、
個人宛のメールで問い合わせが来ました。
以下は私からの返事の内容。

本件をすすめる件、およびその内容については管理人のOK済み。

--- cut ---

現在の２ちゃんねるでは、携帯端末から書き込み時に２ちゃんねるに送信される
固有情報により掲示板の荒らし対策、広告貼り付け対策等を実施しております
ので、これを送信いただくことは、このような場合における必須条件の一つです。

また、このような場合に最低限必要な情報/条件として、

1) ２ちゃんねるへの書き込みが行われる御社サーバのIPアドレス
(固定IPアドレスであることが必須: 複数個存在する場合それらのIPアドレス
全部)を、事前にお知らせいただき、かつ変更の都度お知らせいただくこと

なおこの情報は、2ch運用情報板 (http://qb5.2ch.net/operate/) への
御社ご担当様からの書き込みにより、公開の場でお伝えいただけると助かり
ます。
(例えば、技術情報そのものは御社Web上に別途準備いただき、
URLリンクや更新情報のみを都度書き込むといった形でも問題ありません)

上記情報を書き込むスレッドですが、

2ch特化型サーバ・ロケーション構築作戦 Part20
http://qb5.2ch.net/test/read.cgi/operate/1140540754/

をご使用いただけますと助かります。

2) 書き込みの際に、該当する携帯側のIPアドレス(携帯側から御社サーバに
書き込みリクエストがあった際の携帯側のIPアドレス)を、
一定の方法で２ちゃんねるにそのまま送信いただくこと

これにより２ちゃんねるは、どの会社の携帯電話からの書き込みであるか
を、携帯電話から直接書き込んだ場合と同様の方法で判定できることになり
ます。

なお、上記はIPアドレスの逆引き名ではなく、
IPアドレスそのものを送信いただけると助かります。

携帯電話の固有番号はキャリアごとに仕様・フォーマットが異なっているた
め、この情報が必要となります。

3) 書き込みの際に、該当する携帯の端末固有情報を
一定の方法で２ちゃんねるに送信いただくこと

理由は上記の通りとなります。

なお、上記 2) 3) につきましては、御社側において User-Agent: ヘッダに
挿入する方式(フォーマット)を明確に決めていただき、
この技術情報を 1) と同様、事前にお知らせいただけると助かります。

以上になります。よろしくお願いいたします。

**モーマン☆鯛。** · NG

ド○○ゴ？

**生姜焼き ★** · 2006/03/17(金) 18:47:18

jigではないかと推測

**モーマン☆鯛。** · NG

アッー！

**root▲ ★** · NG

>>463
日曜までに、live22 にこのへんのパッチをいくつか適用する予定。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/17(金) 20:15:05

live22xが重い重い状態というのは実際はどうなっているですかね。
なんかいろいろな話がでているので、まとめるとどうなんでしょ。

・何らかの原因(これがrootさんがいっている蟲？)でバックが
応答を返さなくなって、バックに問い合わせを行っている
フロントも詰まり、ユーザへの応答がない。この状態が重い重いで正しい？
(apache statusでみるとフロントもバックもフルスロット使用中？)

・フロントのloadが高くなるのは重い重いとは直接関係ない。
(dlopenのMT-unsafeのせい or PHPのせい or >>348 )

・バックはフロントみたいにloadが高くなることはない。
たくさんのアクセスがある際に固まるだけでほかは健康。

・暴走と蟲踏みは異なる事象
暴走はフロントのみ(アクセス数とは直接関係ない、
2.2にしてからおきている、prefork MPMだとOK?)
蟲踏みはバックのみ(アクセス数と関係しているかも
>>289の通りなのでカーネルが一番怪しい。)

順番に倒していかないと、発散しそうですね。

受付嬢はrootさん、SunOSさんの教育で問題ないようですし、

・フロントをガチと思われる
Apache 2.0.55 / prefork MPM + PHP 4.4.2 + libmap.conf (thr)
+ カーネルにcalcruのパッチ + >>247のパッチ
構成で固定して、バックだけいじっていく方向とか。
・フロントでmod_cacheを動かす、だめならsquidをあげて、バックへの
アクセスを減らし、バックの問題を先延ばす(6.1に期待)とか。

はどうですかね。

**root▲ ★** · NG

>>469

一番目
正しいです。

二番目
正しいです。

三番目
(今のところは)正しいです。
ただし、オリンピックの荒川静香金メダルの時は
live22x1でもバックと同じ症状が出たっぽいです。
フロントにもバックと同じ虫はいて、普段は発動していないだけと推測。

四番目
暴走はフロントのみ: 正しいです。
2.2 にしてから起きている: 2.2 + libthr にしてから起きています。
2.2 にしてからはprefork MPMを試していません。

最終段落は、そんなかんじですかね。
フロントは libthr にしなければいけないような状態では(今のところ)なさそうなので、
今 ex14 で試している Apache 2.2 + worker MPM + libpthread で暴走が起こらなければ、
libthr をやめて libpthread でいこうかなと。

フロントでsquid動かすですか。つまり、フロントとバックの間に入れるということですね。
悪くないセンスかも。

いずれにせよ、ひとつひとつというかんじで。

**root▲ ★** · NG

【実況】　live22x　Part13
http://qb5.2ch.net/test/read.cgi/operate/1141564207/664-667

原因切り分けも兼ねて、live22x[123] の /etc/libmap.conf を削除して
httpd をリスタート。

これで、
・不可解な 500 エラー
・不可解な httpd 暴走

が、起こらなくなることを期待。

株価【】 ▲ ◆cZfSunOs.U · 2006/03/17(金) 21:43:42

http://www.bookshelf.jp/texi/libtool/libtool-ja_10.html
>一方，`RTLD_NOW'は，FreeBSD上のマルチスレッドアプリケーションで問題が生じたと報告されています．

APR ではまさに RTLD_NOW で dlopen() してるわけですが......
それなら APR のソースをいじって RTLD_LAZY にしちゃってもいいのかも？

**動け動けウゴウゴ２ちゃんねる** · 2006/03/17(金) 22:46:17

458です。少し興味がわいたので、
>>461を参考にsrclib/apr/dso/unix/dso.cに修正をいれて、家のマシンでテストしてみました。
修正点は、dlopen()とdlclose()の呼び出し前後にmutexのlockとunlockを入れたことです。

環境:
FreeBSD 6.1-PRERELEASE i386 SMP
Apache 2.2.0 worker

テストに使用したソース:
ttp://sunos.saita.ma/mod_cgidso.c
ttp://sunos.saita.ma/dso-example.c

テスト方法:
リモートからabを使用して、対象のマシンに負荷をかける。

テスト結果:
srclib/apr/dso/unix/dso.cの修正前は、apacheが落ちまくって全然駄目だったが、
修正後は一度も落ちなかった。

なので、aprのソースをいじるのも悪くないかもしれません。

**473** · 2006/03/17(金) 22:49:53

書き忘れ。
libpthread, libthr どちらでも落ちませんでした。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/17(金) 22:56:36

>>474
diffかいてうｐしればroot先生が滝のような涙を流して?喜ぶでしょうw

**473** · 2006/03/17(金) 23:20:01

--- srclib/apr/dso/unix/dso.c.origSat Feb 5 05:44:01 2005
+++ srclib/apr/dso/unix/dso.cFri Mar 17 23:10:30 2006
@@ -38,6 +38,10 @@
#define DYLD_LIBRARY_HANDLE (void *)-1
#endif

+#if defined(__FreeBSD__)
+static pthread_mutex_t dlmutex = PTHREAD_MUTEX_INITIALIZER;
+#endif
+
APR_DECLARE(apr_status_t) apr_os_dso_handle_put(apr_dso_handle_t **aprdso,
apr_os_dso_handle_t osdso,
apr_pool_t *pool)
@@ -62,6 +66,9 @@
if (dso->handle == NULL)
return APR_SUCCESS;

+#if defined(__FreeBSD__)
+ pthread_mutex_lock(&dlmutex);
+#endif
#if defined(DSO_USE_SHL)
shl_unload((shl_t)dso->handle);
#elif defined(DSO_USE_DYLD)
@@ -69,8 +76,15 @@
NSUnLinkModule(dso->handle, FALSE);
}
#elif defined(DSO_USE_DLFCN)
- if (dlclose(dso->handle) != 0)
+ if (dlclose(dso->handle) != 0) {
+#if defined(__FreeBSD__)
+ pthread_mutex_unlock(&dlmutex);
+#endif
return APR_EINIT;
+ }
+#endif
+#if defined(__FreeBSD__)
+ pthread_mutex_unlock(&dlmutex);
#endif
dso->handle = NULL;

@@ -80,6 +94,9 @@
APR_DECLARE(apr_status_t) apr_dso_load(apr_dso_handle_t **res_handle,
const char *path, apr_pool_t *pool)
{
+#if defined(__FreeBSD__)
+ pthread_mutex_lock(&dlmutex);
+#endif
#if defined(DSO_USE_SHL)
shl_t os_handle = shl_load(path, BIND_IMMEDIATE, 0L);

@@ -139,6 +156,9 @@
os_handle = dlopen(path, flags);
#endif
#endif /* DSO_USE_x */
+#if defined(__FreeBSD__)
+ pthread_mutex_unlock(&dlmutex);
+#endif

*res_handle = apr_pcalloc(pool, sizeof(**res_handle));

**473** · 2006/03/17(金) 23:22:42

単純なものなので、こんな感じです。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/17(金) 23:46:00

>>464
http://hobby7.2ch.net/test/read.cgi/chakumelo/1138463191/846n-
個人宛だったのはユーザーの紹介があったせいか

**root▲ ★** · 2006/03/18(土) 01:15:26

早速、>>464 の件についてのお返事をいただきました。
ないようですが、

1) User-Agent: で、携帯側IPアドレスと端末固有番号の情報を送信いただける
2) User-Agent: のフォーマットが確定次第(メールで案をいただきました)、
先方のサーバのIPアドレス情報、User-Agent: 情報とともに、
このスレで要請いただける

とのことでした。

私のほうからは、
>
>DoCoMo の場合、User-Agent: の serXXXXXXXXXXXXXXX の内容をそのまま(serつきで)、
>au の場合、環境変数 HTTP_X_UP_SUBNO の内容をそのまま(.ezweb.ne.jpつきで)、
>Vodafone の場合、User-Agent: の SNxxxxxxxxxxx の内容をそのまま(SNつきで)、
>
>(User-Agent: の) 該当箇所に入れていただければ結構です。

という返事をしました。

**root▲ ★** · 2006/03/18(土) 01:15:57

ないようですが => 内容ですが >>479

**root▲ ★** · 2006/03/18(土) 01:18:34

>>473-478
おーーー。(滝のような涙)

さっそく、やってみるです。

**473** · 2006/03/18(土) 02:50:06

テストのついでに、パフォーマンスも測ってみました。

libpthread:

同時10接続:
Requests per second: 6057.67 [#/sec]
Requests per second: 6458.70 [#/sec]
Requests per second: 6447.04 [#/sec]

同時50接続:
Requests per second: 6264.09 [#/sec]
Requests per second: 6522.73 [#/sec]
Requests per second: 6425.50 [#/sec]

同時100接続:
Requests per second: 6016.12 [#/sec]
Requests per second: 6153.85 [#/sec]
Requests per second: 6473.33 [#/sec]

同時200接続:
Requests per second: 4890.93 [#/sec]
Requests per second: 5151.98 [#/sec]
Requests per second: 5119.80 [#/sec]

同時500接続:
Requests per second: 2134.06 [#/sec]
Requests per second: 2067.44 [#/sec]
Requests per second: 2041.40 [#/sec]

同時1000接続:
Requests per second: 1873.50 [#/sec]
Requests per second: 1823.15 [#/sec]
Requests per second: 1699.64 [#/sec]

**473** · 2006/03/18(土) 02:56:11

libthr:

同時10接続:
Requests per second: 6698.82 [#/sec]
Requests per second: 6330.32 [#/sec]
Requests per second: 6437.08 [#/sec]

同時50接続:
Requests per second: 6292.87 [#/sec]
Requests per second: 6405.33 [#/sec]
Requests per second: 6567.71 [#/sec]

同時100接続:
Requests per second: 6121.82 [#/sec]
Requests per second: 6424.67 [#/sec]
Requests per second: 6439.56 [#/sec]

同時200接続:
Requests per second: 5997.00 [#/sec]
Requests per second: 6238.30 [#/sec]
Requests per second: 6237.52 [#/sec]

同時500接続:
Requests per second: 5912.96 [#/sec]
Requests per second: 6272.74 [#/sec]
Requests per second: 6298.02 [#/sec]

同時1000接続:
Requests per second: 5775.01 [#/sec]
Requests per second: 6248.83 [#/sec]
Requests per second: 6208.48 [#/sec]

感想:
接続数が増えるとlibthrの圧勝。ほぼ性能低下なし。

**root▲ ★** · 2006/03/18(土) 04:02:30

>>462-463 と >>473 を、適用する予定。
でも今日は、もう眠くてだめ。
明日、某ラウンジから作業するか。

>>483
やはり libthr の方が同時接続をこなす(本来の目的)意味でも、
有効ということですか。

携帯バックエンドサーバのsquid(blackgoat3/4)でも、
libpthread から libthr に変えたら、すごく軽くなりました。
前はプライベート側が200Mbpsぐらいで頭打ちだったんですが、
今は250Mbpsいっても、軽々とこなしているです。

**473** · 2006/03/18(土) 04:06:52

すいません。補足です。
上記の測定は
ThreadLimit 1000
StartServers 1
MaxClients 1000
MinSpareThreads 1000
MaxSpareThreads 1000
ThreadsPerChild 1000
MaxRequestsPerChild 0
の設定でやったんですが、
ThreadLimit 100
StartServers 10
MaxClients 1000
MinSpareThreads 1000
MaxSpareThreads 1000
ThreadsPerChild 100
MaxRequestsPerChild 0
の設定だと
------------------------------------------
同時1000接続:

libpthread:
Requests per second: 6436.25 [#/sec]
Requests per second: 6309.15 [#/sec]
Requests per second: 6432.94 [#/sec]

libthr:
Requests per second: 6170.55 [#/sec]
Requests per second: 6172.46 [#/sec]
Requests per second: 6192.72 [#/sec]
------------------------------------------
という感じでした。
なので、同時接続というより、1プロセスあたりのスレッド数が多くなると
libthrの方が強いという感じでしょうか。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/18(土) 11:47:21

一件落着？

うらやましいな。回線太くて。

でもうちの鯖FC5で僕の携帯のためにアップデートの処理落ち以外はがんがってます。

[―{}@{}@{}-] **root▲ ★** · NG

live22 の Apache に、まずは >>476 を適用。

こんなかんじで、うまくいったっぽい。

in /usr/ports/www/apache22:
ftp://ftp.peko.2ch.net/pub/patch/apache22/Makefile.local
in /usr/ports/distfiles:
ftp://ftp.peko.2ch.net/pub/patch/apache22/apache-2.2.0-dso.c-freebsd6.0.patch

[―{}@{}@{}-] **root▲ ★** · NG

% nm libapr-1.a
...
dso.o:
U apr_cpystrn
000001b0 T apr_dso_error
000000c0 T apr_dso_load
00000174 T apr_dso_sym
0000015c T apr_dso_unload
00000044 T apr_os_dso_handle_get
00000000 T apr_os_dso_handle_put
U apr_palloc
U apr_pool_cleanup_null
U apr_pool_cleanup_register
U apr_pool_cleanup_run
U dlclose
U dlerror
00000000 b dlmutex
U dlopen
U dlsym
00000058 t dso_cleanup
U pthread_mutex_lock
U pthread_mutex_unlock

[―{}@{}@{}-] **root▲ ★** · NG

>>487 は、Apache 2.2 なサーバ全部に適用しようかと。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/18(土) 17:17:28

>>464,479-780 の件でお邪魔しております。
株式会社アイビスモバイル事業部担当の西村です。

現行サービスを行っている ibisBrowserDX から
２ちゃんねるへの書き込みを行うに当たって、技術情報を公開します。

アクセスを行うIPアドレス：　219.117.203.9

書き込みを行うにあたって、一時的に付与するUser-Agent：

Mozilla/4.0 (compatible; ibisBrowser; IPアドレス; ser端末固定番号)

　例：
　Mozilla/4.0 (compatible; ibisBrowser; 219.117.203.9; ser0123456789ABCDEF)

サービスによって、上記User-Agent以外が存在しますが、その場合は書き込みの拒否をお願いいたします。
今後ともよろしくお願い申し上げます。

◆Cathy/YQLs · 2006/03/18(土) 17:39:03

DX版以外は書き込みできないようにってことですかな

◆TWARamEjuA · NG

となるとBBQ除外指定になるのかな？＠現在規制中のもより

**焼きうどん ★** · NG

串規制ってといたほうがいいのかしら？

公式p2はbooでも書ける(be除く)から解除しなくても大丈夫かしら？

**焼きうどん ★** · NG

ちょっとおそかった。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/18(土) 17:50:15

>>490
書き込みできない条件は
　・DX版でない場合
　・書き込む手前で端末情報の送信にたいする同意を拒否した場合
　・状況を想定しておりませんが、2ch外から2chに書き込んだ場合
を考えております。

>>491
現在、BBQ指定となっております。
ただ、上記条件に当たる人も同一IPを用いるため、
User-Agentで弾くというのが良いかどうかの判断はお任せいたします。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/18(土) 18:00:26

アプリ上で書き込み毎に端末情報を発信するかしないかダイアログ出せるのかなー？