2ch特化型サーバ・ロケーション構築作戦のスレッドです。
・2ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更まわりの関連作業・調整事項
・2ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携
等を取り扱います。
現在、複数サーバによる連携により、
サーバ能力のさらなるスケールアップをめざすための「雪だるま作戦」が進行中です。
また、次世代の携帯アクセス環境をめざした「べっかんこ作戦」も稼動しはじめました。
「2ちゃんねる証券取引所」や、「Be」の機能強化等、
2ちゃんねるは今日も変化し続けています。
前スレ:
2ch特化型サーバ・ロケーション構築作戦 Part19
http://qb5.2ch.net/test/read.cgi/operate/1121886018/
探検
2ch特化型サーバ・ロケーション構築作戦 Part20
■ このスレッドは過去ログ倉庫に格納されています
1root▲ ★
NGNG418root▲ ★
NGNG2006/03/12(日) 23:37:20ID:iiVdso7J0
一瞬今年中にみえますたw
2006/03/13(月) 17:46:47ID:u14MvpfC0
特化型サーバスレのこともたまには思い出してあげてください
つ http://search.cpan.org/~ingy/orz-0.10/lib/orz.pm
422root▲ ★
NGNG >>422
"use orz"から"no orz"までソースをコメントするAcme::的なモジュールです
0.10から0.11の変更点は"orz !!!"を"orz..."に変更しています
Module::Compileのお遊び的な使い方としてのモジュールでしょうね
"use orz"から"no orz"までソースをコメントするAcme::的なモジュールです
0.10から0.11の変更点は"orz !!!"を"orz..."に変更しています
Module::Compileのお遊び的な使い方としてのモジュールでしょうね
428root▲ ★
NGNG >>427
正しく変わったのを確認しました。
特に問題は観察されていません。
これで、雪だるまシステムは「形として」、描いたとおりのものになりました。
構想から1年以上ですか。
あとは、より磨いていくことになります。
とりあえず、虫を踏まないようになってほしいとか、
フロントやバックを増やすにはもうちょっと作業が必要とか、
過去ログ関係とかをもっとスマートにやりたいなとかありますが、
このあたりは、例によってぼちぼちすすめていこうかなと。
正しく変わったのを確認しました。
特に問題は観察されていません。
これで、雪だるまシステムは「形として」、描いたとおりのものになりました。
構想から1年以上ですか。
あとは、より磨いていくことになります。
とりあえず、虫を踏まないようになってほしいとか、
フロントやバックを増やすにはもうちょっと作業が必要とか、
過去ログ関係とかをもっとスマートにやりたいなとかありますが、
このあたりは、例によってぼちぼちすすめていこうかなと。
429root▲ ★
NGNG で、本気モードでパケットが来た時に、matd がどうなるかということですね。
あとで matd.stats を外から見られるようにしておくか。
あとで matd.stats を外から見られるようにしておくか。
430root▲ ★
NGNG とりあえず、今の状態(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
[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
431root▲ ★
NGNG 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
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:39ID:WjY6I8pQ0
>>428
ということは雪だるま作戦プロジェクトはリリース版稼動開始ってことでよろしいのでしょうか。
ということは雪だるま作戦プロジェクトはリリース版稼動開始ってことでよろしいのでしょうか。
433root▲ ★
NGNG >>432
実験はずっと続きますが、
ネットワークの形というか各サーバの論理構成(≠台数)としては、
メンバーがそろったという認識です。
・ロードバランサ(受付嬢: ユーザからの接続要求を各フロントに振り分ける)
・フロントエンド(ユーザからの要求の処理: bbs.cgi、read.cgi、削除系の呪文(未対応…)が動作)
・バックエンド(フロントエンドからの要求の処理: フロントにdat提供、実際の書き込み処理)
実験はずっと続きますが、
ネットワークの形というか各サーバの論理構成(≠台数)としては、
メンバーがそろったという認識です。
・ロードバランサ(受付嬢: ユーザからの接続要求を各フロントに振り分ける)
・フロントエンド(ユーザからの要求の処理: bbs.cgi、read.cgi、削除系の呪文(未対応…)が動作)
・バックエンド(フロントエンドからの要求の処理: フロントにdat提供、実際の書き込み処理)
434root▲ ★
NGNG 超簡便な図を描くと、今の構成こんなかんじ。
クライアントたち 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が落ちてもこれらの規制がスキップになるだけで、動作は継続
クライアントたち 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が落ちてもこれらの規制がスキップになるだけで、動作は継続
435root▲ ★
NGNG 今の構成はlive22が落ちると全滅。
live22のところの冗長化・強化手段の例とか。
↓ ↑
B1⇔B2 │
├─┬─┐ │ B1が落ちるとB2に自動切換え、SV1〜SVnが落ちると自動切り離し
↓ ↓ ↓ │
SV1 SV2 ... SVn┘
│ │ │
外部HDD FC-AL等でSV1〜SVnが外部HDDを共有
HDDはRAID 5構成
live22のところの冗長化・強化手段の例とか。
↓ ↑
B1⇔B2 │
├─┬─┐ │ B1が落ちるとB2に自動切換え、SV1〜SVnが落ちると自動切り離し
↓ ↓ ↓ │
SV1 SV2 ... SVn┘
│ │ │
外部HDD FC-AL等でSV1〜SVnが外部HDDを共有
HDDはRAID 5構成
436root▲ ★
NGNG 昔やったおまじないを思い出したので、
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
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:07ID:WjY6I8pQ0
438root▲ ★
NGNG >>437
同じ外部ストレージの中身を(FC-ALとかで)共有する路線かなと。
そうしておいて SV1 〜 SVn を並列で稼動できれば、
HDDのI/Oキャパが板一枚でいっぱいになるか(2chではありえないと思う)、
帰り側のネットワークがいっぱいになるまでは、スケールするんじゃないかなと。
同じ外部ストレージの中身を(FC-ALとかで)共有する路線かなと。
そうしておいて SV1 〜 SVn を並列で稼動できれば、
HDDのI/Oキャパが板一枚でいっぱいになるか(2chではありえないと思う)、
帰り側のネットワークがいっぱいになるまでは、スケールするんじゃないかなと。
2006/03/14(火) 22:22:23ID:WjY6I8pQ0
>>438
そうなるとSumaみたいなのが必要になってくるわけですな・・・
そうなるとSumaみたいなのが必要になってくるわけですな・・・
2006/03/15(水) 00:04:21ID:zGV61Xb10
>>440
前からきになっていたのですが、SumaってFCにつながっている
複数のサーバから同一ファイルをアクセスできるのですか?
箱物のみ共有で、ファイルの共有はできないと思っていたのですが。
(AppleのXsanみたいなソフトがサーバ側に必要と思っていました。)
前からきになっていたのですが、SumaってFCにつながっている
複数のサーバから同一ファイルをアクセスできるのですか?
箱物のみ共有で、ファイルの共有はできないと思っていたのですが。
(AppleのXsanみたいなソフトがサーバ側に必要と思っていました。)
442root▲ ★
2006/03/15(水) 01:31:12ID:???02006/03/15(水) 02:06:07ID:wQ/ASUE00
>>442
普通は排他処理が働いて書き込みできないかと
リードオンリーならNFSマウントみたいな形で十分対処できますがね・・・
書き込みありだから何か工夫がいると思います
今までにrootさんがお守り修行で培ってきた経験が生かせるか、それとも新しい修行が必要かはわかりませんがね
普通は排他処理が働いて書き込みできないかと
リードオンリーならNFSマウントみたいな形で十分対処できますがね・・・
書き込みありだから何か工夫がいると思います
今までにrootさんがお守り修行で培ってきた経験が生かせるか、それとも新しい修行が必要かはわかりませんがね
2006/03/15(水) 02:11:11ID:wQ/ASUE00
445root▲ ★
NGNG 質問・雑談スレ218@運用情報板
http://qb5.2ch.net/test/read.cgi/operate/1142144559/347
うーむ、またこのエラーが。
Apache 2.2 + 64bit 版のみなのかなぁ。
>>443-444
ro で複数ホストから mount できるなら、読ませるほうを分担させることは可能かもですね。
書き込みは(とりあえず)1箇所でやることにして、読み出しを別のやつらに分業させるとか。
http://qb5.2ch.net/test/read.cgi/operate/1142144559/347
うーむ、またこのエラーが。
Apache 2.2 + 64bit 版のみなのかなぁ。
>>443-444
ro で複数ホストから mount できるなら、読ませるほうを分担させることは可能かもですね。
書き込みは(とりあえず)1箇所でやることにして、読み出しを別のやつらに分業させるとか。
とうとう 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 が腐ってるのか......
>>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 が腐ってるのか......
447root▲ ★
NGNG >>446
> とうとう matd 本格稼働ですか.とりあえず今のところ異常なしで一安心ですかね.
ですね。
今実況が盛り上がっていますが、問題なく動作しています。
> ということで,bbsd についてはフェイルオーバだけ考えればいいのではないかと思います.
そですね。
そのほうが(= 書く人は一人にする)いろんな意味でよさそうなかんじ。
最終段落は、確かにってかんじかなと、、、。
ex14 (64bit) も Apache 2.0.55 ではこの現象は発生しなかったので、
apr 問題なのかもしれないですね。
> とうとう matd 本格稼働ですか.とりあえず今のところ異常なしで一安心ですかね.
ですね。
今実況が盛り上がっていますが、問題なく動作しています。
> ということで,bbsd についてはフェイルオーバだけ考えればいいのではないかと思います.
そですね。
そのほうが(= 書く人は一人にする)いろんな意味でよさそうなかんじ。
最終段落は、確かにってかんじかなと、、、。
ex14 (64bit) も Apache 2.0.55 ではこの現象は発生しなかったので、
apr 問題なのかもしれないですね。
448root▲ ★
NGNG 【実況】 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
に類似するような変更が、実は他にも存在しているのかとか。
# でもそれだと、途中からおかしくなる理屈が、、、。
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
に類似するような変更が、実は他にも存在しているのかとか。
# でもそれだと、途中からおかしくなる理屈が、、、。
449root▲ ★
NGNG 今見たらex14でも再発していた。(httpd restart)
ううむ。
ううむ。
450root▲ ★
NGNG あとひょっとすると、libthr なコンディションの時だけ発生するのかな。
ex14で設定変えて試してみるか。
ex14で設定変えて試してみるか。
452root▲ ★
NGNG libmap.conf を mv して、Apache をリスタートした。
今の ex14 の状況下なら、
数日この状況が再現しなかったら、libthr がらみな予感。
今の ex14 の状況下なら、
数日この状況が再現しなかったら、libthr がらみな予感。
2006/03/16(木) 17:29:59ID:gi0mOC860
libpthreadを使うんならこのスレッドにSTABLE向けだけどpatchあり。
http://lists.freebsd.org/pipermail/freebsd-threads/2006-March/003411.html
http://lists.freebsd.org/pipermail/freebsd-threads/2006-March/003411.html
457root▲ ★
2006/03/17(金) 03:24:25ID:???0 すみませんが今日はもう電池切れなので、
>>456 やepg のシングルスレッド(prefork MPM)化などは、あとで。
>>456 やepg のシングルスレッド(prefork MPM)化などは、あとで。
2006/03/17(金) 10:11:31ID:pvQ2ZSVI0
FreeBSDのdlopen() & dlclose()は完全にはスレッドセーフではないので、
mod_cgidsoはworkerだとうまく動かないと思います。。。
libthrよりlibpthreadの方が問題が起こり難いのは確かですが、
それでも問題が起こることは変わらず。
mod_cgidsoはworkerだとうまく動かないと思います。。。
libthrよりlibpthreadの方が問題が起こり難いのは確かですが、
それでも問題が起こることは変わらず。
459root▲ ★
NGNG >>458
うーむ、、、。
で。メモメモ。
p2.2ch.net不具合報告スレ Part10
http://qb5.2ch.net/test/read.cgi/operate/1141521195/214
うーむ、、、。
で。メモメモ。
p2.2ch.net不具合報告スレ Part10
http://qb5.2ch.net/test/read.cgi/operate/1141521195/214
460root▲ ★
NGNG >>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;
}
こんなのを 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;
}
462root▲ ★
2006/03/17(金) 13:52:35ID:???0 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
Problem Report threads/89262 : [kernel] [patch] multi-threaded process hangs in kernel in fork()
http://www.freebsd.org/cgi/query-pr.cgi?pr=89262
463root▲ ★
2006/03/17(金) 14:02:09ID:???0 うーむうーむ。特に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
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
464root▲ ★
NGNG ある携帯用アプリを作っている業者の担当さんから、
個人宛のメールで問い合わせが来ました。
以下は私からの返事の内容。
本件をすすめる件、およびその内容については管理人のOK済み。
--- cut ---
現在の2ちゃんねるでは、携帯端末から書き込み時に2ちゃんねるに送信される
固有情報により掲示板の荒らし対策、広告貼り付け対策等を実施しております
ので、これを送信いただくことは、このような場合における必須条件の一つです。
また、このような場合に最低限必要な情報/条件として、
1) 2ちゃんねるへの書き込みが行われる御社サーバの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アドレス)を、
一定の方法で2ちゃんねるにそのまま送信いただくこと
これにより2ちゃんねるは、どの会社の携帯電話からの書き込みであるか
を、携帯電話から直接書き込んだ場合と同様の方法で判定できることになり
ます。
なお、上記はIPアドレスの逆引き名ではなく、
IPアドレスそのものを送信いただけると助かります。
携帯電話の固有番号はキャリアごとに仕様・フォーマットが異なっているた
め、この情報が必要となります。
3) 書き込みの際に、該当する携帯の端末固有情報を
一定の方法で2ちゃんねるに送信いただくこと
理由は上記の通りとなります。
なお、上記 2) 3) につきましては、御社側において User-Agent: ヘッダに
挿入する方式(フォーマット)を明確に決めていただき、
この技術情報を 1) と同様、事前にお知らせいただけると助かります。
以上になります。よろしくお願いいたします。
個人宛のメールで問い合わせが来ました。
以下は私からの返事の内容。
本件をすすめる件、およびその内容については管理人のOK済み。
--- cut ---
現在の2ちゃんねるでは、携帯端末から書き込み時に2ちゃんねるに送信される
固有情報により掲示板の荒らし対策、広告貼り付け対策等を実施しております
ので、これを送信いただくことは、このような場合における必須条件の一つです。
また、このような場合に最低限必要な情報/条件として、
1) 2ちゃんねるへの書き込みが行われる御社サーバの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アドレス)を、
一定の方法で2ちゃんねるにそのまま送信いただくこと
これにより2ちゃんねるは、どの会社の携帯電話からの書き込みであるか
を、携帯電話から直接書き込んだ場合と同様の方法で判定できることになり
ます。
なお、上記はIPアドレスの逆引き名ではなく、
IPアドレスそのものを送信いただけると助かります。
携帯電話の固有番号はキャリアごとに仕様・フォーマットが異なっているた
め、この情報が必要となります。
3) 書き込みの際に、該当する携帯の端末固有情報を
一定の方法で2ちゃんねるに送信いただくこと
理由は上記の通りとなります。
なお、上記 2) 3) につきましては、御社側において User-Agent: ヘッダに
挿入する方式(フォーマット)を明確に決めていただき、
この技術情報を 1) と同様、事前にお知らせいただけると助かります。
以上になります。よろしくお願いいたします。
465モーマン☆鯛。
NGNG ド○○ゴ?
466生姜焼き ★
2006/03/17(金) 18:47:18ID:???0 jigではないかと推測
467モーマン☆鯛。
NGNG アッー!
2006/03/17(金) 20:15:05ID:uM3QytbS0
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さんがいっている蟲?)でバックが
応答を返さなくなって、バックに問い合わせを行っている
フロントも詰まり、ユーザへの応答がない。この状態が重い重いで正しい?
(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に期待)とか。
はどうですかね。
470root▲ ★
NGNG >>469
一番目
正しいです。
二番目
正しいです。
三番目
(今のところは)正しいです。
ただし、オリンピックの荒川静香金メダルの時は
live22x1でもバックと同じ症状が出たっぽいです。
フロントにもバックと同じ虫はいて、普段は発動していないだけと推測。
四番目
暴走はフロントのみ: 正しいです。
2.2 にしてから起きている: 2.2 + libthr にしてから起きています。
2.2 にしてからはprefork MPMを試していません。
最終段落は、そんなかんじですかね。
フロントは libthr にしなければいけないような状態では(今のところ)なさそうなので、
今 ex14 で試している Apache 2.2 + worker MPM + libpthread で暴走が起こらなければ、
libthr をやめて libpthread でいこうかなと。
フロントでsquid動かすですか。つまり、フロントとバックの間に入れるということですね。
悪くないセンスかも。
いずれにせよ、ひとつひとつというかんじで。
一番目
正しいです。
二番目
正しいです。
三番目
(今のところは)正しいです。
ただし、オリンピックの荒川静香金メダルの時は
live22x1でもバックと同じ症状が出たっぽいです。
フロントにもバックと同じ虫はいて、普段は発動していないだけと推測。
四番目
暴走はフロントのみ: 正しいです。
2.2 にしてから起きている: 2.2 + libthr にしてから起きています。
2.2 にしてからはprefork MPMを試していません。
最終段落は、そんなかんじですかね。
フロントは libthr にしなければいけないような状態では(今のところ)なさそうなので、
今 ex14 で試している Apache 2.2 + worker MPM + libpthread で暴走が起こらなければ、
libthr をやめて libpthread でいこうかなと。
フロントでsquid動かすですか。つまり、フロントとバックの間に入れるということですね。
悪くないセンスかも。
いずれにせよ、ひとつひとつというかんじで。
471root▲ ★
NGNG 【実況】 live22x Part13
http://qb5.2ch.net/test/read.cgi/operate/1141564207/664-667
原因切り分けも兼ねて、live22x[123] の /etc/libmap.conf を削除して
httpd をリスタート。
これで、
・不可解な 500 エラー
・不可解な httpd 暴走
が、起こらなくなることを期待。
http://qb5.2ch.net/test/read.cgi/operate/1141564207/664-667
原因切り分けも兼ねて、live22x[123] の /etc/libmap.conf を削除して
httpd をリスタート。
これで、
・不可解な 500 エラー
・不可解な httpd 暴走
が、起こらなくなることを期待。
http://www.bookshelf.jp/texi/libtool/libtool-ja_10.html
>一方,`RTLD_NOW'は,FreeBSD上のマルチスレッドアプリケーションで問題が生じたと報告されています.
APR ではまさに RTLD_NOW で dlopen() してるわけですが......
それなら APR のソースをいじって RTLD_LAZY にしちゃってもいいのかも?
>一方,`RTLD_NOW'は,FreeBSD上のマルチスレッドアプリケーションで問題が生じたと報告されています.
APR ではまさに RTLD_NOW で dlopen() してるわけですが......
それなら APR のソースをいじって RTLD_LAZY にしちゃってもいいのかも?
2006/03/17(金) 22:46:17ID:pvQ2ZSVI0
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のソースをいじるのも悪くないかもしれません。
>>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のソースをいじるのも悪くないかもしれません。
474473
2006/03/17(金) 22:49:53ID:pvQ2ZSVI0 書き忘れ。
libpthread, libthr どちらでも落ちませんでした。
libpthread, libthr どちらでも落ちませんでした。
2006/03/17(金) 22:56:36ID:T+Aq1Ujm0
>>474
diffかいてうpしればroot先生が滝のような涙を流して?喜ぶでしょうw
diffかいてうpしればroot先生が滝のような涙を流して?喜ぶでしょうw
476473
2006/03/17(金) 23:20:01ID:pvQ2ZSVI0 --- 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));
+++ 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));
477473
2006/03/17(金) 23:22:42ID:pvQ2ZSVI0 単純なものなので、こんな感じです。
2006/03/17(金) 23:46:00ID:0XhMUK1z0
479root▲ ★
2006/03/18(土) 01:15:26ID:???0 早速、>>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: の) 該当箇所に入れていただければ結構です。
という返事をしました。
ないようですが、
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: の) 該当箇所に入れていただければ結構です。
という返事をしました。
482473
2006/03/18(土) 02:50:06ID:2sxuQruK0 テストのついでに、パフォーマンスも測ってみました。
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]
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]
483473
2006/03/18(土) 02:56:11ID:2sxuQruK0 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の圧勝。ほぼ性能低下なし。
同時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の圧勝。ほぼ性能低下なし。
484root▲ ★
2006/03/18(土) 04:02:30ID:???0485473
2006/03/18(土) 04:06:52ID:2sxuQruK0 すいません。補足です。
上記の測定は
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の方が強いという感じでしょうか。
上記の測定は
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:21ID:HQ7AURmuO
一件落着?
うらやましいな。回線太くて。
でもうちの鯖FC5で僕の携帯のためにアップデートの処理落ち以外はがんがってます。
うらやましいな。回線太くて。
でもうちの鯖FC5で僕の携帯のためにアップデートの処理落ち以外はがんがってます。
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
こんなかんじで、うまくいったっぽい。
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
% 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
...
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
>>487 は、Apache 2.2 なサーバ全部に適用しようかと。
2006/03/18(土) 17:17:28ID:Zp2RcK6z0
>>464,479-780 の件でお邪魔しております。
株式会社アイビス モバイル事業部 担当の西村です。
現行サービスを行っている ibisBrowserDX から
2ちゃんねるへの書き込みを行うに当たって、技術情報を公開します。
アクセスを行う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以外が存在しますが、その場合は書き込みの拒否をお願いいたします。
今後ともよろしくお願い申し上げます。
株式会社アイビス モバイル事業部 担当の西村です。
現行サービスを行っている ibisBrowserDX から
2ちゃんねるへの書き込みを行うに当たって、技術情報を公開します。
アクセスを行う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以外が存在しますが、その場合は書き込みの拒否をお願いいたします。
今後ともよろしくお願い申し上げます。
493焼きうどん ★
NGNG 串規制ってといたほうがいいのかしら?
公式p2はbooでも書ける(be除く)から解除しなくても大丈夫かしら?
公式p2はbooでも書ける(be除く)から解除しなくても大丈夫かしら?
494焼きうどん ★
NGNG ちょっとおそかった。
2006/03/18(土) 17:50:15ID:Zp2RcK6z0
2006/03/18(土) 18:00:26ID:51q1y2cRO
アプリ上で書き込み毎に端末情報を発信するかしないかダイアログ出せるのかなー?
2006/03/18(土) 18:20:22ID:HEpuJvr20
499root▲ ★
NGNG 落ち着いたかな。
今日は気流が悪いらしいです。しくしく。
接続IPアドレスが219.117.203.9で、
UAからIPアドレスとser端末固定番号を正しく入手でき、
そのIPアドレスがDoCoMoのCIDRの範囲に正しく収まっており、
その端末固定番号がBBM規制リストに登録されていない場合
に、書き込み許可になるように設定します。
IDとSamba24の種は、端末番号で生成することになります。
つまり、携帯からダイレクトに書いた場合と同じ扱いになります。
該当IPアドレスのリロードバーボンは解除します。
bbs.cgi に新しい処理系を追加することになるので、
識別マーク Q を新設します。
今日は気流が悪いらしいです。しくしく。
接続IPアドレスが219.117.203.9で、
UAからIPアドレスとser端末固定番号を正しく入手でき、
そのIPアドレスがDoCoMoのCIDRの範囲に正しく収まっており、
その端末固定番号がBBM規制リストに登録されていない場合
に、書き込み許可になるように設定します。
IDとSamba24の種は、端末番号で生成することになります。
つまり、携帯からダイレクトに書いた場合と同じ扱いになります。
該当IPアドレスのリロードバーボンは解除します。
bbs.cgi に新しい処理系を追加することになるので、
識別マーク Q を新設します。
500root▲ ★
NGNG BBQのリストは当面このままで。>>492-493
(正しくとれた時はBBQを参照しないようになります)
bbs.cgi の工事は、たぶん到着してからかなと。
気が向いたら今やるかもしれませんが、
揺れながら Perl いじるのは、ちとつらいかも。
(正しくとれた時はBBQを参照しないようになります)
bbs.cgi の工事は、たぶん到着してからかなと。
気が向いたら今やるかもしれませんが、
揺れながら Perl いじるのは、ちとつらいかも。
>490 >495
なにかトリップつけた方がいいんじゃないでしょうかー。
ご承知かと思いますが、念のため。
トリップの出し方は、名前欄に #password です。
(もちろん password = 任意の文字列 で)
なにか↑こんなような、(おそらく)ユニークな文字列が表示されます。
なにかトリップつけた方がいいんじゃないでしょうかー。
ご承知かと思いますが、念のため。
トリップの出し方は、名前欄に #password です。
(もちろん password = 任意の文字列 で)
なにか↑こんなような、(おそらく)ユニークな文字列が表示されます。
2006/03/18(土) 18:46:15ID:wKvz33Kj0
なんで付ける必要があるのか
503root▲ ★
NGNG つけていただけると助かります。 < トリップ
私は西村様から別途メールをいただいており、
今回の書き込み内容がその内容と一致していたため、
本人であると判断できました。
しかしこれで、担当の方の所属とお名前が公知のものになってしまいましたので、
騙りの可能性がないとはいえなくなりました。
ということで、それを防止する道具(= トリップ)をつけていただけると助かります。
もし同じIPアドレスからの書き込みが可能であれば、
本日中に再度トリップをつけてこのスレに書き込んでいただくと、
IDの一致により、より確度が上がるかと。
私は西村様から別途メールをいただいており、
今回の書き込み内容がその内容と一致していたため、
本人であると判断できました。
しかしこれで、担当の方の所属とお名前が公知のものになってしまいましたので、
騙りの可能性がないとはいえなくなりました。
ということで、それを防止する道具(= トリップ)をつけていただけると助かります。
もし同じIPアドレスからの書き込みが可能であれば、
本日中に再度トリップをつけてこのスレに書き込んでいただくと、
IDの一致により、より確度が上がるかと。
504root▲ ★
NGNG >>490
ひとつ補足です。
> Mozilla/4.0 (compatible; ibisBrowser; IPアドレス; ser端末固定番号)
>
> 例:
> Mozilla/4.0 (compatible; ibisBrowser; 219.117.203.9; ser0123456789ABCDEF)
ここのIPアドレスですが、携帯側からアクセスされたIPアドレスを
そのまま出してくださいです。
上記は単純に例示(であるため御社IPアドレスとなっている)かと思いますが、
一応念のため。
ひとつ補足です。
> Mozilla/4.0 (compatible; ibisBrowser; IPアドレス; ser端末固定番号)
>
> 例:
> Mozilla/4.0 (compatible; ibisBrowser; 219.117.203.9; ser0123456789ABCDEF)
ここのIPアドレスですが、携帯側からアクセスされたIPアドレスを
そのまま出してくださいです。
上記は単純に例示(であるため御社IPアドレスとなっている)かと思いますが、
一応念のため。
505讃岐フォアンフォアン▲ ◆SANUKI/VII
NGNG 携帯と同じIDになるのにQの必要ってあるんですか?
たびたび失礼します。
先ほど書きました >>490 の件についてですが
書き込みを行うにあたって、一時的に付与するUser-Agent:
Mozilla/4.0 (compatible; ibisBrowser; ipIPアドレス; iccフォーマカード番号)
例:
Mozilla/4.0 (compatible; ibisBrowser; ip219.117.203.9; icc0123456789ABCDEF)
に変更をお願いできませんか。
急な変更になりまして申し訳ありません。
先ほど書きました >>490 の件についてですが
書き込みを行うにあたって、一時的に付与するUser-Agent:
Mozilla/4.0 (compatible; ibisBrowser; ipIPアドレス; iccフォーマカード番号)
例:
Mozilla/4.0 (compatible; ibisBrowser; ip219.117.203.9; icc0123456789ABCDEF)
に変更をお願いできませんか。
急な変更になりまして申し訳ありません。
509root▲ ★
NGNG2006/03/18(土) 19:15:41ID:HEpuJvr20
ibisBrowserはFOMAカード製造番号しか取得してないんですよね。
なのでiccxxxxxxxxxxxxxxxxxxxx(20桁のFOMAカード製造番号)という形になるかと。
なのでiccxxxxxxxxxxxxxxxxxxxx(20桁のFOMAカード製造番号)という形になるかと。
2006/03/18(土) 19:35:45ID:eCJ6GVAs0
2006/03/18(土) 19:40:38ID:Yat3ZqsT0
しかも座席はYクラスじゃないぞ。スレ違いだけど。w
514root▲ ★
NGNG 食事終わりました。
icc だけですか。
それだと、書き込み許可はできないです。
serXXXXXXXXXXX のほうを(あるいは、ほうも)、
User-Agent 経由で送っていただく必要があります。
よろしくお願いします。
icc だけですか。
それだと、書き込み許可はできないです。
serXXXXXXXXXXX のほうを(あるいは、ほうも)、
User-Agent 経由で送っていただく必要があります。
よろしくお願いします。
2006/03/18(土) 20:48:56ID:HEpuJvr20
なるほど。
ということはibisBrowserの仕様を変更して、
端末製造番号も取得できるようにしなければならないわけですね。
ということはibisBrowserの仕様を変更して、
端末製造番号も取得できるようにしなければならないわけですね。
2006/03/18(土) 20:53:36ID:bZeuSXqF0
「人」に対する許可/禁止をするという考えなら、ICカード識別番号(icc)のほうがいいと思うのはオイラだけ?
こういうブラウザってFOMA専用っぽいし……
こういうブラウザってFOMA専用っぽいし……
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【札幌】ライブのため…小学生の息子を約3日間自宅に放置 脱水症・低血糖にさせた疑い 母親(34)逮捕 [煮卵★]
- ホンダ日産 経営統合へ 新会社トップはホンダ指名の取締役から [蚤の市★]
- 【スクープ】中居正広が女性との間に重大トラブル、巨額の解決金を支払う 重病から復帰後の会食で深刻な問題が発生 ★29 [Ailuropoda melanoleuca★]
- 日本の家どんどん狭く ステルス値上げで30年前の水準に [蚤の市★]
- イチロー氏、今のメジャーは「退屈」 松井秀喜氏と10年ぶり再会…日本球界への影響も危惧 [王子★]
- 【テレビ】M-1視聴率 関東は18・0%!瞬間最高は21・4% 令和ロマンが史上初の連覇 [冬月記者★]
- 【悲報】兎田ぺこーら「競馬で100万負けたペコ」👉赤スパの嵐に [737150144]
- 「独身男性は狂う」嘘だった。一番キツいのは妻と子供に捨てられた離婚男性 [811796219]
- 【悲報】ゲーセン、もうだめそう [821395612]
- 🏡【躊躇】須磨都民👶、泣き叫ぶ「助けて!もう毎日毎日すこられるのイヤなの!!!!」
- DeNA濱口 SB三森トレード!!!!
- 【正論】自民・小野寺「178万に引き上げる財源はなんだよ!言えるもんならな!」国民・古川「地価税の課税を再開すればいいよね?」 [918057362]