2ch特化型サーバ・ロケーション構築作戦のスレッドです。
・2ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更関連の各種作業や調整事項
・2ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携
等を取り扱います。
現在、複数サーバによる連携により、
サーバ能力のさらなるスケールアップをめざすための「雪だるま作戦」が進行中です。
しかし、問題はあらゆる意味で山積の状態です。
また「2ちゃんねる証券取引所」をはじめとする「株」関連や「Be」の機能強化、
あるいは、次世代の携帯アクセス環境をめざした「べっかんこ作戦」の状況など、
気候も暖かくなり、そろそろ気になりだす季節にさしかかりつつある今日この頃、
あいかわらず2ちゃんねるは、刻一刻と確実に変化し続けています。
2ch特化型サーバ・ロケーション構築作戦 Part21
■ このスレッドは過去ログ倉庫に格納されています
1root▲ ★
NGNG197root▲ ★
NGNG >>196 第一段落
過去ログでは、「祭り」はないですからね(あってたまるか(w)。
で、ご指摘のとおり、
基本的にはdatができていくだけなので、
そういう部分では、確かに虫を踏む可能性は少なそうですね。
(というかそう思ったので、NFSにしてみたという側面があります)
過去ログでは、「祭り」はないですからね(あってたまるか(w)。
で、ご指摘のとおり、
基本的にはdatができていくだけなので、
そういう部分では、確かに虫を踏む可能性は少なそうですね。
(というかそう思ったので、NFSにしてみたという側面があります)
2006/04/25(火) 09:16:41ID:aQCO1jRV0
>>rootさん
jigブラウザでの書き込みの対応が目前な様ですが、書き込み可能になった場合の
公式p2経由での書き込みに関してはどのような扱いになりますでしょうか?
確か、現在の公式p2ではBBQとBBMの規制データを基に規制をしていたと思うのですが
jigブラウザでの書き込みの対応が目前な様ですが、書き込み可能になった場合の
公式p2経由での書き込みに関してはどのような扱いになりますでしょうか?
確か、現在の公式p2ではBBQとBBMの規制データを基に規制をしていたと思うのですが
>>194
書き込みテストが完了致しました。
問題ございません。
■テスト結果
http://qb5.2ch.net/test/read.cgi/operate/1145833088/27-70
【DoCoMo】
27ネイティブ
28jigブラウザ
【ボーダフォン】
30jigブラウザ
32ネイティブ
【au】
69jigブラウザ
70ネイティブ
bbs.cgi全サーバに配布お願い致します。
宜しくお願い致します。
書き込みテストが完了致しました。
問題ございません。
■テスト結果
http://qb5.2ch.net/test/read.cgi/operate/1145833088/27-70
【DoCoMo】
27ネイティブ
28jigブラウザ
【ボーダフォン】
30jigブラウザ
32ネイティブ
【au】
69jigブラウザ
70ネイティブ
bbs.cgi全サーバに配布お願い致します。
宜しくお願い致します。
200root▲ ★
NGNG201▲ ◆SANUKI/VII
NGNG そして伝説へ
2006/04/25(火) 11:51:08ID:PGEbgPoeP
P2の規制チェックをBBQからBBXにすることはできませんか?
ここではスレ違いかな…
ここではスレ違いかな…
2006/04/25(火) 11:52:36ID:+haoXbxGP
ibisやjig側がp2を作ってアプリで直カキコした時と同じように端末情報などを2ch側に送信するのは?
204root▲ ★
NGNG >>202
Proxy + p2 で、荒らしツールとして使われまくった過去があるですね。
ようは「規制回避ツール」「荒らしツール」として使うのは、おことわりってことで。
で、たぶんスレ違いな肝。
# 上にも質雑スレにも書いたように、ibis と jig については迷っているので、
# 気まぐれに解除を依頼するかも。
Proxy + p2 で、荒らしツールとして使われまくった過去があるですね。
ようは「規制回避ツール」「荒らしツール」として使うのは、おことわりってことで。
で、たぶんスレ違いな肝。
# 上にも質雑スレにも書いたように、ibis と jig については迷っているので、
# 気まぐれに解除を依頼するかも。
205root▲ ★
NGNG >>203
そういう形での解決は、ありえますね。
p2(相当)のしくみを各アプリのベンダーさんが持って
技術情報を開示 => 2ちゃんねるでうまく対応
みたいな解決パターンは、じゅうぶん考えられると思います。
前スレでもちょっと議論しましたが、一般論だと、
・荒らしツール、規制回避ツールとして使うのはおことわりです
・携帯の場合、個別規制ができる形がいいなぁ(= 端末固有情報を2ちゃんねる側で得られる)
・2ちゃんねるから見て、コスト的に大きくないのがいいなぁ(= 大きな負荷や手間がかからない)
ってかんじなのかなと。
そういう形での解決は、ありえますね。
p2(相当)のしくみを各アプリのベンダーさんが持って
技術情報を開示 => 2ちゃんねるでうまく対応
みたいな解決パターンは、じゅうぶん考えられると思います。
前スレでもちょっと議論しましたが、一般論だと、
・荒らしツール、規制回避ツールとして使うのはおことわりです
・携帯の場合、個別規制ができる形がいいなぁ(= 端末固有情報を2ちゃんねる側で得られる)
・2ちゃんねるから見て、コスト的に大きくないのがいいなぁ(= 大きな負荷や手間がかからない)
ってかんじなのかなと。
206root▲ ★
NGNG Hello, Sean-san, Jim-san,
Cc: related folks,
This is Mumumu. Genki-desuka?
Now several XO 2ch servers, cobra2247, tiger503, and tiger507 are
'almost idling'. So, we need to verify the current electric power
status before these servers working well.
I want to know the current status of power circuit configuration.
I think that if cobra2247 works well, it will use the electric power
almost the same as oyster901. Is the current electric power
configuration of XO enough for it?
And if tiger503 and tiger507 work well, they will use the electric
power almost the same as tiger2523 and tiger2524.
If the power is not enough for them, we can move out some servers of XO,
they are tiger504, tiger509, tiger510 and cobra2245.
We want to advance the power up of the server of 2ch by "The Snowman"
clustering technology. The "Snowman" system is now working on tiger2522,
tiger2523, tiger2524 and tiger2525.
I think it is an ultimate server system for 2ch. I will describe to you
details of it.
Thank you for your cooperation.
Regards,
Cc: related folks,
This is Mumumu. Genki-desuka?
Now several XO 2ch servers, cobra2247, tiger503, and tiger507 are
'almost idling'. So, we need to verify the current electric power
status before these servers working well.
I want to know the current status of power circuit configuration.
I think that if cobra2247 works well, it will use the electric power
almost the same as oyster901. Is the current electric power
configuration of XO enough for it?
And if tiger503 and tiger507 work well, they will use the electric
power almost the same as tiger2523 and tiger2524.
If the power is not enough for them, we can move out some servers of XO,
they are tiger504, tiger509, tiger510 and cobra2245.
We want to advance the power up of the server of 2ch by "The Snowman"
clustering technology. The "Snowman" system is now working on tiger2522,
tiger2523, tiger2524 and tiger2525.
I think it is an ultimate server system for 2ch. I will describe to you
details of it.
Thank you for your cooperation.
Regards,
207root▲ ★
NGNG 菊池様;
202.181.98.242
202.181.98.243
202.181.98.244
202.181.98.245
202.181.98.246
202.181.98.247
202.181.98.248
202.181.98.249
202.181.98.250
これらの御社のサーバは、DNSの逆引きがエラーになっているようです。
202.181.98.242
202.181.98.243
202.181.98.244
202.181.98.245
202.181.98.246
202.181.98.247
202.181.98.248
202.181.98.249
202.181.98.250
これらの御社のサーバは、DNSの逆引きがエラーになっているようです。
208root▲ ★
NGNG >>207 続き、
こちらで確認してみたところ、
%dig -t ptr 242.98.181.202.in-addr.arpa. @ns1.dns.ne.jp.
; <<>> DiG 9.3.2 <<>> -t ptr 242.98.181.202.in-addr.arpa. @ns1.dns.ne.jp.
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61718
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;242.98.181.202.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
242.98.181.202.in-addr.arpa. 3600 IN NS dns1.jig.jp.98.181.202.in-addr.arpa.
242.98.181.202.in-addr.arpa. 3600 IN NS dns2.jig.jp.98.181.202.in-addr.arpa.
;; Query time: 110 msec
;; SERVER: 210.188.224.9#53(210.188.224.9)
;; WHEN: Tue Apr 25 00:31:48 2006
;; MSG SIZE rcvd: 90
となっており、DNSサーバの指定が適切ではない状態にみえます。
# たぶん上位ISP(ns1.dns.ne.jp)において、NS 指定の末尾に "." を付け忘れていると思われ。
# 以上、老婆心ながら。
こちらで確認してみたところ、
%dig -t ptr 242.98.181.202.in-addr.arpa. @ns1.dns.ne.jp.
; <<>> DiG 9.3.2 <<>> -t ptr 242.98.181.202.in-addr.arpa. @ns1.dns.ne.jp.
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61718
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;242.98.181.202.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
242.98.181.202.in-addr.arpa. 3600 IN NS dns1.jig.jp.98.181.202.in-addr.arpa.
242.98.181.202.in-addr.arpa. 3600 IN NS dns2.jig.jp.98.181.202.in-addr.arpa.
;; Query time: 110 msec
;; SERVER: 210.188.224.9#53(210.188.224.9)
;; WHEN: Tue Apr 25 00:31:48 2006
;; MSG SIZE rcvd: 90
となっており、DNSサーバの指定が適切ではない状態にみえます。
# たぶん上位ISP(ns1.dns.ne.jp)において、NS 指定の末尾に "." を付け忘れていると思われ。
# 以上、老婆心ながら。
210桶屋
2006/04/26(水) 00:16:26ID:4qUryQYl0 >>210
>サーバのアクセスが集中しているときに、NFSやbbsdをTCPにしてみる。
ん......問題の切り分けという点では興味深いですが,bbsd は UDP に依存した
造りになってるんで,TCP で扱えるようにするのはちょっと大変かも......
あと,アクセス集中でおかしくなる時はバックエンドへの HTTP アクセス,
つまり TCP でもどん詰まりになってるんで,パケットのドロップ自体より,
ドロップをきっかけに別の異常が発生しているという感じなのかな,とも......
>サーバのアクセスが集中しているときに、NFSやbbsdをTCPにしてみる。
ん......問題の切り分けという点では興味深いですが,bbsd は UDP に依存した
造りになってるんで,TCP で扱えるようにするのはちょっと大変かも......
あと,アクセス集中でおかしくなる時はバックエンドへの HTTP アクセス,
つまり TCP でもどん詰まりになってるんで,パケットのドロップ自体より,
ドロップをきっかけに別の異常が発生しているという感じなのかな,とも......
212桶屋
2006/04/26(水) 00:36:11ID:4qUryQYl0 >あと,アクセス集中でおかしくなる時はバックエンドへの HTTP アクセス,
>つまり TCP でもどん詰まりになってるんで,パケットのドロップ自体より,
>ドロップをきっかけに別の異常が発生しているという感じなのかな,とも......
詳しくどうもです。
もうちょっと詳しい観察と切り分けが必要ってことなんですね。
>つまり TCP でもどん詰まりになってるんで,パケットのドロップ自体より,
>ドロップをきっかけに別の異常が発生しているという感じなのかな,とも......
詳しくどうもです。
もうちょっと詳しい観察と切り分けが必要ってことなんですね。
214root▲ ★
NGNG Jim-san, Ryan-san, Tom-san,
Thank you for your help.
I have more questions.
1) I want to know which circuit following servers are connected to
precisely.
tiger503
tiger507
cobra2247
I think MS VM 1 and MS VM 2 in MS-XO-9 are almost full. If these
servers are connected to their circuit, we have to change the circuit
configuration. So, please tell us the information.
2) What time do you measured the amp usage? The amp usage of 2ch
servers are vary. 22:00-24:00 JST (it is equal to 6:00;8:00 PDT)
is the maximum time. We need to check the actual usage at that time.
Regards,
> MS-XO-2
> MS VM 1 Load: 8 of 20 amps [39%]
> MS VM 2 Load: 3 of 15 amps [17%]
> MS-XO-9
> MS VM 1 Load: 11 of 15 amps [73%]
> MS VM 2 Load: 17 of 20 amps [87%]
> MS VM 3 Load: 6 of 20 amps [31%]
> MS VM 4 Load: 5 of 15 amps [32%]
Thank you for your help.
I have more questions.
1) I want to know which circuit following servers are connected to
precisely.
tiger503
tiger507
cobra2247
I think MS VM 1 and MS VM 2 in MS-XO-9 are almost full. If these
servers are connected to their circuit, we have to change the circuit
configuration. So, please tell us the information.
2) What time do you measured the amp usage? The amp usage of 2ch
servers are vary. 22:00-24:00 JST (it is equal to 6:00;8:00 PDT)
is the maximum time. We need to check the actual usage at that time.
Regards,
> MS-XO-2
> MS VM 1 Load: 8 of 20 amps [39%]
> MS VM 2 Load: 3 of 15 amps [17%]
> MS-XO-9
> MS VM 1 Load: 11 of 15 amps [73%]
> MS VM 2 Load: 17 of 20 amps [87%]
> MS VM 3 Load: 6 of 20 amps [31%]
> MS VM 4 Load: 5 of 15 amps [32%]
215む@携帯
2006/04/26(水) 21:44:09ID:LLZKM6MbO do you measuredって何だよ、、、。ううむ。
>>215
ibis+公式p2書き込みの件で返事来ました
いつもお世話になっております。アイビスサポート係です。
p2の管理者様が
「ibisBrowserから2chに書き込むために出力しているUserAgent」
への有効化を行っていただければ、
ibisBrowser側のアップデートで実現可能と思います。
実装については前向きに検討してまいります。
今後ともよろしくお願い申し上げます。
↑をあきさんに伝えれば宜しいのでしょうか?
ibis+公式p2書き込みの件で返事来ました
いつもお世話になっております。アイビスサポート係です。
p2の管理者様が
「ibisBrowserから2chに書き込むために出力しているUserAgent」
への有効化を行っていただければ、
ibisBrowser側のアップデートで実現可能と思います。
実装については前向きに検討してまいります。
今後ともよろしくお願い申し上げます。
↑をあきさんに伝えれば宜しいのでしょうか?
217root▲ ★
NGNG >>216
ですね。
既にこちらにも貼られているようです。
p2.2ch.net不具合報告スレ Part10
http://qb5.2ch.net/test/read.cgi/operate/1141521195/
ですね。
既にこちらにも貼られているようです。
p2.2ch.net不具合報告スレ Part10
http://qb5.2ch.net/test/read.cgi/operate/1141521195/
219root▲ ★
NGNG あ、そうだ。一応念のため。
ibis さん、jig さんとも、相手方のドメイン名を見て、固有情報を送っているのかしら。
だとすると、2ch.net に加えて、bbspink.com に対しても同じ動作をする必要があると思います。
ibis さん、jig さんとも、相手方のドメイン名を見て、固有情報を送っているのかしら。
だとすると、2ch.net に加えて、bbspink.com に対しても同じ動作をする必要があると思います。
2006/04/27(木) 01:50:56ID:7FX0xzeW0
221root▲ ★
NGNG p2.2ch.net のほうでは、対応が終わったとのことです。
p2.2ch.net不具合報告スレ Part10
http://qb5.2ch.net/test/read.cgi/operate/1141521195/675
ということで、p2.2ch.net 経由での書き込みについても、
通常の bbs.cgi 経由での書き込みと同じ形で
固有情報を送っていただくように設定された時点で、
同様に書き込みができるようになるはずです。 > ibis/jig とも
# この場合のIDの末尾は、通常のp2での書き込み同様に P となります。
p2.2ch.net不具合報告スレ Part10
http://qb5.2ch.net/test/read.cgi/operate/1141521195/675
ということで、p2.2ch.net 経由での書き込みについても、
通常の bbs.cgi 経由での書き込みと同じ形で
固有情報を送っていただくように設定された時点で、
同様に書き込みができるようになるはずです。 > ibis/jig とも
# この場合のIDの末尾は、通常のp2での書き込み同様に P となります。
222root▲ ★
NGNG >>220
了解。やはりそうですか。
これは、それぞれの中の方々の対応待ちですね。
お手数ですが、もし公式 p2 のアカウントをお持ちであれば、
>>221 についても、*以下のスレでの解除作業が終了後に*
お試しいただけますと助かります。
【BBQ&BBM14本目】公開串登録所【ピンポイント規制】
http://qb5.2ch.net/test/read.cgi/sec2chd/1145893627/
了解。やはりそうですか。
これは、それぞれの中の方々の対応待ちですね。
お手数ですが、もし公式 p2 のアカウントをお持ちであれば、
>>221 についても、*以下のスレでの解除作業が終了後に*
お試しいただけますと助かります。
【BBQ&BBM14本目】公開串登録所【ピンポイント規制】
http://qb5.2ch.net/test/read.cgi/sec2chd/1145893627/
2006/04/27(木) 02:09:40ID:7FX0xzeW0
>>222
p2で試してみました。
ibis、jigともに
「p2 error: 携帯の固有端末IDを送信しないと書き込みできません。。(携帯の設定で、固有端末IDを送信するようにしてください)」
が表示されました。
・・・あれっ?
p2で試してみました。
ibis、jigともに
「p2 error: 携帯の固有端末IDを送信しないと書き込みできません。。(携帯の設定で、固有端末IDを送信するようにしてください)」
が表示されました。
・・・あれっ?
2006/04/27(木) 02:12:40ID:7FX0xzeW0
どうやらjigも通常の書き込み時"のみ"固有情報を送信しているようですね。
・・・ということはjig側の対応も必要ということですね。
・・・ということはjig側の対応も必要ということですね。
225root▲ ★
NGNG 西村様、菊池様;
p2.2ch.net不具合報告スレ Part10
http://qb5.2ch.net/test/read.cgi/operate/1141521195/686
ということで、jig, ibis とも、現時点では p2.2ch.net 経由では
固有情報を送信しないように設定されている模様です。
p2.2ch.net は2ちゃんねる公式のサービスですので、
こちらでの書き込みの際にも、同様の形式で送るように
設定をいただけますと大変助かります。
なお、>>221 にあるように、p2.2ch.net での設定は完了している旨、
連絡をもらっています。
>>219 の件とあわせ、お手数ですがよろしくお願いいたします。
p2.2ch.net不具合報告スレ Part10
http://qb5.2ch.net/test/read.cgi/operate/1141521195/686
ということで、jig, ibis とも、現時点では p2.2ch.net 経由では
固有情報を送信しないように設定されている模様です。
p2.2ch.net は2ちゃんねる公式のサービスですので、
こちらでの書き込みの際にも、同様の形式で送るように
設定をいただけますと大変助かります。
なお、>>221 にあるように、p2.2ch.net での設定は完了している旨、
連絡をもらっています。
>>219 の件とあわせ、お手数ですがよろしくお願いいたします。
227root▲ ★
NGNG jig さんについては、続報が。
ちと、向こうのスレの動きを観察します。
p2.2ch.net不具合報告スレ Part10
http://qb5.2ch.net/test/read.cgi/operate/1141521195/687
ちと、向こうのスレの動きを観察します。
p2.2ch.net不具合報告スレ Part10
http://qb5.2ch.net/test/read.cgi/operate/1141521195/687
228root▲ ★
NGNG p2.2ch.net不具合報告スレ Part10
http://qb5.2ch.net/test/read.cgi/operate/1141521195/700-702
jig については、p2.2ch.net 側の対応により
書き込みが可能になったようです。
ということで残作業は、
jig: >>219
ibis: >>219 >>216
になります。お手数ですがよろしくです。
# 今日はそろそろ、寝る時間で。
http://qb5.2ch.net/test/read.cgi/operate/1141521195/700-702
jig については、p2.2ch.net 側の対応により
書き込みが可能になったようです。
ということで残作業は、
jig: >>219
ibis: >>219 >>216
になります。お手数ですがよろしくです。
# 今日はそろそろ、寝る時間で。
231stream ◆PNstream2s
2006/04/27(木) 10:57:48ID:eG5n3QCX0 いつのまにかeAccelerator-0.9.5-beta2になってます
>>219に関してibisから返事来ましたー
いつもお世話になっております。アイビスサポート係です。
情報提供まことにありがとうございます。ご連絡いただいたページも参考にさせていただきます。
今後とも宜しくお願い申し上げます。
との事です
もー1通はp2スレに貼ります
ありがとうございましたm(__)m
いつもお世話になっております。アイビスサポート係です。
情報提供まことにありがとうございます。ご連絡いただいたページも参考にさせていただきます。
今後とも宜しくお願い申し上げます。
との事です
もー1通はp2スレに貼ります
ありがとうございましたm(__)m
237root▲ ★
NGNG u.la の対応がなされたようです。
雪だるま作戦のスレを待ち続けるスレ Part6
http://aa5.2ch.net/test/read.cgi/nanmin/1144142021/946
確認をお願いいたします。
雪だるま作戦のスレを待ち続けるスレ Part6
http://aa5.2ch.net/test/read.cgi/nanmin/1144142021/946
確認をお願いいたします。
u.la から bbspink.comの書き込みを確認しました。
http://same.u.la/test/r.so/sakura02.bbspink.com/pinkqa/1142871332/481
478: bbspink.com からibisBrowserで直接書き込み
479: c.2ch.net からibisBrowserで書き込み
480: (PCから書き込み)
481: u.la からibisBrowserで書き込み
以上の通り、書き込みできましたことを報告いたします。
http://same.u.la/test/r.so/sakura02.bbspink.com/pinkqa/1142871332/481
478: bbspink.com からibisBrowserで直接書き込み
479: c.2ch.net からibisBrowserで書き込み
480: (PCから書き込み)
481: u.la からibisBrowserで書き込み
以上の通り、書き込みできましたことを報告いたします。
241カイト
2006/04/27(木) 19:05:12ID:hLXKjTQn0 皆さんに質問ですウイルスの作り方知ってる人カキコおねがいします
(*´д`)ハァハァ
(*´д`)ハァハァ
2006/04/27(木) 19:20:01ID:xm32mp4Q0
2006/04/27(木) 19:21:37ID:swt1nvC50
そしてお湯を沸かす
↓
↓
244▲ ◆SANUKI/VII
NGNG VIPでやれ
2006/04/27(木) 20:07:09ID:xm32mp4Q0
怒られる
↓
↓
2006/04/27(木) 20:11:25ID:Egjy6L/JP
讃岐あぼん
2006/04/27(木) 20:13:11ID:qyRDUlMq0
出来上がりです!
2006/04/27(木) 20:23:03ID:vNc69kqx0
蒸らしが足りないので失敗でした。。
NGNG
rootさん・西村さん、お疲れ様でしたm(_ _)m
250root▲ ★
NGNG さっき、live22 が重くなった時。
症状は先日と同じで、CPU idle time が 0 になり、
umtx という状態の httpd が多数発生して、httpd 自体が signal 10 でダウンするもの。
httpd の数を少なくしておくと、操作できなくなるほどの重さにはならない。
core 吐いているので、gdb の出力をこれから調査。
(gdb) where
#0 0x282884d3 in _umtx_op () from /lib/libc.so.6
Cannot access memory at address 0xb787de80
症状は先日と同じで、CPU idle time が 0 になり、
umtx という状態の httpd が多数発生して、httpd 自体が signal 10 でダウンするもの。
httpd の数を少なくしておくと、操作できなくなるほどの重さにはならない。
core 吐いているので、gdb の出力をこれから調査。
(gdb) where
#0 0x282884d3 in _umtx_op () from /lib/libc.so.6
Cannot access memory at address 0xb787de80
251root▲ ★
NGNG で、top で見ると、
"stopped" なスレッドが山ほどいた。
明らかに、挙動不審だ。
"stopped" なスレッドが山ほどいた。
明らかに、挙動不審だ。
252root▲ ★
NGNG もう1回堀江被告が出るようなので、
/etc/libmap.conf を /etc/libmap.conf.SAVE に mv して、
Apache と bbsd をリスタートし、
libthr => libpthread に戻してみた。
/etc/libmap.conf を /etc/libmap.conf.SAVE に mv して、
Apache と bbsd をリスタートし、
libthr => libpthread に戻してみた。
253root▲ ★
NGNG #XXX#MaxKeepAliveRequests 100
↓
MaxKeepAliveRequests 0
これはあんまり効果ないかなぁ。
やはり、mod_cache とかか。
↓
MaxKeepAliveRequests 0
これはあんまり効果ないかなぁ。
やはり、mod_cache とかか。
桃の毛が明晩に迫ってて,バック増設も間に合いそうにない,となると
やはり mod_cache か......
やはり mod_cache か......
2006/04/27(木) 23:54:34ID:FVJqUPlM0
桃の毛は5/12だからそこまで急がなくても。
>>255 なるほど......金曜日とかどっかで見たような気がして,てっきり明日かと......
257stream ◆PNstream2s
2006/04/28(金) 00:12:56ID:kCVpYe/y0 Apache2.2.0で起こるフロントの暴走って結局どうなりました?
mod_proxyで子プロセスがCPUを100%つかうバグが2.2.0にあるみたいですけど
http://svn.apache.org/viewcvs.cgi?rev=390724&view=rev
mod_proxyで子プロセスがCPUを100%つかうバグが2.2.0にあるみたいですけど
http://svn.apache.org/viewcvs.cgi?rev=390724&view=rev
2006/04/28(金) 00:31:15ID:g6hnuWFD0
2.2.0じゃないの?
GET /ootoko/subject.txt HTTP/1.1
If-Modified-Since: Thu, 27 Apr 2006 14:27:26 GMT
Host: live22x.2ch.net
Accept: text/html, */*
Accept-Encoding: gzip
User-Agent: Monazilla/1.00 (JaneStyle/2.23)
HTTP/1.1 304 Not Modified
Date: Thu, 27 Apr 2006 15:22:36 GMT
Server: Apache/2.2.0
ETag: "126a1-3d-63244f80"
Vary: Accept-Encoding
GET /ootoko/subject.txt HTTP/1.1
If-Modified-Since: Thu, 27 Apr 2006 14:27:26 GMT
Host: live22x.2ch.net
Accept: text/html, */*
Accept-Encoding: gzip
User-Agent: Monazilla/1.00 (JaneStyle/2.23)
HTTP/1.1 304 Not Modified
Date: Thu, 27 Apr 2006 15:22:36 GMT
Server: Apache/2.2.0
ETag: "126a1-3d-63244f80"
Vary: Accept-Encoding
260root▲ ★
NGNG >>259
mod_proxy 経由でバックエンドにいくと、そうなります。
バックエンドは Apache 2.2.0
HEAD / HTTP/1.1
Host: live22x.2ch.net
HTTP/1.1 200 OK
Date: Thu, 27 Apr 2006 15:38:03 GMT
Server: Apache/2.0.55
Last-Modified: Thu, 18 Aug 2005 12:46:12 GMT
ETag: "da84b-8c-9917ed00"
Accept-Ranges: bytes
Content-Length: 140
Vary: Accept-Encoding
Content-Type: text/html
mod_proxy 経由でバックエンドにいくと、そうなります。
バックエンドは Apache 2.2.0
HEAD / HTTP/1.1
Host: live22x.2ch.net
HTTP/1.1 200 OK
Date: Thu, 27 Apr 2006 15:38:03 GMT
Server: Apache/2.0.55
Last-Modified: Thu, 18 Aug 2005 12:46:12 GMT
ETag: "da84b-8c-9917ed00"
Accept-Ranges: bytes
Content-Length: 140
Vary: Accept-Encoding
Content-Type: text/html
2006/04/28(金) 00:40:58ID:g6hnuWFD0
あら、そんな仕様だったのか。失礼しました。
262root▲ ★
NGNG 明日以降、mod_cache を入れるべく、
squid と mod_cache あり Apache との間で実際にどんなやりとりがなされているか
調べてみるということで。
squid と mod_cache あり Apache との間で実際にどんなやりとりがなされているか
調べてみるということで。
2006/04/29(土) 10:41:19ID:pY0afDFM0
Apacheが落ちちゃう問題について。
自宅の6.0-RELEASEマシンで再現したので、いろいろ調べてるんですが、
メモリが破壊されることがある模様。
例:
(gdb) frame 2
#2 0x08095001 in ap_http_header_filter (f=0x819edd8, b=0x819f708) at http_filters.c:1024
1024 send_all_header_fields(&h, r);
(gdb) p r
$31 = (request_rec *) 0x819e050
(gdb) p *r
$32 = {pool = 0x2c746153, connection = 0x20393220, server = 0x20727041, next = 0x36303032,
<長いので省略>
(gdb)
0x2c746153 -> ,taS -> Sat,
0x20393220 -> 92 -> 29
0x20727041 -> rpA -> Apr
つまり Sat, 29 Apr
…というように、本来ポインタ値が入るところに文字列が入ってます。
今のところ、OSの問題なのか、Apacheの問題なのかは不明です。
自宅の6.0-RELEASEマシンで再現したので、いろいろ調べてるんですが、
メモリが破壊されることがある模様。
例:
(gdb) frame 2
#2 0x08095001 in ap_http_header_filter (f=0x819edd8, b=0x819f708) at http_filters.c:1024
1024 send_all_header_fields(&h, r);
(gdb) p r
$31 = (request_rec *) 0x819e050
(gdb) p *r
$32 = {pool = 0x2c746153, connection = 0x20393220, server = 0x20727041, next = 0x36303032,
<長いので省略>
(gdb)
0x2c746153 -> ,taS -> Sat,
0x20393220 -> 92 -> 29
0x20727041 -> rpA -> Apr
つまり Sat, 29 Apr
…というように、本来ポインタ値が入るところに文字列が入ってます。
今のところ、OSの問題なのか、Apacheの問題なのかは不明です。
>>262 この壁を乗り越えると,また一歩前進と......
265軍艦焼 ★
2006/04/29(土) 11:07:12ID:???0 【BBQ&BBM14本目】公開串登録所【ピンポイント規制】
http://qb5.2ch.net/test/read.cgi/sec2chd/1145893627/96-97
携帯からなのでbrew.ne.jpと思われる範囲をばっさりしました。
(>>205の考えと宣伝荒らし発生のため)
ご報告まで。
http://qb5.2ch.net/test/read.cgi/sec2chd/1145893627/96-97
携帯からなのでbrew.ne.jpと思われる範囲をばっさりしました。
(>>205の考えと宣伝荒らし発生のため)
ご報告まで。
>>263 う〜む......そうなっちゃうとすると SIGBUS 発生も頷けますが,しかしなぜそうなるのか......
2006/04/29(土) 11:23:23ID:TGF9wkTR0
メモリが糞で化けてる可能性は無視ですか?そうですか。
2006/04/29(土) 12:04:34ID:WQscSnyKO
きっとアドレスが足りないんだよ、ァ。
再現できるので、多分OSでゴミが貯まっているかも。
二日にいっぺん再起動かけるようにしたらいいかも。
10:55〜11:00までは朝支度をしています。何卒ご了承下さい。
再現できるので、多分OSでゴミが貯まっているかも。
二日にいっぺん再起動かけるようにしたらいいかも。
10:55〜11:00までは朝支度をしています。何卒ご了承下さい。
2006/04/29(土) 13:58:38ID:2y12yphs0
memtestかけて何も問題無かったらapacheの問題かな?
270root▲ ★
NGNG signal 10 で落ちるのは 2ch 全土でかなり昔から観測されているので、
Apache か OS の問題と思いますね。
preform MPM な banana / tiger / cobra でも観測されているです。
Apache か OS の問題と思いますね。
preform MPM な banana / tiger / cobra でも観測されているです。
2006/04/29(土) 15:27:45ID:vLnePUkK0
>>263
こういうのは、普通はAPL側での、メモリの誤解放、
メモリを解放したけどなんらかの検索用のlistからの
削除が漏れていた、listからの削除がメモリ解放より
後になっていてプリエンプションで他のプロセスに
メモリを横取りされた、といったことが多いですね。
でも、ApacheとFreeBSDどっちが信頼がおけるのだろう...
こういうのは、普通はAPL側での、メモリの誤解放、
メモリを解放したけどなんらかの検索用のlistからの
削除が漏れていた、listからの削除がメモリ解放より
後になっていてプリエンプションで他のプロセスに
メモリを横取りされた、といったことが多いですね。
でも、ApacheとFreeBSDどっちが信頼がおけるのだろう...
2006/04/29(土) 15:31:24ID:2y12yphs0
どっちも枯れたとは言い難い最新版だしなぁ
2006/04/29(土) 15:39:53ID:WQscSnyKO
この際他のディストリに乗り換えてみるとか。
debian
fedora
centos
gentoo
ubuntu
あと個人的には理研のKNOPPIXがたしかworkノードを分散処理出来るらしいので気になる。
debian
fedora
centos
gentoo
ubuntu
あと個人的には理研のKNOPPIXがたしかworkノードを分散処理出来るらしいので気になる。
2006/04/29(土) 16:17:31ID:m2wBdN/f0
>>274はなんで2chがFreeBSD採用しているのかわかっているのだろうか
お守りをする人が一番得意としているからだろw
お守りをする人が一番得意としているからだろw
276263
2006/04/30(日) 12:05:34ID:0J9aTQO80 >>263 の問題についてパッチを作ったので、後ほどUPします(現在テスト中)。
パッチを当てる前は結構落ちてましたが、
パッチを当てた後は、今のところ一度も落ちていません。
live22 で落ちる原因がこれと同じかはわかりませんが。。。
なお、これは Apache 2.2.0 worker で落ちる問題の対応で、
prefork で落ちるのは別の原因だと思われます。
パッチを当てる前は結構落ちてましたが、
パッチを当てた後は、今のところ一度も落ちていません。
live22 で落ちる原因がこれと同じかはわかりませんが。。。
なお、これは Apache 2.2.0 worker で落ちる問題の対応で、
prefork で落ちるのは別の原因だと思われます。
277263
2006/04/30(日) 13:06:17ID:0J9aTQO80 長いので、分けてUPします。
--- server/mpm/worker/fdqueue.c.origFri Nov 11 00:20:05 2005
+++ server/mpm/worker/fdqueue.cSun Apr 30 10:37:38 2006
@@ -14,6 +14,10 @@
* limitations under the License.
*/
+#ifdef __FreeBSD__
+#include <sys/types.h>
+#include <machine/atomic.h>
+#endif
#include "fdqueue.h"
#include "apr_atomic.h"
@@ -43,8 +47,14 @@
if (first_pool == NULL) {
break;
}
+#ifdef __FreeBSD__
+ if (atomic_cmpset_ptr((volatile uintptr_t *)&(qi->recycled_pools),
+ (uintptr_t)first_pool,
+ (uintptr_t)first_pool->next)) {
+#else
if (apr_atomic_casptr((volatile void**)&(qi->recycled_pools), first_pool->next,
first_pool) == first_pool) {
+#endif
apr_pool_destroy(first_pool->pool);
}
}
@@ -96,9 +106,15 @@
new_recycle->pool = pool_to_recycle;
for (;;) {
new_recycle->next = queue_info->recycled_pools;
+#ifdef __FreeBSD__
+ if (atomic_cmpset_ptr((volatile uintptr_t *)&(queue_info->recycled_pools),
+ (uintptr_t)new_recycle->next,
+ (uintptr_t)new_recycle)) {
+#else
if (apr_atomic_casptr((volatile void**)&(queue_info->recycled_pools),
new_recycle, new_recycle->next) ==
new_recycle->next) {
+#endif
break;
}
}
--- server/mpm/worker/fdqueue.c.origFri Nov 11 00:20:05 2005
+++ server/mpm/worker/fdqueue.cSun Apr 30 10:37:38 2006
@@ -14,6 +14,10 @@
* limitations under the License.
*/
+#ifdef __FreeBSD__
+#include <sys/types.h>
+#include <machine/atomic.h>
+#endif
#include "fdqueue.h"
#include "apr_atomic.h"
@@ -43,8 +47,14 @@
if (first_pool == NULL) {
break;
}
+#ifdef __FreeBSD__
+ if (atomic_cmpset_ptr((volatile uintptr_t *)&(qi->recycled_pools),
+ (uintptr_t)first_pool,
+ (uintptr_t)first_pool->next)) {
+#else
if (apr_atomic_casptr((volatile void**)&(qi->recycled_pools), first_pool->next,
first_pool) == first_pool) {
+#endif
apr_pool_destroy(first_pool->pool);
}
}
@@ -96,9 +106,15 @@
new_recycle->pool = pool_to_recycle;
for (;;) {
new_recycle->next = queue_info->recycled_pools;
+#ifdef __FreeBSD__
+ if (atomic_cmpset_ptr((volatile uintptr_t *)&(queue_info->recycled_pools),
+ (uintptr_t)new_recycle->next,
+ (uintptr_t)new_recycle)) {
+#else
if (apr_atomic_casptr((volatile void**)&(queue_info->recycled_pools),
new_recycle, new_recycle->next) ==
new_recycle->next) {
+#endif
break;
}
}
278263
2006/04/30(日) 13:08:24ID:0J9aTQO80 @@ -163,7 +179,7 @@
* now nonzero, it's safe for this function to
* return immediately.
*/
- if (queue_info->idlers == 0) {
+ while (queue_info->idlers == 0) {
rv = apr_thread_cond_wait(queue_info->wait_for_idler,
queue_info->idlers_mutex);
if (rv != APR_SUCCESS) {
@@ -190,8 +206,14 @@
if (first_pool == NULL) {
break;
}
+#ifdef __FreeBSD__
+ if (atomic_cmpset_ptr((volatile uintptr_t*)&(queue_info->recycled_pools),
+ (uintptr_t)first_pool,
+ (uintptr_t)first_pool->next)) {
+#else
if (apr_atomic_casptr((volatile void**)&(queue_info->recycled_pools), first_pool->next,
first_pool) == first_pool) {
+#endif
*recycled_pool = first_pool->pool;
break;
}
* now nonzero, it's safe for this function to
* return immediately.
*/
- if (queue_info->idlers == 0) {
+ while (queue_info->idlers == 0) {
rv = apr_thread_cond_wait(queue_info->wait_for_idler,
queue_info->idlers_mutex);
if (rv != APR_SUCCESS) {
@@ -190,8 +206,14 @@
if (first_pool == NULL) {
break;
}
+#ifdef __FreeBSD__
+ if (atomic_cmpset_ptr((volatile uintptr_t*)&(queue_info->recycled_pools),
+ (uintptr_t)first_pool,
+ (uintptr_t)first_pool->next)) {
+#else
if (apr_atomic_casptr((volatile void**)&(queue_info->recycled_pools), first_pool->next,
first_pool) == first_pool) {
+#endif
*recycled_pool = first_pool->pool;
break;
}
279263
2006/04/30(日) 13:12:46ID:0J9aTQO80 完了。
変更点は、apr_atomic_casptr() -> atomic_cmpset_ptr() です。
なお、fdqueue.c は以前のパッチがあるので、
このパッチはその変更も取り込んでいます。
変更点は、apr_atomic_casptr() -> atomic_cmpset_ptr() です。
なお、fdqueue.c は以前のパッチがあるので、
このパッチはその変更も取り込んでいます。
280root▲ ★
NGNG281263
2006/04/30(日) 13:34:40ID:0J9aTQO80 >>280
#ifdef __FreeBSD__ になっているのは、
対応に、FreeBSD固有の関数(atomic_cmpset_ptr())を使用しているからです。
で、一応、私のところではこれで直ってるんですが、
apr_atomic_casptr()を使用した場合、どこが問題なのかは、まだわかってないです。
わかる人がいたら、教えて頂けると嬉しいです。。
#ifdef __FreeBSD__ になっているのは、
対応に、FreeBSD固有の関数(atomic_cmpset_ptr())を使用しているからです。
で、一応、私のところではこれで直ってるんですが、
apr_atomic_casptr()を使用した場合、どこが問題なのかは、まだわかってないです。
わかる人がいたら、教えて頂けると嬉しいです。。
282263
2006/04/30(日) 13:50:22ID:0J9aTQO80 apr_atomic_casptr()に問題があるなら、どのOSでも発生するはずですが、
タイミングに依るので、OSによっては問題が起こらない or 起こり難い
はあると思います。
それにしても、、
Apache の ap_queue_info_set_idle() & ap_queue_info_wait_for_idler()
の条件変数とmutexは、もう少し素直なコーディングにしても良いんじゃないかと思う。
できるだけパフォーマンスをUPさせるためにこうなってるのかな。。。
タイミングに依るので、OSによっては問題が起こらない or 起こり難い
はあると思います。
それにしても、、
Apache の ap_queue_info_set_idle() & ap_queue_info_wait_for_idler()
の条件変数とmutexは、もう少し素直なコーディングにしても良いんじゃないかと思う。
できるだけパフォーマンスをUPさせるためにこうなってるのかな。。。
283root▲ ★
NGNG パッチ適用作業中、、、。 < live22
284root▲ ★
NGNG ftp://ftp.peko.2ch.net/pub/patch/apache22/apache-2.2.0-fdqueue.c.patch
285root▲ ★
NGNG 作業完了。< @live22
286root▲ ★
NGNG で、libthr 復活してみるか。 < @ live22
287root▲ ★
NGNG /etc/libmap.conf を元に戻して(有効にして)、
httpd と bbsd を再起動した。 < live22
httpd と bbsd を再起動した。 < live22
288ノtasukeruyo
2006/04/30(日) 20:15:15ID:PUxuVcKTO やはりp2から書き込んでいないのに末尾Pになると悲しくなるのは修正効きませんか?
KDDI-HI31 UP.Browser/6.2.0.5.c.1.100 (GUI) MMP/2.0
KDDI-HI31 UP.Browser/6.2.0.5.c.1.100 (GUI) MMP/2.0
2006/04/30(日) 21:02:33ID:oNtMiNwU0
ID末尾に機種判定が出ない板で、たまたま末尾がPになっただけだったりして
291root▲ ★
NGNG PowerDNS recursor 3.0.1
http://downloads.powerdns.com/documentation/html/changelog.html
http://blog.netherlabs.nl/articles/category/powerdns
高パフォーマンスか。
試してみる価値はあるかも。
live22系での使用とかを考えると、レイテンシが高いといいかな。
http://downloads.powerdns.com/documentation/html/changelog.html
http://blog.netherlabs.nl/articles/category/powerdns
高パフォーマンスか。
試してみる価値はあるかも。
live22系での使用とかを考えると、レイテンシが高いといいかな。
mutex が怪しい?
void *apr_atomic_casptr(volatile void **mem, void *with, const void *cmp)
{
void *prev;
#if APR_HAS_THREADS
apr_thread_mutex_t *lock = hash_mutex[ATOMIC_HASH(mem)];
CHECK(apr_thread_mutex_lock(lock));
prev = *(void **)mem;
if (prev == cmp) {
*mem = with;
}
CHECK(apr_thread_mutex_unlock(lock));
#else
prev = *(void **)mem;
if (prev == cmp) {
*mem = with;
}
#endif /* APR_HAS_THREADS */
return prev;
}
void *apr_atomic_casptr(volatile void **mem, void *with, const void *cmp)
{
void *prev;
#if APR_HAS_THREADS
apr_thread_mutex_t *lock = hash_mutex[ATOMIC_HASH(mem)];
CHECK(apr_thread_mutex_lock(lock));
prev = *(void **)mem;
if (prev == cmp) {
*mem = with;
}
CHECK(apr_thread_mutex_unlock(lock));
#else
prev = *(void **)mem;
if (prev == cmp) {
*mem = with;
}
#endif /* APR_HAS_THREADS */
return prev;
}
293root▲ ★
NGNG ex11, ex14 にも適用しておこう。< 上記Apache2.2のパッチ
296263
2006/05/01(月) 07:02:25ID:S0NHnq+v0 全OS対応の汎用パッチも作ってみました。
このパッチでも、Apacheが落ちずに使えてます。
>>292 >>294
下記パッチで修正されることから考えるに、apr_atomic_casptr()自身よりも
その使い方に問題があると思われます。
apr_atomic_casptr()が成功した場合、new_recycleがキューにpushされたということであり、
一旦キューに入ったからには、apr_atomic_casptr()からreturnしてきた段階で、
既にpopされて別のところで使われているかもしれません。
そういう意味で、new_recycle->nextを比較演算子の右辺として使うのは
よろしくないんじゃないかと思います。
なお、このパッチは汎用なので、
FreeBSDの場合は >>277-278 のパッチを使用した方がちょっとだけ速いです。
--- server/mpm/worker/fdqueue.c.origMon May 1 05:56:14 2006
+++ server/mpm/worker/fdqueue.cMon May 1 06:08:02 2006
@@ -95,10 +95,10 @@
sizeof(*new_recycle));
new_recycle->pool = pool_to_recycle;
for (;;) {
- new_recycle->next = queue_info->recycled_pools;
+ struct recycled_pool *prev;
+ prev = new_recycle->next = queue_info->recycled_pools;
if (apr_atomic_casptr((volatile void**)&(queue_info->recycled_pools),
- new_recycle, new_recycle->next) ==
- new_recycle->next) {
+ new_recycle, prev) == prev) {
break;
}
}
@@ -163,7 +163,7 @@
* now nonzero, it's safe for this function to
* return immediately.
*/
- if (queue_info->idlers == 0) {
+ while (queue_info->idlers == 0) {
rv = apr_thread_cond_wait(queue_info->wait_for_idler,
queue_info->idlers_mutex);
if (rv != APR_SUCCESS) {
このパッチでも、Apacheが落ちずに使えてます。
>>292 >>294
下記パッチで修正されることから考えるに、apr_atomic_casptr()自身よりも
その使い方に問題があると思われます。
apr_atomic_casptr()が成功した場合、new_recycleがキューにpushされたということであり、
一旦キューに入ったからには、apr_atomic_casptr()からreturnしてきた段階で、
既にpopされて別のところで使われているかもしれません。
そういう意味で、new_recycle->nextを比較演算子の右辺として使うのは
よろしくないんじゃないかと思います。
なお、このパッチは汎用なので、
FreeBSDの場合は >>277-278 のパッチを使用した方がちょっとだけ速いです。
--- server/mpm/worker/fdqueue.c.origMon May 1 05:56:14 2006
+++ server/mpm/worker/fdqueue.cMon May 1 06:08:02 2006
@@ -95,10 +95,10 @@
sizeof(*new_recycle));
new_recycle->pool = pool_to_recycle;
for (;;) {
- new_recycle->next = queue_info->recycled_pools;
+ struct recycled_pool *prev;
+ prev = new_recycle->next = queue_info->recycled_pools;
if (apr_atomic_casptr((volatile void**)&(queue_info->recycled_pools),
- new_recycle, new_recycle->next) ==
- new_recycle->next) {
+ new_recycle, prev) == prev) {
break;
}
}
@@ -163,7 +163,7 @@
* now nonzero, it's safe for this function to
* return immediately.
*/
- if (queue_info->idlers == 0) {
+ while (queue_info->idlers == 0) {
rv = apr_thread_cond_wait(queue_info->wait_for_idler,
queue_info->idlers_mutex);
if (rv != APR_SUCCESS) {
■ このスレッドは過去ログ倉庫に格納されています