2ch特化型サーバ・ロケーション構築作戦のスレッドです。
・2ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更関連の各種作業や調整事項
・2ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携
等を取り扱います。
現在、複数サーバによる連携により、
サーバ能力のさらなるスケールアップをめざすための「雪だるま作戦」が進行中です。
しかし、問題はあらゆる意味で山積の状態です。
また「2ちゃんねる証券取引所」をはじめとする「株」関連や「Be」の機能強化、
あるいは、次世代の携帯アクセス環境をめざした「べっかんこ作戦」の状況など、
気候も暖かくなり、そろそろ気になりだす季節にさしかかりつつある今日この頃、
あいかわらず2ちゃんねるは、刻一刻と確実に変化し続けています。
探検
2ch特化型サーバ・ロケーション構築作戦 Part21
■ このスレッドは過去ログ倉庫に格納されています
1root▲ ★
NGNG237root▲ ★
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) {
297root▲ ★
NGNG >>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 していました。
通常状態でのものなので原因違うかもですが、一応。
おつです。
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 していました。
通常状態でのものなので原因違うかもですが、一応。
298root▲ ★
NGNG (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
...
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
...
299root▲ ★
NGNG 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)
ううむ。
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)
ううむ。
300root▲ ★
NGNG signal 10問題、簡単なまとめ
1) 通常状態で散発的に発生(全サーバ)
httpd子プロセスの一つが散発的にsignal 10で落ちる
負荷にあんまり関係ないっぽい
2) 高負荷状態で集中的に発生(live22)
httpd子プロセスがたくさんsignal 10で落ちる
高負荷時に発生している模様
ということで上のほうのパッチで 2) が直るといいかなと。
1) 通常状態で散発的に発生(全サーバ)
httpd子プロセスの一つが散発的にsignal 10で落ちる
負荷にあんまり関係ないっぽい
2) 高負荷状態で集中的に発生(live22)
httpd子プロセスがたくさんsignal 10で落ちる
高負荷時に発生している模様
ということで上のほうのパッチで 2) が直るといいかなと。
2006/05/01(月) 13:04:06ID:J451Dwo00
302root▲ ★
NGNG 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
%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
2006/05/01(月) 17:45:34ID:bDtDitjaO
thttpdはcgiをBasicサポトしてます。
というのを知ったがどうにも私ゃ知らん。
明日からCプログラミングを習います、はい。
というのを知ったがどうにも私ゃ知らん。
明日からCプログラミングを習います、はい。
305root▲ ★
NGNG2006/05/01(月) 20:49:31ID:6BqJQb+40
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にいっぱい修正が入ってます。
http://www.apache.org/dist/httpd/Announcement2.0.html
http://www.apache.org/dist/httpd/Announcement2.2.html
2.2.2のほうはmod_proxyにいっぱい修正が入ってます。
307root▲ ★
2006/05/02(火) 01:36:41ID:???0 >>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
ぼちぼち、入れてみるか。
%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
ぼちぼち、入れてみるか。
308root▲ ★
NGNG ./srclib/apr/dso/unix/dso.c と
./server/mpm/worker/fdqueue.c へのパッチは、
そのまま必要がありそうですね(変わっていない)。
食事の後ででも、ごにょごにょと。
./server/mpm/worker/fdqueue.c へのパッチは、
そのまま必要がありそうですね(変わっていない)。
食事の後ででも、ごにょごにょと。
310root▲ ★
NGNG 電源ですが、各方面からの情報により以下のことがわかりました。
1) 現在、以下のサーバが同じ主幹(MasterSwitch)からとられている。
live22, live22x1, live22x2, live22x3, live22x4, live22x5, cobra2247(= live22-2 候補),
news19, hobby7
2) この主幹の電源は現在、ほぼおなかいっぱいの状態である。
3) live22x4, live22x5, cobra2247 は現在遊んでいる。
フル稼働させるには、電源系統のリアレンジが必要と考えられる。
4) XOロケーションには、余裕のある主幹が別にある。
1) 現在、以下のサーバが同じ主幹(MasterSwitch)からとられている。
live22, live22x1, live22x2, live22x3, live22x4, live22x5, cobra2247(= live22-2 候補),
news19, hobby7
2) この主幹の電源は現在、ほぼおなかいっぱいの状態である。
3) live22x4, live22x5, cobra2247 は現在遊んでいる。
フル稼働させるには、電源系統のリアレンジが必要と考えられる。
4) XOロケーションには、余裕のある主幹が別にある。
311root▲ ★
NGNG で、最初は、news19 と hobby7 の XO 外への移設を考えていました。
しかし、今後これらのサーバもかなり近い近未来に雪だるまの一員になることが
じゅうぶんありうるのかなと、思いました。
ということで現在サービスインしていない 3) のサーバ3台を、
4) の主幹に移動するのが、いちばんよい気がしてきました。
問題なければ、この路線で Jim さんと Ryan さん(現地電源関係担当)に、
相談してみようかなと。
しかし、今後これらのサーバもかなり近い近未来に雪だるまの一員になることが
じゅうぶんありうるのかなと、思いました。
ということで現在サービスインしていない 3) のサーバ3台を、
4) の主幹に移動するのが、いちばんよい気がしてきました。
問題なければ、この路線で Jim さんと Ryan さん(現地電源関係担当)に、
相談してみようかなと。
313root▲ ★
NGNG 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 でも、発生すると。
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 でも、発生すると。
2006/05/02(火) 18:53:49ID:gD/Ndbla0
>>313
corefileも、やっぱり同じ感じで役に立たないですか?
corefileも、やっぱり同じ感じで役に立たないですか?
316root▲ ★
NGNG >>315
状況は全く同じですね。
まだ core 一つしか調べてないですが。
今の方針は明確に「勝ちに行く」なので、
修正が入っているはずの、最新の OS にバージョンアップをする予定。
ゴールデンウィーク明けまでに 6.1R が出ない場合、
6.1-RC2 でいこうと。
状況は全く同じですね。
まだ core 一つしか調べてないですが。
今の方針は明確に「勝ちに行く」なので、
修正が入っているはずの、最新の OS にバージョンアップをする予定。
ゴールデンウィーク明けまでに 6.1R が出ない場合、
6.1-RC2 でいこうと。
2006/05/02(火) 19:01:01ID:gD/Ndbla0
319モーマン☆鯛。
NGNG 乗り遅れ…
>>310
電源について,主幹と有りますが,そう呼んでしまうとトランス2次側からの電源が別系統で と
受け取ってしまいます。
要は「分電盤のブレーカーに空きがある」ということで良いのかしら?
という前提で 3)ですが,フル稼働時で万が一落ちた時に切り離し及び復帰が
問題なく行えるのか心配だったり。
逆に,x1〜x5がひとつのバックエンドとして利用でき,切り離し・復帰が問題なく行えるであろうと言うのであれば,
─live22
┌live22x1
├live22x2
└live22x3
┌live22x4
└live22x5
という具合に3系統に分けられると,フロントが落ちた時以外は冗長化が容易では無いかと。
>>310
電源について,主幹と有りますが,そう呼んでしまうとトランス2次側からの電源が別系統で と
受け取ってしまいます。
要は「分電盤のブレーカーに空きがある」ということで良いのかしら?
という前提で 3)ですが,フル稼働時で万が一落ちた時に切り離し及び復帰が
問題なく行えるのか心配だったり。
逆に,x1〜x5がひとつのバックエンドとして利用でき,切り離し・復帰が問題なく行えるであろうと言うのであれば,
─live22
┌live22x1
├live22x2
└live22x3
┌live22x4
└live22x5
という具合に3系統に分けられると,フロントが落ちた時以外は冗長化が容易では無いかと。
320root▲ ★
NGNG >>319
> 電源について,主幹と有りますが,そう呼んでしまうとトランス2次側からの電源が別系統で と
> 受け取ってしまいます。
すみませんです。
私の電気屋的知識は、所詮門前のなんたら。
> 要は「分電盤のブレーカーに空きがある」ということで良いのかしら?
です。
> という具合に3系統に分けられると,フロントが落ちた時以外は冗長化が容易では無いかと。
なるほどです。
ただまだ全貌を掌握しているわけではないので、
まずは一歩ずつ進めていこうかなと。
> 電源について,主幹と有りますが,そう呼んでしまうとトランス2次側からの電源が別系統で と
> 受け取ってしまいます。
すみませんです。
私の電気屋的知識は、所詮門前のなんたら。
> 要は「分電盤のブレーカーに空きがある」ということで良いのかしら?
です。
> という具合に3系統に分けられると,フロントが落ちた時以外は冗長化が容易では無いかと。
なるほどです。
ただまだ全貌を掌握しているわけではないので、
まずは一歩ずつ進めていこうかなと。
321root▲ ★
NGNG >>317
(gdb) thread 73
[Switching to thread 73 (Thread 0x81d5e00 (LWP 101639))]#0 0x2828b4b3 in kill
() from /lib/libc.so.6
(gdb) info frame
Stack level 0, frame at 0xbc0c5a40:
eip = 0x2828b4b3 in kill; saved eip Cannot access memory at address 0xbc0c5a3c
(gdb) info registers
eax 0x0 0
ecx 0xc3ae7fec -1011974164
edx 0xf7f5 63477
ebx 0xa 10
esp 0xbc0c5a3c 0xbc0c5a3c
ebp 0xbc0c5a58 0xbc0c5a58
esi 0x285c5000 677138432
edi 0x3c9 969
eip 0x2828b4b3 0x2828b4b3
eflags 0x200296 2097814
cs 0x33 51
ss 0x3b 59
ds 0x3b 59
es 0x3b 59
fs 0x3b 59
gs 0x1b 27
(gdb) thread 73
[Switching to thread 73 (Thread 0x81d5e00 (LWP 101639))]#0 0x2828b4b3 in kill
() from /lib/libc.so.6
(gdb) info frame
Stack level 0, frame at 0xbc0c5a40:
eip = 0x2828b4b3 in kill; saved eip Cannot access memory at address 0xbc0c5a3c
(gdb) info registers
eax 0x0 0
ecx 0xc3ae7fec -1011974164
edx 0xf7f5 63477
ebx 0xa 10
esp 0xbc0c5a3c 0xbc0c5a3c
ebp 0xbc0c5a58 0xbc0c5a58
esi 0x285c5000 677138432
edi 0x3c9 969
eip 0x2828b4b3 0x2828b4b3
eflags 0x200296 2097814
cs 0x33 51
ss 0x3b 59
ds 0x3b 59
es 0x3b 59
fs 0x3b 59
gs 0x1b 27
322root▲ ★
NGNG (gdb) thread 14
[Switching to thread 14 (Thread 0x8249900 (LWP 100922))]#0 0x2828b4b3 in kill
() from /lib/libc.so.6
(gdb) where
#0 0x2828b4b3 in kill () from /lib/libc.so.6
Cannot access memory at address 0xb858aa3c
(gdb) info frame
Stack level 0, frame at 0xb858aa40:
eip = 0x2828b4b3 in kill; saved eip Cannot access memory at address 0xb858aa3c
(gdb) info registers
eax 0x0 0
ecx 0xab590bbd -1420227651
edx 0xf7f5 63477
ebx 0xa 10
esp 0xb858aa3c 0xb858aa3c
ebp 0xb858aa58 0xb858aa58
esi 0x285b2000 677060608
edi 0xa7 167
eip 0x2828b4b3 0x2828b4b3
eflags 0x200296 2097814
cs 0x33 51
ss 0x3b 59
ds 0x3b 59
es 0x3b 59
fs 0x3b 59
gs 0x1b 27
[Switching to thread 14 (Thread 0x8249900 (LWP 100922))]#0 0x2828b4b3 in kill
() from /lib/libc.so.6
(gdb) where
#0 0x2828b4b3 in kill () from /lib/libc.so.6
Cannot access memory at address 0xb858aa3c
(gdb) info frame
Stack level 0, frame at 0xb858aa40:
eip = 0x2828b4b3 in kill; saved eip Cannot access memory at address 0xb858aa3c
(gdb) info registers
eax 0x0 0
ecx 0xab590bbd -1420227651
edx 0xf7f5 63477
ebx 0xa 10
esp 0xb858aa3c 0xb858aa3c
ebp 0xb858aa58 0xb858aa58
esi 0x285b2000 677060608
edi 0xa7 167
eip 0x2828b4b3 0x2828b4b3
eflags 0x200296 2097814
cs 0x33 51
ss 0x3b 59
ds 0x3b 59
es 0x3b 59
fs 0x3b 59
gs 0x1b 27
323root▲ ★
NGNG とりあえず、二つ分。
2006/05/03(水) 04:45:06ID:qpNDFpsT0
>>321-323
情報どうもです。
ちょっとだけ光が見えてきたような気がします。
こうなるとVMのマップ状態が知りたくなってくるんですが、
/usr/ports/sysutils/procmap を使用して、現在稼働中のhttpdのマップ状態を
見ることは可能でしょうか?
なお、procmapはprocfsを必要としますので、現在mountしてないのでしたら、
一時的にでもmountする必要があります。
あと、kern.dflssiz, kern.maxssiz, kern.sgrowsiz等は設定されてますでしょうか?
また、Apacheの設定でThreadStackSizeは設定されてますでしょうか?
情報どうもです。
ちょっとだけ光が見えてきたような気がします。
こうなるとVMのマップ状態が知りたくなってくるんですが、
/usr/ports/sysutils/procmap を使用して、現在稼働中のhttpdのマップ状態を
見ることは可能でしょうか?
なお、procmapはprocfsを必要としますので、現在mountしてないのでしたら、
一時的にでもmountする必要があります。
あと、kern.dflssiz, kern.maxssiz, kern.sgrowsiz等は設定されてますでしょうか?
また、Apacheの設定でThreadStackSizeは設定されてますでしょうか?
2006/05/03(水) 11:48:39ID:qpNDFpsT0
2006/05/03(水) 11:53:27ID:qpNDFpsT0
次に、>>326の結果を利用して、関数呼び出しの流れが取得可能か試す。
(gdb) p/a *(0xbc0c5a58 + 4)
$11 = ...
(gdb) p/a *(0xXXXXXXXX + 4)
$12 = ...
(gdb) p/a *(0xYYYYYYYY + 4)
...
うまくいけば、関数名が表示されると思います。
(gdb) p/a *(0xbc0c5a58 + 4)
$11 = ...
(gdb) p/a *(0xXXXXXXXX + 4)
$12 = ...
(gdb) p/a *(0xYYYYYYYY + 4)
...
うまくいけば、関数名が表示されると思います。
328root▲ ★
NGNG329む P211018235141.ppp.prin.ne.jp
2006/05/03(水) 18:57:25ID:IAaJAFY00 外からですが、
見ていると、プロセスあたりのスレッド数が32の時のほうが、パフォーマンスは出るような感じですね。
でもそれだと、虫を踏んだ時にLAがめちゃくちゃ上がって、瀕死状態になってしまうと。
見ていると、プロセスあたりのスレッド数が32の時のほうが、パフォーマンスは出るような感じですね。
でもそれだと、虫を踏んだ時にLAがめちゃくちゃ上がって、瀕死状態になってしまうと。
330root▲ ★
NGNG まずは。
live22、signal 10 でのダウン(虫ふみ)多数。
別途解析すすめる予定。
live22, live22x1 は重くなった局面あり。
プライベート接続側の受信バッファがあふれた模様。
May 3 02:30:34 <0.4> tiger2522 kernel: em1: RX overrun
May 3 02:47:17 <0.4> tiger2522 kernel: em1: RX overrun
May 3 05:04:32 <0.4> tiger2522 kernel: em1: RX overrun
May 3 05:00:00 <0.4> tiger2523 kernel: em1: RX overrun
May 3 05:00:00 <0.4> tiger2523 last message repeated 2 times
live22x2 特に異常なし。
live22x3 リブートかかった模様、原因不明(メッセージなし)。
それとは別にこんなメッセージが。
やや不吉なるも、とりあえず経過観察。
May 3 08:49:50 <0.2> tiger2525 kernel: ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=94099079
live22、signal 10 でのダウン(虫ふみ)多数。
別途解析すすめる予定。
live22, live22x1 は重くなった局面あり。
プライベート接続側の受信バッファがあふれた模様。
May 3 02:30:34 <0.4> tiger2522 kernel: em1: RX overrun
May 3 02:47:17 <0.4> tiger2522 kernel: em1: RX overrun
May 3 05:04:32 <0.4> tiger2522 kernel: em1: RX overrun
May 3 05:00:00 <0.4> tiger2523 kernel: em1: RX overrun
May 3 05:00:00 <0.4> tiger2523 last message repeated 2 times
live22x2 特に異常なし。
live22x3 リブートかかった模様、原因不明(メッセージなし)。
それとは別にこんなメッセージが。
やや不吉なるも、とりあえず経過観察。
May 3 08:49:50 <0.2> tiger2525 kernel: ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=94099079
331root▲ ★
NGNG ex14は大きな破綻なしか。
cobra、強いなぁ。
cobra、強いなぁ。
332root▲ ★
NGNG live22x3、また変なリブート入った。
おかしいな。
おかしいな。
333root▲ ★
NGNG live22x3 は、ログインして状況確認中。
メールチェックしてきます。
作業終わっているといいな。
メールチェックしてきます。
作業終わっているといいな。
334root▲ ★
NGNG live22x3、いけませんね。
受付嬢の設定変えて、フロントエンドからはずします。
受付嬢の設定変えて、フロントエンドからはずします。
335root▲ ★
NGNG live22x3 は、ハードウェアトラブルっぽいですね。
いろいろ手配します。
matd の設定いじって、とりあえずフロントエンドからはずしました。
いろいろ手配します。
matd の設定いじって、とりあえずフロントエンドからはずしました。
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- ホンダ日産 経営統合へ 新会社トップはホンダ指名の取締役から [蚤の市★]
- 【芸能】女優・川島海荷、結婚を発表! お相手は競泳・中村克 「これからも変わらず頑張っていきたい」 [冬月記者★]
- 【札幌】ライブのため…小学生の息子を約3日間自宅に放置 脱水症・低血糖にさせた疑い 母親(34)逮捕 ★2 [煮卵★]
- 【スクープ】中居正広が女性との間に重大トラブル、巨額の解決金を支払う 重病から復帰後の会食で深刻な問題が発生 ★30 [Ailuropoda melanoleuca★]
- 日本の家どんどん狭く ステルス値上げで30年前の水準に [蚤の市★]
- イチロー氏、今のメジャーは「退屈」 松井秀喜氏と10年ぶり再会…日本球界への影響も危惧 [王子★]
- 米屋「ごめんね。お米の値段だけど、来年は更に値上がる予想」 [256556981]
- 寿命がまもなく尽きるんだが?
- 「独身男性は狂う」嘘だった。一番キツいのは妻と子供に捨てられた離婚男性 [811796219]
- 🏡【躊躇】須磨都民👶、泣き叫ぶ「助けて!もう毎日毎日すこられるのイヤなの!!!!」
- DeNA濱口 SB三森トレード!!!!
- 京都、女性が刃物で切りつけられる [256556981]