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

**root▲ ★** · NG

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

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

等を取り扱います。

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

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/27(木) 01:50:56

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

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

**root▲ ★** · NG

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 となります。

**root▲ ★** · NG

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

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

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/27(木) 02:09:40

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

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

・・・あれっ？

**動け動けウゴウゴ２ちゃんねる** · 2006/04/27(木) 02:12:40

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

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

**root▲ ★** · NG

西村様、菊池様;

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

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

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

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

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

**root▲ ★** · NG

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

**root▲ ★** · NG

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

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

**root▲ ★** · NG

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

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

ということで残作業は、

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

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

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

株価【600】 : ◆SEXY...t7c · NG

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

**七宝焼 ★** · NG

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

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

**stream** ◆PNstream2s · 2006/04/27(木) 10:57:48

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

株価【600】 : ◆SEXY...t7c · NG

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

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

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

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

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

◆XejmK2zG7E · 2006/04/27(木) 11:35:29

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

**root▲ ★** · NG

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

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

◆PyBmQVnXTM · 2006/04/27(木) 12:03:55

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

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

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

**root▲ ★** · NG

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

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

**root▲ ★** · NG

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

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

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

◆PyBmQVnXTM · 2006/04/27(木) 15:35:13

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で書き込み

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

**root▲ ★** · NG

>>238
了解しました。

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

◆PyBmQVnXTM · 2006/04/27(木) 17:24:20

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

**カイト** · 2006/04/27(木) 19:05:12

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

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

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

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

そしてお湯を沸かす
↓

▲ ◆SANUKI/VII · NG

VIPでやれ

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

怒られる
↓

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

讃岐あぼん

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

出来上がりです！

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

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

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

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

**root▲ ★** · NG

さっき、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

**root▲ ★** · NG

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

明らかに、挙動不審だ。

**root▲ ★** · NG

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

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

**root▲ ★** · NG

#XXX#MaxKeepAliveRequests 100
↓
MaxKeepAliveRequests 0

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

株価【600】 ▲ ◆cZfSunOs.U · 2006/04/27(木) 23:41:38

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/27(木) 23:54:34

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

株価【600】 ▲ ◆cZfSunOs.U · 2006/04/27(木) 23:58:12

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

**stream** ◆PNstream2s · 2006/04/28(金) 00:12:56

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

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

**root▲ ★** · NG

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

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

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

**root▲ ★** · NG

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

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

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

**root▲ ★** · NG

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

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

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の問題なのかは不明です。

株価【700】 ▲ ◆cZfSunOs.U · 2006/04/29(土) 11:02:03

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

**軍艦焼 ★** · 2006/04/29(土) 11:07:12

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

ご報告まで。

株価【700】 ▲ ◆cZfSunOs.U · 2006/04/29(土) 11:20:38

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

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

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

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

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

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

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

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

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

**root▲ ★** · NG

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

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

**root▲ ★** · NG

>>270 補足

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

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

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

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

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

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

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

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

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

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

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

**263** · 2006/04/30(日) 12:05:34

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

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

**263** · 2006/04/30(日) 13:06:17

長いので、分けて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;
}
}

**263** · 2006/04/30(日) 13:08:24

@@ -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;
}

**263** · 2006/04/30(日) 13:12:46

完了。

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

**root▲ ★** · NG

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

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

**263** · 2006/04/30(日) 13:34:40

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

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

**263** · 2006/04/30(日) 13:50:22

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

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

**root▲ ★** · NG

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

**root▲ ★** · NG

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

**root▲ ★** · NG

作業完了。< @live22

**root▲ ★** · NG

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

**root▲ ★** · NG

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

**ﾉtasukeruyo** · 2006/04/30(日) 20:15:15

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

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

**root▲ ★** · NG

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

**動け動けウゴウゴ２ちゃんねる** · 2006/04/30(日) 21:02:33

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

**root▲ ★** · NG

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

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

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

株価【650】 ▲ ◆cZfSunOs.U · 2006/04/30(日) 22:24:59

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

**root▲ ★** · NG

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

**root▲ ★** · NG

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

**root▲ ★** · NG

>>293 done.

**263** · 2006/05/01(月) 07:02:25

全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) {

**root▲ ★** · NG

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

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

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

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

**root▲ ★** · NG

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

**root▲ ★** · NG

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

ううむ。

**root▲ ★** · NG

signal 10問題、簡単なまとめ

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

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

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

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

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

**動け動けウゴウゴ２ちゃんねる** · 2006/05/01(月) 13:04:06

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

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

**root▲ ★** · NG

6.1-RC2

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

◆TWARamEjuA · NG

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

**動け動けウゴウゴ２ちゃんねる** · 2006/05/01(月) 17:45:34

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

**root▲ ★** · NG

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

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

**動け動けウゴウゴ２ちゃんねる** · 2006/05/01(月) 20:49:31

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

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

**root▲ ★** · 2006/05/02(火) 01:36:41

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

対応早。< ports

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

**root▲ ★** · NG

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

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

**root▲ ★** · NG

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

**root▲ ★** · NG

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

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

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

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

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

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

**root▲ ★** · NG

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

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

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

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

◆FUGOUFZVvA · 2006/05/02(火) 18:42:21

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

**root▲ ★** · NG

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

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

**root▲ ★** · NG

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

**動け動けウゴウゴ２ちゃんねる** · 2006/05/02(火) 18:53:49

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

**root▲ ★** · NG

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

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

**動け動けウゴウゴ２ちゃんねる** · 2006/05/02(火) 19:01:01

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

◆FUGOUFZVvA · 2006/05/02(火) 19:16:34

了解しました

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

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

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

**root▲ ★** · NG

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

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

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

です。

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

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