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

虫を踏んだか。
類似例とか、あるのかしら。

【ブリ大根】負荷監視所_20051214
http://live14.2ch.net/test/read.cgi/liveplus/1134552855/523

523 名前： ◆MUMUMUhnYI [sage] 投稿日：2005/12/25(日) 02:51:36 ID:tGhMF0WE0 ?
クラッシュダンプを収容中。(savecore)

vm_thread_new: kstack allocation failed

スタックを、使い切ったっぽい。

http://www.monkey.org/freebsd/archive/freebsd-current/200505/msg00063.html
スレッド数が猛烈に増えるとカーネルメモリを食い尽くすってことですかね．
worker MPM で接続可能クライアント数を増やしたのもありますし(>>601-602)．
そのカーネルメモリ領域を増やすとかできないんですかね......

>>631
in sys/vm/vm_glue.c:

/*
* Get a kernel virtual address for this thread's kstack.
*/
ks = kmem_alloc_nofault(kernel_map,
(pages + KSTACK_GUARD_PAGES) * PAGE_SIZE);
if (ks == 0)
panic("vm_thread_new: kstack allocation failed");
if (KSTACK_GUARD_PAGES != 0) {
pmap_qremove(ks, KSTACK_GUARD_PAGES);
ks += KSTACK_GUARD_PAGES * PAGE_SIZE;
}
td->td_kstack = ks;

となっているのか。

で、in vm/vm_kern.c:

/*
* kmem_alloc_nofault:
*
* Allocate a virtual address range with no underlying object and
* no initial mapping to physical memory. Any mapping from this
* range to physical memory must be explicitly created prior to
* its use, typically with pmap_qenter(). Any attempt to create
* a mapping on demand through vm_fault() will result in a panic.
*/
vm_offset_t
kmem_alloc_nofault(map, size)
vm_map_t map;
vm_size_t size;
{
vm_offset_t addr;
int result;

size = round_page(size);
addr = vm_map_min(map);
result = vm_map_find(map, NULL, 0,
&addr, size, TRUE, VM_PROT_ALL, VM_PROT_ALL, MAP_NOFAULT);
if (result != KERN_SUCCESS) {
return (0);
}
return (addr);
}

#ifndef KSTACK_MAX_PAGES
#define KSTACK_MAX_PAGES 32
#endif

って、なってるですね。(in vm/vm_glue.c)

で、

/*
* Create the kernel stack (including pcb for i386) for a new thread.
* This routine directly affects the fork perf for a process and
* create performance for a thread.
*/
void
vm_thread_new(struct thread *td, int pages)

となっているですね。うむむ。

Googleしてみると、こんな記述が。
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/performance/2005-08/0004.html

Hrm... I'll suggest one tunable:

options KSTACK_MAX_PAGES=32 # Maximum pages to give the kernel stack

Don't crank it up too far, but 64 seems to be a decent number in my
experience. I'd pimp more settings, but given that tuning is still
closer to an art than a science (it wouldn't be if someone catalogued
settings for various applications and hardware combinations, but I
digress), I'll suggest having you take a peak at the various NOTES
files and some of the headers, such as: src/sys/amd64/include/param.h.
I've divulged more in the archives, too. -sc

…でかくしてもよさそうな気がするけど、
よく調べてからでないと、ちと、こわいかも。

さらに。

int kstack_pages = KSTACK_PAGES;
SYSCTL_INT(_kern, OID_AUTO, kstack_pages, CTLFLAG_RD, &kstack_pages, 0, "");

sysctl tunableか。
i386では2、amd64では4の模様。

(live22)
%sysctl -a | grep kstack
kern.kstack_pages: 2

(ex14)
%sysctl -a | grep kstack
kern.kstack_pages: 4

で、さらっとカーネルソースに目を通してみたところでは、
>>636 は、どうも埋め込みのようかん。
つまり、カーネルの再構築が必要と。

とりあえず今日は、こんなところで。

あと、bbsd ですが、そんなわけで -n 24 に減らしましたが、
もっと小さな値でも、いいのかも、かも。

>>637
KSTACK_MAX_PAGESはkernel stack一つ当たりのサイズを
制限するものだから、今回のようなkernel stackの数が増え過ぎのときに
増やすのは逆効果では?

>>641
…とすると、httpdの数とか(今のところまだ相当余裕あり)を
もっと減らした方がいいかもしれんと。

全プロセストータルでのスレッド数が増えすぎないようにということでは，
MaxClients の引き下げとかいうあたりですかね．

# こういうのは，カーネルパニックじゃなくシステムコールのエラーリターンのように
# もっと graceful なやり方にできんものか，とも思ったりもしますが......

>>643
<IfModule worker.c>
StartServers 144
MinSpareThreads 768
MaxSpareThreads 4608
Serverlimit 216
ThreadLimit 32
ThreadsPerChild 32
MaxClients 6912
MaxRequestsPerChild 32000000
MaxMemFree 64000
</IfModule>
↓
<IfModule worker.c>
StartServers 96
MinSpareThreads 512
MaxSpareThreads 3072
Serverlimit 144
ThreadLimit 32
ThreadsPerChild 32
MaxClients 4608
MaxRequestsPerChild 32000000
MaxMemFree 64000
</IfModule>

に変更してみた。@ live22

【ブリ大根】負荷監視所_20051214
http://live14.2ch.net/test/read.cgi/liveplus/1134552855/709

カーネルパニックする前に救い出した。
bbsdが凍り付いて、LAがどんどん上がっている状態だった。

とりあえず、-n 24 を -n 8 にして、
httpdとbbsdをリスタートして、再開。

>>630
よく考えたら、panicの直接の原因はkstack allocation failedだけど、
別の何かが大量にメモリを掴んでいることが真の問題とかいうことも考えられますよね。
# vmstat -mz -M /var/crash/vmcore.1
とかして、何か変わったところとかはありますか?

>>646
http://live22.2ch.net/_service/vmstat-20051225.txt

で、実行時に、
vmstat: not implemented

と、出るです。

>>625
done

>>648
逆引きが stiger10[012345].maido3.com になったのを確認しました。

>>645
>カーネルパニックする前に救い出した。
>bbsdが凍り付いて、LAがどんどん上がっている状態だった。

う〜む......その凍り付いてる時にどんな状態だかがわかればってとこですが......＜bbsd
しかし

http://aa5.2ch.net/test/read.cgi/nanmin/1135352063/164
>[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]

なんですよね...... でも，

http://live14.2ch.net/test/read.cgi/liveplus/1134552855/709
>(killでも死なない、kill -9で死んだ)。

ってことはメインスレッドも凍ってたってことでしょうから，
メインスレッドの状態だけでもわかれば手がかりになるかも......

rootさん、こんばんはーヾ('-')ﾉ

>>650
次回再発したら、精査してみるです。

# /proc を mount しておかないと。

>>651
おひさしぶりです。

むさんいつぞやはお世話になりましたー。
本業も一息つきそうなので、手伝えることがないか
このスレに参加させてもらいますー。

pthread_cond_signal(), pthread_cond_broadcast(), pthread_cond_wait()
pthread_mutex_lock(), pthread_mutex_unlock()
pthread_rwlock_rdlock(), pthread_rwlock_wrlock(), pthread_rwlock_unlock()

これらがエラーになったら abort() するようにしてみますた＜bbsd, matd
通常ならこれらがエラーになるのは考えられないんですが，
その考えられないことが発生してるかも知れないので......
で，abort() すると /tmp に core dump します（setuid プロセスになったりしていなければ）．

>>655
おぉ、入れ替えます。

daemontools的にsetuidgidしていますが、coreは吐くはず、、、。
で、abortしたらdaemontoolsが自動的に立ち上げ直すことになると。

最近は鯖さんが氏んでも即復帰する体制作りやってるんですか？ヾ('-')ﾉ

>>654
こことか、nanminを「雪だるま」で検索してみるとか。

>>657
いろいろですね。
そのへんも、微妙にやっていたり。

「絶対繋がる２ちゃんねる」への道

(´-`).｡ｏＯ(毎分ping撃って、10回連続して返事がなかったらリモートコンソールをリモートで動かしてｺﾞﾆｮｺﾞﾆｮ)

…ということで、DNS登録依頼をするです。
雪だるまシステム開発用になります。

以下の登録をよろしくお願いします。

(新規登録)
+snow.2ch.net:206.223.152.30

>>661
done

snow.2ch.net建設予定地見えました。

やほーでsnow.2ch.net見えますた

>>662
いつもはえーですな

>>rootﾀﾝ
何のことかよくわかりませんが、いつもお世話になっております
これからも頑張ってください

そして、実験用新板が生まれた…
http://snow.2ch.net/alaska/

>>936
ttp://qb5.2ch.net/test/read.cgi/operate/1121886018/255-256
ってことで対応してるみたい。

>>668
これ、まだやってないわけですが、さて。

やらないままに突入すると、どうなるのか。

UNIX timeは別に関係ないから(だって所詮は単なる数値)、
dateコマンドとかローカルタイムにする(zoneinfo読む系)ところで、1秒ずれるのかな。
で、ずっとずれ続けると。

FreeBSDだと、
確か5.4R以降じゃないと2006年の閏秒は入ってないから、
そういうやつ(ほとんどのbanana、かなりのtiger)は、何かしないといけないのかな。

ちょっと調べてまとめて、必要ならmaido3.comの中の人にも作業お願いしようっと。

いろいろ調べ中。

結論からいうと、

FreeBSDでは、デフォルトでは閏秒はシステムに入っていない状態なので、
「デフォルト状態で」「NTPでUTCに対して時間を合わせている限り」、
今回の閏秒挿入に関して、何らかのアクションを起こす必要はない。
つまり、我々は何もする必要がない。

になります。

TAIに合わせている場合(例えばclockspeedとかを使っている場合など)は、
FreeBSDでは最初にそもそも対応が必要だったはずで、
その対応と同じことを、ファイルを更新したうえで、再度やる必要がある。

ことになるはず。

重要なFAQ:

ネットワ−クによる時刻情報提供サービス（NTPサ−ビス）のうるう秒対応
http://jjy.nict.go.jp/news/leaps.html#l4

NTPの取り扱う時刻は1900年１月１日を起点とした時系ですが、
過去のうるう秒を積算していません。積算秒数をお知らせします。
日本標準時で1月1日8時59分60秒(UTCでは12月31日23時59分60秒)と
9時0分0秒（UTCでは1月１日0時0分0秒）は9時0分0秒に相当する
同じ積算秒数をカウントします。

すなわち、60秒と0秒は、同じ時刻を２度カウントすることになります。

こんなページが。djbか。
ほんとに、同じ時刻を2度カウントするのね。すごいな。

http://cr.yp.to/proto/utctai.html

1997-06-30 23:59:59.7 UTC -> 867715199.7 xntpd
1997-06-30 23:59:59.8 UTC -> 867715199.8 xntpd
1997-06-30 23:59:59.9 UTC -> 867715199.9 xntpd
1997-06-30 23:59:60.0 UTC -> 867715200.0 xntpd
1997-06-30 23:59:60.1 UTC -> 867715200.1 xntpd
1997-06-30 23:59:60.2 UTC -> 867715200.2 xntpd
1997-06-30 23:59:60.3 UTC -> 867715200.3 xntpd
1997-06-30 23:59:60.4 UTC -> 867715200.4 xntpd
1997-06-30 23:59:60.5 UTC -> 867715200.5 xntpd
1997-06-30 23:59:60.6 UTC -> 867715200.6 xntpd
1997-06-30 23:59:60.7 UTC -> 867715200.7 xntpd
1997-06-30 23:59:60.8 UTC -> 867715200.8 xntpd
1997-06-30 23:59:60.9 UTC -> 867715200.9 xntpd
1997-07-01 00:00:00.0 UTC -> 867715200.0 xntpd
1997-07-01 00:00:00.1 UTC -> 867715200.1 xntpd
1997-07-01 00:00:00.2 UTC -> 867715200.2 xntpd

ということで、今回の件をまとめると、

0) NTPで時刻あわせをしているシステムでは、
今回何の対応もしなくてよい。
つまり、私もmaido3.comの中の人も、何も作業しなくてよい。

1) ntpdは増える閏秒が発生した場合、
同じ秒を2回繰り返すことにより、つじつま合わせをしている。

2) 結果として今回、1136073600 というUNIX timeな時間が、
２ちゃんねる内において1秒間ではなく、2秒間存在することになる。

3) その際のlocaltime()ライブラリによる時間表示は、
Sun Jan 1 09:00:00 JST 2006 となる。

4) つまり、2006/01/01(日) 08:59:60 という表示が
２ちゃんねるにおいて 投稿日： のところに現れることはなく、
2006/01/01(日) 09:00:00 という表示が、2秒間発生することになる。

ということになるのかなと。

つまり、記念カキコしても無駄ですよと
それはそれで寂しいな

if( time == 1136073600 and $$ % 10 == 0){ $FOX->{なんたら} =~ s/\b09:00:00/08:59:60/ }
wktk

1/1はX:YY:XX.aaにしてみるとか

無駄かな？

ログが2個できて壊れる可能性があると？特にVIP

>>676
どひー。

>>677
面白いかも。

>>678
ある瞬間の1秒が2秒に伸びるだけのはずなので、
それは起こらないはず。

qb6には、Time::HiRes が入ってないのね。

必要なのは一部サーバだけだろうから、
live22xとex14あたりだけ入れてみるとかかなと。

あっち行ったりこっち行ったり大変そうですが頑張ってください。

>>680
http://search.cpan.org/~jhi/BSD-Resource-1.24/Resource.pm
こっちの方が何かと使えたりするかも？

>>682
あ、使えないか、、、λ.....

http://www.bsddiary.net/doc/ntpd-leapseconds.html
># cd /usr/src/share/zoneinfo/
># vi leapseconds
>Leap 1998 の行の下に、以下の行を挿入する。
>Leap 2005 Dec 31 23:59:60 + S
>
># make clean
># make LEAPSECONDS=yes install
># cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

これで「60秒」が出現するのかな......

祭りたいのか？祭りたいんだなｗ

>>684
FreeBSD 5.4R以降では、最初から2005年12月31日のエントリが入っているです。

で、時刻合わせをTAIでやってやれば、できなくはないのかな。
clockspeedとか使ってみるかんじか。

1/100秒対応:

通らないところで、use したものがない場合エラーになるようなので、
syscallで代用。

# 一部サーバではマイクロ秒もとる
if($ENV{SERVER_NAME} =~ /snow|ex14|live22/)
{
# 本当はこっちの方が普通だが、、、
#use Time::HiRes qw( gettimeofday );
#
#($GBX->{NOWTIME}, $GBX->{NOWMICROTIME}) = gettimeofday;
#
# FreeBSD 5.2.1Rなbananaサーバのperlには
# Time::HiResが入っていないので、
# 替わりにsyscallを使うことにする

my $tv = pack("L!L!", ()); # 2つのpackしたlong型変数

require 'sys/syscall.ph';
syscall(&main::SYS_gettimeofday, $tv, undef);

($GBX->{NOWTIME}, $GBX->{NOWMICROTIME}) = unpack("L!L!", $tv);
}
else
{
$GBX->{NOWTIME} = time ; #現在時刻
}

ほいで、

# マイクロ秒の情報がある場合、1/100秒まで表示する
if(defined($GB->{NOWMICROTIME}))
{
my $csec = sprintf("%02d", int($GB->{NOWMICROTIME} / 10000));
$GB->{DATE} .= '.' . $csec;
}

ex11も入れてみたりしない？

eval "use Time::HiRes";
if ($@) {
# Time::HiResが無かったときの処理
$GBX->{NOWMICROTIME} = 1;
}
else {
# Time::HiResがあったときの処理
$GBX->{NOWMICROTIME} = undef;
}
# $GBX->{NOWMICROTIME} = $@ ? 1 : undef; # 1行にしてみるテスト
でもって、、、

$GBX->{NOWTIME} = &getNowTime(鯖名、板名、とかとか♪);
こんな式にしておいて・・・

sub getNowTime{
# 一部サーバではマイクロ秒もとる
return time unless $ENV{SERVER_NAME} =~ /^snow|^ex14|^live22/;
ﾅﾝﾀﾗｶﾝﾀﾗ･･･
}
で値を返してあげるとかとか♪

>>689
入れてみるですかね。

>>690
おぉ、evalすればいいと。

だめっぽいような。

#! /usr/local/bin/perl -w

use strict;
use warnings;

my $seconds = 0;
my $microseconds = 0;
my $centiseconds = 0;

#use Time::HiRes;
eval "use Time::HiRes";

if(!@$)
{
($seconds, $microseconds) = Time::HiRes::gettimeofday;
$centiseconds = sprintf("%02d", int($microseconds / 10000));
};

print $centiseconds;

exit;

で、これを実行すると、

./xx.pl
Bareword "Time::HiRes::gettimeofday" not allowed while "strict subs" in use at ./xx.pl line 15.
Execution of ./xx.pl aborted due to compilation errors.

こうなるですね。

# のところを普通のuseにすれば、動くみたい。

>>693 Time::HiRes::gettimeofday も eval 中に入れたらどうでしょうか．
というか......Time::HiRes が入ってない鯖ではホームディレクトリに
Time::HiRes を入れておいて use lib するとか......

ヒント：$@

ですね

>>694
なるほどです。

>>695
おはずかしい、、、。

うぅむ、、、
こうなったら全鯖perl5.8.xにしてもらおう！

ええと、ひとつ質問です、、、。

いわゆるprefork(シングルスレッド・複数プロセス)な状態でbbsdを動かすことって、
できるんでしたっけか。

さすがに -n 8 は微妙な感じなので、
-n 12 にしてみた。< live22

>>698 シングルスレッド・シングルプロセスなら可能ですが，複数プロセスは
残念ですが対応してません......複数プロセスだと排他制御が大変になるし
（インタープロセスな mutex だとどれかプロセスが死んだ場合の考慮を
しなければならないが，それに必要な pthread_mutexattr_setrobust_np()
が FreeBSD にはない模様，一方 flock() などでやるとなると昔の bbs.cgi と同じ），
subject バッファも共有メモリを使うとかいうことになって，それも大変なので......

まぁ，安全策ならシングルスレッド・シングルプロセス（-DUSE_THREADS なしでビルド）で
動かす形になりますかね．その場合，UDP ソケットのキューイング機能によって処理が
シリアライズされることになります．コンカレンシーはなくなりますが，実際上待ち行列に
入ってもそれほど長時間待たされるということもないかと思いますし......

>>700
> シングルスレッド・シングルプロセスなら可能ですが，複数プロセスは
> 残念ですが対応してません......

やはりそうですか。
理由も含めて納得したです。

> まぁ，安全策ならシングルスレッド・シングルプロセス（-DUSE_THREADS なしでビルド）で
> 動かす形になりますかね．

そですね。
それでどこまでいけるか、ってかんじですか。

そういえば、例のおかしくなっていた時のApache statusって、
L (ログファイル書き込み中)、ばっかりだったんですよね。
普段はほとんど見かけないのですが。

ひょっとしてひょっとすると、mpsafevfs周りに微妙に虫がいるのかも。

calcru: runcalcru: runtime went backwards from 1435168 usec to 1434623 usec for pid 10326 (httpd)
time went backwards from 1380652 usec to 1380546 usec for pid 10327 (httpd)
pid 98776 (httpd), uid 2001: exited on signal 10
pid 10286 (httpd), uid 2001: exited on signal 10
pid 98685 (httpd), uid 2001: exited on signal 10
pid 75181 (httpd), uid 2001: exited on signal 10
pid 10326 (httpd), uid 2001: exited on signal 10
pid 75156 (httpd), uid 2001: exited on signal 10
pid 75165 (httpd), uid 2001: exited on signal 10

さっきと同じか。< 症状
で、LAが急上昇。

もう少し「リアルタイムで」現場を見ないと何とも言えないけど、
直感では、mpsafevfsまわりの虫くさいような気がしないでもない。

書き込み側だけじゃなく読み込み側もドバっと来ると虫がうごめき出すようですね．
mod_cache でバック側からの読み出しを減らせれば虫が冬眠から目覚めにくくなるかも......？

>>705
やはり、Apache 2.2化が急務ですか。

>>706 まぁ OS 側の虫駆除ができればそれはそれでいいんでしょうけど，
それのめどが立たなければ打てる手はそのあたりかと......

# XXX
debug.mpsafevfs=0

/boot/loader.confに追加してリブートした。

さっきはhttpdとかperl(F15)とかが全部、ufsと言って止まっていた。
かなり高い確率で、mpsafevfsの虫だと思われ。

>>708 を入れる前と、様子が変わったですね。
bbsdがCPUを速いタイミングから、食うようになったです。

前は、半日も動かしてないとbbsdがtopの上位プロセスに出てこなかったのが、
早くから出てくるようになった。

ファイルシステムががGiant lockで動く(5.xまでと同じ)から、
そういうもんなのかなと。

>>709 なるほど......

bbsd のログ見てたら，20:50から20:51の間に落ちて再立ち上げされてたようですね．
abort() なのか SIGSEGV かそのあたりか......となると core 吐いてるかな......？

Sat Dec 31 20:50:00 JST 2005
user CPU time = 0:32:21.009, system CPU time = 0:50:51.806
elapsed time = 126:21:01.139, CPU load = 1.10%

Sat Dec 31 20:51:00 JST 2005
user CPU time = 0:00:00.290, system CPU time = 0:00:00.397
elapsed time = 0:00:17.162, CPU load = 4.00%

この目で見たです。
原因はhttpdか。

>>710
手でやったかも。
/tmp 見てきます。

>>712
一応聞いときますが,楽しいですカー？

live22のhttpdをpreforkに戻した。
今日はこれで動かす予定。

>>713
いやぁ、リンクが遅くて。

セッティング出している時が、一番楽しいですよ。
例えそれが、虫との戦いであっても。

>>715
なればおｋ
体も家庭も無理せんようにねーﾉｼ

mpsafevfs は原因切り分けのため、明日の昼間にでも元に戻そうかなと。

しかし、超ヘビーにアクセスがあるとworker MPMがおかしくなるというのは、
ありそうな話では、あるのかも。

まぁ，worker MPM の 32 threads / process ってのは bbsd でいえば
-n256 (32-256) と同じようなもんですからね．livejupiter で最速1000
やってた時も，そのぐらいのスレッド数だと bbsd もおかしくなってましたし......

preforkにするにあたり、php4のモジュールを切ってメモリを空け、
httpdの応答数を前と同じ(フロントの2倍まで受けつけ)にした。< live22

とりあえず、なんとかなるかなと。

>>718
ありえるですね。

1プロセス4スレッドとか、8スレッドとかぐらいがいいのかなぁ(それでも有用ではある)。

このへん、あんまり情報がないんですよね。
探し方が悪いだけなのかもしれないですが。

でもまずは、とりあえずpreforkで動かして、他が安定したら再度考えるです。
mpsafevfsとかを元に戻して、しばらく動かしてみてからで。

morningcoffeeの設定を戻して、、、。
あとは、live22のmpsafevfsを戻すのか。

これは、落ち着いてからやるか。

PHPを止められないとわかったので(p2/２ちゃんねるプロバイダからの過去ログ参照で使用)、
復活させて、そのぶんサーバ数を減らした。

現在の設定。 @ live22

<IfModule prefork.c>
StartServers 2048
MinSpareServers 256
MaxSpareServers 2048
ServerLimit 4608
MaxClients 4608
MaxRequestsPerChild 1000000
MaxMemFree 2000
</IfModule>

>>722
…って書いた直後に、既にこれはフロント参照にしてあって、
私のかんちがいだったことが判明。
(だって、offlawと一緒じゃん。スロー同期でOK)。

明日、mpsafevfsと一緒に、元に戻そう(PHPはずそう)。

ということで、明日これに変える予定。 @ live22

2304 = フロントひとつ分の最大値
4608 はその倍ということで。

<IfModule prefork.c>
StartServers 2304
MinSpareServers 256
MaxSpareServers 2304
ServerLimit 4608
MaxClients 4608
MaxRequestsPerChild 1000000
MaxMemFree 2000
</IfModule>

そねそね
バックは何もしなくていいはず、、、

>>725
過去ログを読む部分は、既に完全にフロント化できたです。
(そういうわけで、上記はかんちがいでした)

bbs.cgiやread.cgiはフロント化でき、
Samba24とかtimecount/timecloseも別サーバに移動でき、
あとは、ライブなdatを触るとか、subject.txtをごにょごにょするとか、
そのへんですね。

ようは、各種呪文系と。

で、SETTING.TXTをいじるとか、キャップを編集するとかは、
バックに対して唱えることになるです。
あと、過去ログ削除の呪文とかも、そういうことになるのかな。

このへんの整理整頓ができたら、
呪文を唱えた時点で、「こっちで唱えてください」みたいなのを、
表示するかんじにまとめて、呪文そのものは同じやつを配布すればOKにしようなと、
思っていたりするです。

芋ほりは単に =~ s/live22x/live22/ したっす。
先のことは考えていないコードですけど、

>>727
掘るのは、たぶんそれでいけるはずです。

キャップいじるのとかSETTING.TXT変えるのとかも、
唱えるところをかえるだけでいい = 変更不要かなと。

やはり、削除系の各種呪文の対応ですね。これは避けて通れない。
bbsd側の道具はそろえてもらえたので、
おぞうにたべながら、I/Fスレあたりでぼちぼちやっていくかんじで。

初ごにょごにょは、live16, live18, live20, live21のmemoriesへの収容から。

現在、移動中。
live20、なかなか多い。

移動完了。
バイナリread.cgi、offlaw.cgiを入れ替え。
各種配布リスト更新。
f22は既に停止。

DNS更新依頼を出しておくです。
実際の更新は、しばらく後かなと。

ということで、以下のDNS更新依頼をば。

(現在)
+live16:206.223.152.50
+live18:206.223.152.150
+live20:206.223.150.110
+live21:206.223.154.235

(変更後)
+live16:206.223.151.230
+live18:206.223.151.230
+live20:206.223.151.230
+live21:206.223.151.230

どーん

>>732
おぉ、どもです。はやいすね。

変更確認しました。
live18, live20, live21 の TTL が 300 になっているようですが、
live16 同様、86400 でよいと思いますです。

ということで、bbsdもシングルスレッドに。

【伊達巻】負荷監視所_20060101
http://live14.2ch.net/test/read.cgi/liveplus/1136044526/403

シングルスレッドにした後も処理はさばけていたので、
とりあえず、この設定で様子見か。

ということで、虫(?)との戦いは続くと。

あとは、これか。

【伊達巻】負荷監視所_20060101
http://live14.2ch.net/test/read.cgi/liveplus/1136044526/420

こうならないことを祈りたい。

あとはApache 2.2にして、フロントのキャッシュを有効に活用できるようになるかどうかで。
空いた旧live16/20/21のどれかで、新しいhttpdのセッティングを作ってみるか。

【実況】 live22x 鯖 Part7
http://qb5.2ch.net/test/read.cgi/operate/1136038806/443

pid 80132 (httpd), uid 2001: exited on signal 6
pid 80107 (httpd), uid 2001: exited on signal 6
pid 80194 (httpd), uid 2001: exited on signal 6
pid 80026 (httpd), uid 2001: exited on signal 6
pid 80183 (httpd), uid 2001: exited on signal 6
pid 80074 (httpd), uid 2001: exited on signal 6
pid 80214 (httpd), uid 2001: exited on signal 6
...

ううむ、daily処理でhttpdの子供が一斉に。
# 親は死ななかったので、普通に立ち上がったけど。

昨日の挙動不審の影響か。

で、全面的にシングルスレッドにしたことでもしlive22が落ち着いたら、
次はいよいよ、matdを試す時期か。

>>703
>calcru: runcalcru: runtime went backwards from 1435168 usec to 1434623 usec for pid 10326 (httpd)
>time went backwards from 1380652 usec to 1380546 usec for pid 10327 (httpd)

このあたりもちょっと気になるんですが，

http://qb5.2ch.net/test/read.cgi/operate/1129310805/119-121n

ってのもあったようですね．このあたりがキーポイントかも......？


>>737
>次はいよいよ、matdを試す時期か。

いよいよですか．

Security Advisory 何通来るんだろ

>>739
これと言って緊急に対応しなければならなさそうなのは無い？ようなので
大丈夫じゃないっすかねぇ．

と思ったら，[FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:04.ipfw
なるものがありますなぁ．
http://lists.freebsd.org/pipermail/freebsd-announce/2006-January/001037.html

私のところにもぼこすか。
とりあえず、8通じゃなくて4通の模様。

Dear freebsd-announce subscribers,

Due to a scripting bug, the four recent security advisories
(FreeBSD-SA-06:01.texindex, FreeBSD-SA-06:02.ee, FreeBSD-SA-06:03.cpio,
and FreeBSD-SA-06:04.ipfw) were accidentally sent out twice each, first
with the correct subject line of "FreeBSD Security Advisory ..." and
second with the incorrect subject line "FreeBSD Errata Advisory ...".
Don't worry, there are only 4 advisories, not 8.

Sorry for accidentally filling your inboxes,

Colin Percival
FreeBSD Security Officer

>>740
6.0系だけのようですね。
いまいちなので、あとでまとめて作業をば。

=============================================================================
FreeBSD-SA-06:04.ipfw Security Advisory
The FreeBSD Project

Topic: ipfw IP fragment denial of service

Category: core
Module: ipfw
Announced: 2006-01-11
Credits: Oleg Bulyzhin
Affects: FreeBSD 6.0-RELEASE
Corrected: 2006-01-11 08:02:16 UTC (RELENG_6, 6.0-STABLE)
2006-01-11 08:03:18 UTC (RELENG_6_0, 6.0-RELEASE-p2)
CVE Name: CVE-2006-0054

>>741
本家のfreebsd-announceと，日本のannounce-jpへ登録してた
もんだから倍の16通に（＾＾；；
ちょっと困ったもんだ．

ipfw.ko はとりあえず使ってないので、
リブートは不要だと判明(cook81はやってしまいましたが)。

他のはユーザランドなので、たんたんと入れ替えで。

Seanさんからリモートコンソール復活の知らせが入ったので、
bbq = cobra2245 のRAIDのチェック(どうも1台HDDがいまいちらしい)を、
明日昼間にでもやることにしようかと。

bbs.cgi再開発プロジェクト7
http://qb5.2ch.net/test/read.cgi/operate/1130918407/439-440

このスレの >>325-340 あたりを参照ですね。
そんなわけで、なんか面白い結果が出たということで。

>>745
Seanさんに状況の報告と、作業のお願いをしました。
bbqサーバで作業する前に、連絡が入る手はず。

一応、報告

PHP 5.1.2
ttp://www.php.net/ChangeLog-5.php

どのURIをアクセスしても、工事中表示にする設定
リダイレクトだとURIが変わってしまうので、mod_rewriteにて

# XXX kouji
RewriteCond %{REQUEST_URI} /kouji.html
RewriteRule ^(.*) $1 [L]
RewriteRule ^(.*) /kouji.html [L]

>>749 は最後の1行だけについしたくなるんですが、
それだとあえなく500エラーで。

>>749-750
RewriteRule !/?kouji\.html$ /kouji.html [L]

かな......

>>751
うわ、駄目出し入っちゃいました(w。

…ですね。kouji.htmlを含んだり別のところにあったりすると、
アレであると。

>>752 いや，ダメ出しってことでもないんですが，1行にまとめるとこんな感じかなぁと......

>>753
なるほど、、、。
まだまだ、しゅぎょうが必要そうすね。

mod_rewriteって、なんかその昔の(でもないか)sendmail.cfっぽいなと思ったり。

>754
mod_rewriteの解説文には複雑さをsendmailで例えていたような

>>754-755 ですね......
http://httpd.apache.org/docs/2.2/rewrite/
``The great thing about mod_rewrite is it gives you all the configurability and flexibility of Sendmail.
　The downside to mod_rewrite is that it gives you all the configurability and flexibility of Sendmail.''

1/19/2006 0:40 JST ごろ、XOロケーションのサーバに障害発生。
一時的に全サーバへの接続性が失われる。

いくつかのサーバは、電源断が入った模様。
調査結果は追ってここに。

XOにある、電源強制断が入ったサーバ:

tiger503 tiger504 tiger511 tiger512
cobra2245
tiger2508 tiger2510 tiger2511 tiger2512

XOにあるけど、電源強制断が入らなかったサーバ:

tiger509 tiger510
banana402 banana403 banana404 banana405 banana406
banana307
tiger2522 tiger2523 tiger2524 tiger2525
tiger2507 tiger2509

とりあえず現在は、全サーバとも動作している模様。

原因によっては、何らかの根本的対策が必要な予感。

ここで作業します。
緊急事態につき、野次馬カキコ禁止。

live22の板は、全部復帰できたはず。

tiger504 つながらず。
tiger509 電源断入った。復帰必要のはず。

tiger510 電源断入った。 復帰必要のはず。

tiger511 電源断再度入った。

状況から考えて、電源不安でほぼ間違いないですね。
XOロケーション全体で起こっている模様。

アクセスがピーク過ぎるまでは、起こり続ける予感。

で、対応できる現地の人が誰一人オフラインではないので、
根本対応は、日本時間の昼あたりになりそうな予感。

連絡がとれる人は全員ICQ的にオフラインのようです。
つまり、こちらではどうしようもない状況。

とりあえず、JimさんとSeanさんに状況をメール打っておきます。

とりあえず、小康状態か。

tiger504 = game10 ダウンしたままの模様。

Seanさんと連絡とれました。
状況を伝達中。

Sean (02:14 AM) :
Which servers are not online????
Me (02:14 AM) :
Now tiger504 is offline. Please check.
Sean (02:15 AM) :
Please wait while I check it.

d1donly (02:28 AM) :
tiger504 is back up now...
mumumu (02:28 AM) :
Ok, I will check now.

Me (02:53 AM) :
And I found tiger511 is now out of service.
Ping is OK, but other servers are down.
Please reboot it now.
Sean (02:54 AM) :
ok...I will.

障害は2台のサーバを追加したことによる、電源のオーバーロード。
つまり、現地のミス(誰がやったかは不明)。

Seanさんが緊急に電源を繋ぎ変え、障害の原因そのものは修復された模様。

Me (02:44 AM) :
And I have one more question. Do you complete the power rearrangement?
I mean, is the cause of the trouble solved now?
Sean (02:45 AM) :
yes....it has been solved. I sent a completed mail msg just a few minutes ago.

tiger511上がりました。

ファイルシステムが一部損傷しているようなので(datのキャッシュのところ)、
一時的にサービス止めて、リモートコンソールで作業します。

キャッシュ部分が破損していて、squidがおかしくなるようなので、
いったんキャッシュをゼロクリアして、squidを上げなおしました。< tiger511

Me (03:24 AM) :
I received reports from 2ch users all servers of 2ch are normal and back online.
I think the trouble is solved now. Thank you for your work.

But I think this is human error. So, please be careful for your operation.
we serve most biggest BBS service in Japan, so, we are watched by millions
users of Japan always... Please do not forget it, it is very important for us.
Sean (03:28 AM) :
ok....I will remember

Me (03:30 AM) :
Yes. But it is proud for us.
It is very funtastic project that 2ch makes bigger and bigger.
Let's enjoy it together.
Sean (03:31 AM) :
Yes... I agree.
Sean (03:31 AM) :
I am excited for it too....
Me (03:32 AM) :
Ok, I was relieved to see it. Please don't let you down.
But server management is very important work for us, please be careful again.
Me (03:35 AM) :
And now time is 3 AM in Japan, so I feel a little bit sleepy.
I will check the servers for a while and will go to bed.

Thanks again for your quick recovery.

…ということで今日のところは、このぐらいで。

ここには書いてないけど、
もうちょっときついこと(電源オーバーロードは2回目でしょ、とか)もゆったです。
むぎゅー。

c.2ch不具合報告総合スレ4
http://qb5.2ch.net/test/read.cgi/operate/1122639354/959

Jimさんに状況確認したところ、返事が。
昨日の続きだった模様。

全ラックを止める(先日の二の舞)の替わりに、一部サーバの電源系を移動したと。

The mobile phone user power maxed out and our new technician
made a decision to move power immediately or have the entire rack
disconnected from blown circuit breaker.
This was the correct decision to make.
I am very sorry for any inconvenience that you incurred.
Please note that power usage on the servers increases as they become busy
and this is monitored
by pie.

公式p2のサーバ引越しに伴い、
以下のDNSの変更をお願いします。

(変更前)
+p2.2ch.net:210.135.97.178

(変更後)
+p2.2ch.net:210.135.99.5

ぶひー

>>779
変更完了を確認しました。

TTL=86400(通常モード)なので、
浸透には変更後最大1日かかる予定。

http://p2.2ch.net/_service/

というわけで、よろしくです。 < いろんな中の方々

[FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:06.kmem
http://lists.freebsd.org/pipermail/freebsd-announce/2006-January/001043.html
[FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:07.pf
http://lists.freebsd.org/pipermail/freebsd-announce/2006-January/001044.html

でてました．

2ch.se / www.2ch.se 用の土地を作りました。

まだNSが向いていないようですが、
とりあえず従来の形で。

+2ch.se:206.223.150.250
+www.2ch.se:206.223.150.250

つまり、2ch.se と www.2ch.se を、
206.223.150.250 に向けていただければ OK です。
アカウント情報は、これからメールするです。

>>783
done

<チラシの裏>

WilTel Communications Looking Glass
http://lookingglass.wcg.net/
Cogent - Looking Glass
http://www.cogentco.com/htdocs/glass.php

</チラシの裏>

>>785
某3DGUIプロジェクトと名前が紛らわしいですなー

あ、むこうのほうが紛らわしいのかw

http://tmp6.2ch.net/
IPアドレス： http://206.223.149.90/~ch2tmp6/
バーチャルホスト変換前： http://banana340.maido3.com/~ch2tmp6/

stock.2ch.net 用の土地を作成しました。

(新規追加)
+stock.2ch.net:206.223.150.250

よろしくです。

チラシの裏。VJってゆうぐらいで。
http://www.lemis.com/grog/Documentation/vj/

Linuxの例みたいだけど、どうもいろいろ面白そうらしい。

ということで、tmp5.2ch.netをmemoriesに収容。
よろしくです。

(現在)
+tmp5.2ch.net:206.223.150.205

(変更後)
+tmp5.2ch.net:206.223.151.230

>>790
done

>>788 も done. なのを確認。

そうだった、、

done です

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/conf/newvers.sh.diff?r1=1.69.2.9&r2=1.69.2.10

6.1-PRERELEASE で、 RELENG_6_1 はまだ切られてないと。

Note that we've entered code freeze and the 6.1-RELEASE cycle has
begun but we're not ready to branch yet so we call it PRERELEASE
between now and when we're ready to branch.

select問題。うむむ。

【チョコ】雪だるま作戦に思いを馳せながら雑談するスレッド Part36
http://aa5.2ch.net/test/read.cgi/nanmin/1138964618/427

> --- sys_generic.c.ORG Thu Jul 7 11:17:55 2005
> +++ sys_generic.c Mon Feb 6 11:28:07 2006
> @@ -678,7 +678,11 @@
> * FD_SETSIZE infds, outfds and exceptfds with the old FD_SETSIZE
> * of 256.
> */
> +#if 1
> + fd_mask s_selbits[howmany(8192, NFDBITS)];
> +#else
> fd_mask s_selbits[howmany(2048, NFDBITS)];
> +#endif
> fd_mask *ibits[3], *obits[3], *selbits, *sbp;
> struct timeval atv, rtv, ttv;
> int error, timo;
> にしたつもり。

【チョコ】雪だるま作戦に思いを馳せながら雑談するスレッド Part36
http://aa5.2ch.net/test/read.cgi/nanmin/1138964618/441-452

ということで、
CFLAGS+= -DFD_SETSIZE=8192
を /etc/make.conf に追加。

これがうまくいくようなら、通常サーバ(tiger/cobra)にも反映が吉か。

>>795 のカーネルソースにあるコメントも含めて考えると、
通常サーバでは CFLAGS+= -DFD_SETSIZE=2048 あたりか。

【チョコ】雪だるま作戦に思いを馳せながら雑談するスレッド Part36
http://aa5.2ch.net/test/read.cgi/nanmin/1138964618/457-469

ということで、

COPTFLAGS+= -DFD_SETSIZE=8192
を /etc/make.conf に追加。
で、カーネル入れ替え。

>>797
これじゃだめで、
/usr/include/sys/select.h をいじるのもだめで、
(/usr/src/sys/sys/select.h があるから)、
結局、

# for increasing FD_SETSIZE
makeoptions CONF_CFLAGS="-DFD_SETSIZE=8192U"

と、カーネルコンフィギュレーションファイルに書いて作り直さないと、
だめらしい。

しかも、いったんクリーンナップして作らないと、バイナリを作り直さない場合が
あるかもしれないらしい。

ということで、

/etc/make.conf:

CFLAGS+=-DFD_SETSIZE=8192U
これを追加。

COPTFLAGS に同様に追加すると、カーネル生成時に副作用があるので、
追加してはいけない(COPTFLAGSmake.conf的には何もしない)。

Apache等は正しく作れたが、これを見ないportsがあるかもしれないので
要注意。

bbsd のように直接makeする場合は、コンパイル時に-DFD_SETSIZE=8192U を
明示的に追加すること。

カーネルmake時の注意は、>>798 のとおり。

>>799
> ということで、
> COPTFLAGS に同様に追加すると、カーネル生成時に副作用があるので、
> 追加してはいけない(COPTFLAGSmake.conf的には何もしない)。

追加してはいけない(COPTFLAGSはmake.conf的には何もしないのがよい)。

rootさんこんばんはーヾ('-')ﾉ

ファイルディスクリプタのチューニングってYahooのApacheでもしてそうだな。

http://public.yahoo.com/~radwin/talks/yapache-apachecon2005.htm

>>802
おぉ、面白い資料をありがとうです。あとで読んでみます。

>>801
こんばんはです。

ttp://blog.bz2.jp/archives/2006/01/yahoo_apache.html
一応これも。

>>804
今読んでいるです。
「うんうん、そうなんだよね」なところ、「おぉー、そうか」なところ、
「そうか、そうやってるのか」なところ、などなど、すんごく参考になるですね。

> 起動と同時に最大数のプロセスを生成する
> プロセスがアイドル状態になっても終了しない

とかはまさに、死ぬほどうなづく、うんうんなところ。

>>806 について補足すると、２ちゃんねるの場合、
そうもいかないところもあるですね。

書き込み主体か読み出し主体かによっても違うし、
いろんな要因があったりするんで。

そのへんは、おいおいまたどっかに書こうかなとは思っていたりするわけですが、
思うに終始しているという話もあったりして。

・FD_SETSIZE=8192 対応カーネル
・FD_SETSIZE=8192 対応Apache2、bbsd
・Apache2 マルチスレッド復活
・bbsd マルチスレッド復活(-n 8)

@ live22

>>808
kern/sys_generic.c パッチバージョン

radwinさんの他のスライドもおもしろいよ

>>810
http://public.yahoo.com/~radwin/

んーむ。面白そうなものばかりだ。
私も、がんがらなきゃ。

rootﾀﾝファイト！

rootﾀﾝ尊敬してます。ファイト!

pid 55164 (httpd), uid 2001: exited on signal 10
pid 55160 (httpd), uid 2001: exited on signal 10
calcru: runtime went backwards from 871422 usec to 871357 usec for pid 55170 (httpd)
pid 55196 (httpd), uid 2001: exited on signal 10
pid 55218 (httpd), uid 2001: exited on signal 10
pid 55157 (httpd), uid 2001: exited on signal 10
pid 55182 (httpd), uid 2001: exited on signal 10
pid 55156 (httpd), uid 2001: exited on signal 10
pid 55184 (httpd), uid 2001: exited on signal 10
pid 55221 (httpd), uid 2001: exited on signal 10
pid 55162 (httpd), uid 2001: exited on signal 10
pid 55167 (httpd), uid 2001: exited on signal 10

虫を踏んだ時のログ。
Apacheリスタートで復活。

calcru: っていうぐらいで、カーネルの虫か?

Apacheかカーネルかライブラリか。

いずれにせよ、あとでいったんシングルスレッドに戻そう。< httpd

やはり、マルチスレッド＊も＊、あやしい模様。

【実況】 live22x 鯖 Part9
http://qb5.2ch.net/test/read.cgi/operate/1139287006/824

824 名前：動け動けウゴウゴ２ちゃんねる：2006/02/11(土) 20:42:41 ID:BYTRitRl0 ?
フジのスレが1008までいった
めちゃいけ　part6
http://live22x.2ch.net/test/read.cgi/livecx/1139657295/
1005 名無しでいいとも！ New! 2006/02/11(土) 20:40:07.79 ID:Go7yoz7N
昔紗理奈もやられてたな
1006 名無しでいいとも！ sage New! 2006/02/11(土) 20:40:08.12 ID:sFKhtQWa
遺留品ｗｗｗｗｗｗｗｗ
1007 名無しでいいとも！ New! 2006/02/11(土) 20:40:08.73 ID:IEqIP2kY
１０００！！
1008 １００１ New! Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

これ、vmwareの話だけど、

http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2005-06/0457.html

%sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast

うーむ、やってみるか。

# suspicious "calcru: runtime went backwards" wordaround
# see http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2005-06/0457.html
kern.timecounter.hardware=TSC

を /etc/sysctl.conf に入れて、

sysctl kern.timecounter.hardware=TSC

を実行。@ live22

>>819 を実施したので、再度様子見。
再発するようなら、MT 再度オフで。

LA=15超えたら、Apacheをリスタートするしくみを入れてみた。
daily処理の時とリスタート後120秒以内は、発動しないようにしたつもり。

# for increasing -DFD_SETSIZE=8192U
.if ${.CURDIR} != "/var/src/libexec/rlogind"
CFLAGS+=-DFD_SETSIZE=8192U
.endif

なんてやらないといかんかった。せめて#undefしてほしいかも。 < rlogind

rlogind.c に、こんなことが直書き。

#define FD_SETSIZE 16 /* don't need many bits for select */

%grep ACPI- /var/run/dmesg.boot
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000

%sysctl -a | grep hz
kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 }

というぐらいで、6.0RでHZが1000になったのが、
微妙に影響していたりするかも、かも。

# とりあえず変えないけど。

で、
%sysctl -a | grep TSC
kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-1000000)
kern.timecounter.hardware: TSC

ここが -100 (品質だめ = 選ばれない)になっていることに気づき、
/usr/src/sys/i386/i386/tsc.c を読むと、

#ifdef SMP
static int smp_tsc;
SYSCTL_INT(_kern_timecounter, OID_AUTO, smp_tsc, CTLFLAG_RDTUN, &smp_tsc, 0,
"Indicates whether the TSC is safe to use in SMP mode");
TUNABLE_INT("kern.timecounter.smp_tsc", &smp_tsc);
#endif

となっていて、

#ifdef SMP
/*
* We can not use the TSC in SMP mode unless the TSCs on all CPUs
* are somehow synchronized. Some hardware configurations do
* this, but we have no way of determining whether this is the
* case, so we do not use the TSC in multi-processor systems
* unless the user indicated (by setting kern.timecounter.smp_tsc
* to 1) that he believes that his TSCs are synchronized.
*/
if (mp_ncpus > 1 && !smp_tsc)
tsc_timecounter.tc_quality = -100;
#endif

ということらしく、

でも、TSCにしてちゃんと動いているということは、
このマザボはたまたま "Some hardware configurations do this"
なやつらしく、

%sysctl -a | grep smp_tsc
kern.timecounter.smp_tsc: 0

のように、デフォルトではオフになっていて、

%sysctl kern.timecounter.smp_tsc=1
sysctl: oid 'kern.timecounter.smp_tsc' is a read only tunable
sysctl: Tunable values are set in /boot/loader.conf

ということなので、sysctl.conf で指定する必要があると。

>>826
× ということなので、sysctl.conf で指定する必要があると。
○ ということなので、/boot/loader.conf で指定する必要があると。

でもどうせ、TSCのクオリティは、

static struct timecounter tsc_timecounter = {
tsc_get_timecount, /* get_timecount */
0, /* no poll_pps */
~0u, /* counter_mask */
0, /* frequency */
"TSC", /* name */
800, /* quality (adjusted in code) */
};

のように、800と決められているようなので、
ACPI-fast(1000)には負ける模様(未確認)。

なので、/boot/loader.conf への追加はどうもしなくてよくて、
/etc/sysctl.conf に TSC を強制選択すると書いておけば、いい模様。

TSCまわりだと、こんなパッチが出てる模様。
http://docs.freebsd.org/cgi/mid.cgi?1835.1139524338
6-stableにマージされるのが楽しみ。

>>829
おぉ、 phk ですか。
わくてかってかんじで。

>>829 のパッチを読んでいますが、
これって calcru をまるっきり置き換えなんすね。
まさに、○○だねみたいな。

# for Torino olympic games
0 17 * * * /usr/local/bin/home-backup.sh /home

@ live22

もともとは 14:00 PST/PDT >>832

今日健康でもLA=10超えたので、
>>821 を LA=20 で発動に変更。

>>819
> # suspicious "calcru: runtime went backwards" wordaround

word => work

# おはずかしい。

>>832
月曜の朝10時にフルダンプするのもいまいちなんで、
あとで、2時間ぐらい早めておこう。

いまさらだけど>>811のradwinさんのスライド読みました。
これはすごいですねーー。
kill -HUP しなくてログローテーションとかどうやるんだろう。
inode変るはずなのに。

>>837
それ用のモジュールあたりかしら。

Apache 2.2系で環境を作るべく、調べ中。
以下、FreeBSDのports的観点でまずは。

・Apache 2.2系では最初からkqueue(2)をサポートしている模様。
- ports作る時のWITH_KQUEUE_SUPPORTは、不要(意味なし)になった。
・configとかが/usr/local/etc/apache22の下に変わる
・同様にモジュールの場所も/usr/local/libexec/apache22の下に変わる

2ch的には、
・mod_cgidsoは再インストールが必要

あたりか。

/usr/local/etc/rc.d/apache22.sh

これも名前が変わる。

#
# Add the following lines to /etc/rc.conf to enable apache22:
# apache22_enable (bool): Set to "NO" by default.
# Set it to "YES" to enable apache22
# apache22_profiles (str): Set to "" by default.
# Define your profiles here.
# apache22limits_enable (bool):Set to "NO" by default.
# Set it to yes to run `limits $limits_args`
# just before apache starts.
# apache22_flags (str): Set to "" by default.
# Extra flags passed to start command.
# apache22limits_args (str): Default to "-e -C daemon"
# Arguments of pre-start limits run.
# apache22_http_accept_enable (bool): Set to "NO" by default.
# Set to yes to check for accf_http kernel
# module on start up and load if not loaded.

のように、accf_http(9)のオン・オフをrc.confに書くようになった。
デフォルトでは入らないので注意。

/usr/ports/CHANGES:

20051108:
AUTHOR: [email protected]
The following changes were introduced:
...
* Add bsd.apache.mk
USE_APACHE knob enhancements

/usr/ports/Mk/bsd.apache.mk:

# Variables definition
# USE_APACHE: Call this script. Values can be:
# <version>: 1.3/13/2.0/20/2.1/2.2/1.3+/2.0+/2.1+/2.2+
# common*: common13, common20, common21 and common22

ということは、/etc/make.conf に、

# added by mumumu, for Apahce 2.2 -- 2006/2/13
USE_APACHE=common22

を追加でいいのかな。

<IfModule dir_module>
DirectoryIndex index.html
</IfModule>

IfModuleの文法が変わったですか。
(多分前のもいけるんでしょうけど)

>>839
>Apache 2.2系で環境を作るべく、調べ中。

いよいよですか．2.2 なら Event MPM も挑戦する価値あるかも．

>・mod_cgidsoは再インストールが必要

それを用いるプログラム (read.cgi 等) もですね．

>>843
> それを用いるプログラム (read.cgi 等) もですね．

おぉ、なるほど。

で、さっきまた症状再発。

アイドルタイムがぐぐぐとなくなり、でもtop的にはプロセスがRUNにならないのに、
ロードアベレージが上がり続けるという、いかにもカーネルのバグっぽい、
謎な状態になる模様。

症状はこれまでと全く同じ。

%grep backward /var/log/messages
Feb 13 10:27:24 <0.2> tiger2522 kernel: calcru: runtime went backwards from 235116018 usec to 235115799 usec for pid 28466 (httpd)
Feb 13 10:28:06 <0.2> tiger2522 kernel: calcru: runtime went backwards from 557817 usec to 557807 usec for pid 17019 (httpd)
Feb 13 10:28:06 <0.2> tiger2522 kernel: calcru: runtime went backwards from 547476 usec to 547431 usec for pid 16997 (httpd)
Feb 13 10:28:21 <0.2> tiger2522 kernel: calcru: runtime went backwards from 1734019 usec to 1733938 usec for pid 16944 (httpd)

2006-02-14 03:26:37.805228500 MaxLA = 20, LA = 2.13818359375
2006-02-14 03:27:07.806554500 MaxLA = 20, LA = 14.9033203125
2006-02-14 03:27:37.808498500 MaxLA = 20, LA = 98.05224609375
2006-02-14 03:27:37.809198500 delta = 1139855257
2006-02-14 03:27:37.809226500 Restarting apache...
2006-02-14 03:27:37.893737500 Performing sanity check on apache2 configuration:
2006-02-14 03:27:38.135912500 Syntax OK
2006-02-14 03:27:38.193105500 Stopping apache2.
2006-02-14 03:27:38.208165500 Waiting for PIDS: 55140, 55140, 55140, 55140, 55140, 55140.
2006-02-14 03:27:50.395771500 Starting apache2.
2006-02-14 03:28:21.037681500 MaxLA = 20, LA = 82.00390625
2006-02-14 03:28:21.037954500 delta = 30
2006-02-14 03:28:21.037975500 delta = 30, not restarting
2006-02-14 03:28:51.038550500 MaxLA = 20, LA = 79.72509765625
2006-02-14 03:28:51.038668500 delta = 60
2006-02-14 03:28:51.038692500 delta = 60, not restarting
2006-02-14 03:29:21.039819500 MaxLA = 20, LA = 49.25634765625
2006-02-14 03:29:21.039891500 delta = 90
2006-02-14 03:29:21.039907500 delta = 90, not restarting
2006-02-14 03:29:51.041112500 MaxLA = 20, LA = 30.40380859375
2006-02-14 03:29:51.041344500 delta = 120
(続く)

2006-02-14 03:29:51.041389500 Restarting apache...
2006-02-14 03:29:51.056401500 Performing sanity check on apache2 configuration:
2006-02-14 03:29:51.104448500 Syntax OK
2006-02-14 03:29:51.121918500 Stopping apache2.
2006-02-14 03:29:51.186926500 Waiting for PIDS: 16927, 16927, 16927.
2006-02-14 03:29:57.209463500 Starting apache2.
2006-02-14 03:30:28.033177500 MaxLA = 20, LA = 53.62548828125
2006-02-14 03:30:28.033181500 delta = 30
2006-02-14 03:30:28.033183500 delta = 30, not restarting
2006-02-14 03:30:58.033944500 MaxLA = 20, LA = 35.7099609375
2006-02-14 03:30:58.034165500 delta = 60
2006-02-14 03:30:58.034201500 delta = 60, not restarting
2006-02-14 03:31:28.035250500 MaxLA = 20, LA = 22.26318359375
2006-02-14 03:31:28.035586500 delta = 90
2006-02-14 03:31:28.035631500 delta = 90, not restarting
2006-02-14 03:31:58.036485500 MaxLA = 20, LA = 12.85009765625
2006-02-14 03:32:28.037717500 MaxLA = 20, LA = 8.75927734375
2006-02-14 03:32:58.038980500 MaxLA = 20, LA = 5.54248046875
2006-02-14 03:33:28.040237500 MaxLA = 20, LA = 3.64404296875
2006-02-14 03:33:58.041496500 MaxLA = 20, LA = 2.49658203125
2006-02-14 03:34:28.042745500 MaxLA = 20, LA = 1.51171875
(以下略)

[Mon Feb 13 10:27:24 2006] [notice] child pid 28437 exit signal Bus error (10)
[Mon Feb 13 10:27:41 2006] [warn] child process 28391 still did not exit, sending a SIGTERM
[Mon Feb 13 10:27:41 2006] [warn] child process 28392 still did not exit, sending a SIGTERM
[Mon Feb 13 10:27:41 2006] [warn] child process 28393 still did not exit, sending a SIGTERM
[Mon Feb 13 10:27:41 2006] [warn] child process 28394 still did not exit, sending a SIGTERM
...
[Mon Feb 13 10:27:47 2006] [error] child process 28391 still did not exit, sending a SIGKILL
[Mon Feb 13 10:27:47 2006] [error] child process 28392 still did not exit, sending a SIGKILL
[Mon Feb 13 10:27:47 2006] [error] child process 28393 still did not exit, sending a SIGKILL
[Mon Feb 13 10:27:47 2006] [error] child process 28394 still did not exit, sending a SIGKILL
...
[Mon Feb 13 10:27:49 2006] [notice] caught SIGTERM, shutting down
[Mon Feb 13 10:27:50 2006] [notice] suEXEC mechanism enabled (wrapper: /usr/local/sbin/suexec)
[Mon Feb 13 10:27:51 2006] [notice] mod_cgidso enabled
[Mon Feb 13 10:27:56 2006] [notice] Apache/2.0.55 configured -- resuming normal operations
[Mon Feb 13 10:28:02 2006] [notice] child pid 16999 exit signal Bus error (10)
[Mon Feb 13 10:28:03 2006] [notice] child pid 16994 exit signal Bus error (10)
[Mon Feb 13 10:28:03 2006] [notice] child pid 16980 exit signal Bus error (10)
[Mon Feb 13 10:28:04 2006] [notice] child pid 17000 exit signal Bus error (10)
...
[Mon Feb 13 10:29:54 2006] [warn] child process 16944 still did not exit, sending a SIGTERM
[Mon Feb 13 10:29:54 2006] [warn] child process 16946 still did not exit, sending a SIGTERM
[Mon Feb 13 10:29:54 2006] [warn] child process 16947 still did not exit, sending a SIGTERM
[Mon Feb 13 10:29:54 2006] [warn] child process 16948 still did not exit, sending a SIGTERM
...
(続く)

ひょっとしてこれが解決策になるかも


ttp://d.hatena.ne.jp/hiro-ueda/20060118

[Mon Feb 13 10:29:56 2006] [notice] caught SIGTERM, shutting down
[Mon Feb 13 10:29:57 2006] [notice] suEXEC mechanism enabled (wrapper: /usr/local/sbin/suexec)
[Mon Feb 13 10:29:58 2006] [notice] mod_cgidso enabled
[Mon Feb 13 10:30:00 2006] [notice] Apache/2.0.55 configured -- resuming normal operations
(ここまで)

>>849
↓
>>817-819

・装置は2回発動
・2回とも死ぬ前に SIGBUS 発生
・1回目はSIGTERMでは死なず、SIGKILLで死んだ
・2回目はSIGTERMで死んだ

今日作ったインストールキット使って、Apache 2.2を入れてみるか。

ついに2.2投入ですか
早朝実況組もいますがざっくり入れちゃっても問題はないと思います。
（どの時間帯に実施しても騒ぎになること必定ですし）

ううーむ。
http://www.atm.tut.fi/list-archive/freebsd-stable-2005/msg08332.html

>>854
カーネルバグっぽいので、ちょっと躊躇していたり。
で、>>855 の件を調べちゅう。

うーむ。
http://www.atm.tut.fi/list-archive/freebsd-stable-2005/msg08344.html

症状は、これなんですよね。
http://www.freebsd.org/cgi/query-pr.cgi?pr=72338

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_resource.c

Revision 1.151 / (download) - annotate - [select for diffs], Mon Jan 23 19:15:13 2006 UTC (3 weeks ago) by ups
Branch: MAIN
Changes since 1.150: +1 -1 lines
Diff to previous 1.150 (colored)

Hopefully fix the "calcru: runtime went backwards from ..." problem by
keeping the resource values locked (where needed) while we use them
for calculations.

MFC after:3 days

…で、これはまだMFCされていない模様。

>>859 は、
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_resource.c.diff?r1=1.150&r2=1.151

===================================================================
RCS file: /usr/local/www/cvsroot/FreeBSD/src/sys/kern/kern_resource.c,v
retrieving revision 1.150
retrieving revision 1.151
diff -u -p -r1.150 -r1.151
--- src/sys/kern/kern_resource.c2005/11/02 21:18:071.150
+++ src/sys/kern/kern_resource.c2006/01/23 19:15:131.151
@@ -35,7 +35,7 @@
*/

#include <sys/cdefs.h>
-__FBSDID("$FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/kern/kern_resource.c,v 1.150 2005/11/02 21:18:07 ps Exp $");
+__FBSDID("$FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/kern/kern_resource.c,v 1.151 2006/01/23 19:15:13 ups Exp $");

#include "opt_compat.h"

@@ -733,8 +733,8 @@ calcru(p, up, sp)
&pcpu_find(td->td_oncpu)->pc_switchtime);
}
}
-mtx_unlock_spin(&sched_lock);
calcru1(p, &rux, up, sp);
+mtx_unlock_spin(&sched_lock);
p->p_rux.rux_uu = rux.rux_uu;
p->p_rux.rux_su = rux.rux_su;
p->p_rux.rux_iu = rux.rux_iu;

…でもこれ、1.154で「ばっさりこん」なんですよね。
>>829 のやつのもより。

うーむうーむ。

>>859
がびーん。

Revision 1.152 / (download) - annotate - [select for diffs], Wed Jan 25 02:05:47 2006 UTC (2 weeks, 5 days ago) by ups
Branch: MAIN
Changes since 1.151: +1 -1 lines
Diff to previous 1.151 (colored)

Back out changes made in rev. 1.151.
They were bogus.

Cluebat applied by: jhb@

いずれにせよ、、、カーネルの虫ってことっぽいのかな。

Apacheを変えるのはそれはそれで意味ありそうなんで、
そっちは、たんたんとやるかんじかなと。

ということで、Apache 2.2.0 を投入。@ live22

TransferLog の動きが、2.0 と違うみたい。

TransferLog "| /usr/local/sbin/logbuffer"

とかやっているのですが、Apache 2.xでは直接起動してくれたlogbufferが、

%ps ax | grep logbuffer
74136 ?? I 0:00.01 /bin/sh -c /usr/local/sbin/logbuffer
74137 ?? S 0:01.30 /usr/local/sbin/logbuffer
74568 p1 S+ 0:00.00 grep logbuffer

のように、sh経由になり、
しかもApacheをリスタートすると、暴走状態で残ってしまうようです。
(kill -TERMで死にはする)

おぉ、Apache 2.2 系列では
今の read.cgi は、そのままではコンパイルできないっぽい。

gcc -c read.c -I`apxs -q INCLUDEDIR` -O2 -Wall -funsigned-char -fPIC -DSNOWMAN -o read.o
In file included from read.c:1:
read.h:11:22: apr_date.h: No such file or directory
read.h:12:25: apr_file_io.h: No such file or directory
read.h:13:21: apr_lib.h: No such file or directory
read.h:14:25: apr_strings.h: No such file or directory
read.h:15:24: apr_tables.h: No such file or directory
read.h:16:22: apr_time.h: No such file or directory
read.h:20:22: apr_want.h: No such file or directory

>864
これですか？

ttp://httpd.apache.org/docs/2.2/ja/mod/mod_log_config.html#logformat

>>866
そうです。で、

TransferLog "| exec /usr/local/sbin/logbuffer"

とすることで、前と同じ動きになりました。
リスタートしても大丈夫でした。

色々、微妙みたい。

>>865
/usr/local/include/apr-1 に入るのかぁ。
ってことは、Makefile 更新しないとってことかい。

-I`apxs -q INCLUDEDIR` -I/usr/local/include/apr-1

とかやって、read.cgi はできる模様。

あとは、例の装置のリスタート部分を2.2対応にすればOKかな。
やっておこう。

で、今日はそろそろみせじまいで。

2.2 稼働ですか，乙です．あとは mod_cache がちゃんと使えるようになれば
バック側の httpd がかなり楽になりますね．

>>869 は、

%apr-1-config --includes
-I/usr/local/include/apr-1

これ使ったほうがよさげ。

で、>>871 (live22x[123]をApache 2.2にする)をそのうち。

(´-`).｡ｏＯ(2.3になると、deny allow がなくなるそうな)

>>873
まじすか。
つまり2.4を使う頃には、あれのしくみ変えないといけないと。

これですね
まだ2.3すら出てないし、これからどうなるか知らないですけど

http://svn.apache.org/repos/asf/httpd/httpd/trunk/CHANGES

*) Authz: Mark the directives 'Order', 'Allow', 'Deny' and 'Satisfy' as
deprecated and move them into the new module mod_access_compat which
can be loaded to provide backwards compatibility for these directives.
[Brad Nicholes]

>>875
mod_access_compat 入れれば、一応互換性は保てることにすると。
たぶん、もっといいしくみにしようってことなのかしら。

このあたりかな......
http://www.mail-archive.com/[email protected]/msg30304.html

フロント2台追加の第一段階(基本セットアップ)ができました。
以下のDNSへの追加をお願いします。

これをDNSに追加することにより、第二段階(掲示板システムに必要なファイル入れたり、
F22をセットアップしたり等)が、できるようになります。

で、それができた後で、ラウンドロビンへの投入
(= DNSに再度追加し、live22x の仲間に入れる)という手順を踏むことになります。

以上、よろしくです。

(新規追加)
+live22x4.2ch.net:206.223.150.110:300
+live22x5.2ch.net:206.223.150.42:300

で、これら2台はApache 2.2 + worker MPMです。

キャッシュ関係はオフです。
どうも、Apache 2.0 で入れていた以下の設定は、そのままではエラーになる模様。
CacheSize なんて知らないよ、って言われたです。

# include cache config file
<IfModule cache_module>
# config cache directory and size
CacheRoot /md/cache
CacheSize 65536
</IfModule>

>>879
そこも設定かわっているみたいですな。

ttp://httpd.apache.org/docs/2.2/ja/mod/mod_disk_cache.html
を参考にすると

<IfModule mod_disk_cache>
# config cache directory and size
CacheRoot /md/cache
CacheMinFileSize 64 #(デフォは1)
CacheMaxFileSize 1000000 #(デフォは1000000)
</IfModule>

などと書くのが正しいようですね。

>>878-879 乙です．
>で、これら2台はApache 2.2 + worker MPMです。

どうせなら，どちらか片方を event MPM にしてみるとか......
http://httpd.apache.org/docs/2.2/mod/event.html

あと，キャッシュ保持時間とかのチューニングの手段は，と......

フロント側 mod_cache のディレクティブ:
    CacheLastModifiedFactor
    CacheMaxExpire

バック側 mod_headers で Cache-Control ヘッダ付加:
    # キャッシュ保持時間が n 秒未満なら再評価なしにキャッシュをそのまま使用
    # その後は conditional GET で再評価する
    Header set Cache-Control s-maxage=n

>>878
そろそろ受付嬢の再投入は？

live22x4,live22x5のIPアドレスを直接ラウンドロビンに
いれるのではなく、受付嬢での振り分け先をlive22x4,live22x5に
して、受付嬢の代表IPアドレスを登録する。

とりあえず、1/4の負荷からはどうでしょう。
おちても、3/4の確率でつながるので、以前ほどはひどくないかと。

>>878
done

>>880 以降へのレスは別途まとめて。

まずは、くーるすれっずにちょっとﾜｸﾃｶしておこうと。

Sun、『UltraSPARC T1』プロセッサの仕様を公開
http://japan.internet.com/webtech/20060215/12.html

>>880 >>882
どもです。
ディスクキャッシュの時は、htcacheclean ってのを動かすかんじなのか。
いろいろ読み中。

>>881
Event MPM
The event MPM uses a seperate thread to handle Keep Alive requests and
accepting connections. Keep Alive requests have traditionally required httpd
to dedicate a worker to handle it. This dedicated worker could not be used
again until the Keep Alive timeout was reached.

おぉ、なんかよさげですね。
入れてみるかな。

>>883
魅力的ですが、一歩一歩やっていこうかなと。
普通にラウンドロビンして、次にmatdか。

で、

フロントは負荷的には足りているような気がするのに、なぜ2つ追加投入するのか

の件ですが(私も疑問を持ちました)、
それは「雪だるまシステム」そのもののテスト、という意味合いがあるとのことです。

ようは、スロー同期とか今の形で構築したシステムが、フロントが増えていっても
ちゃんと動くようになっているかとかを、いまのうちにきちんと試しておきたいと。

どうせ、フロントは増える方向だし、このシステムは将来にわたり使うに違いないので、
いまのうちにきちんとしたものを作っておくほうが、いいんじゃないかなということで。

…ということで、私も納得したと。

で、cobra2247は「コブラをバックエンドにしたらどんなかんじなのか」を試すということで、
バックエンドに仕立てると。

live22x[45] を作る場合の手順:

・器を作る
・フロントパック(フロントにするためのもの一式)を入れる
・スロー同期のための設定をする (live22x[45], live22)
・スロー同期スクリプトを手で動かす
=> それまでの過去ログがどばーっと転送される (要注意)
・cronの設定をする(定時スロー同期開始)
・BBx 等にIPアドレスを登録する

・DNSに live22x[45] を登録する
・投稿のテストをする
・F22/丁稚どん/配布リストに live22x[45] を登録する

・DNSに live22y として追加登録する => 将来は live22b[12] の matd に追加、になる
・ｳﾏｰ

>>887
雪だるまスレのほうがよいのかもしれないけど。
なんとなく、フロントで過去ログをもっているのが厳しいかも。

バックを複数もつとフロントは掛算で過去ログを持ちますよね。
そこが大変そう。

ディスクは十分大きいから大丈夫かもしれないし、
自動的にコピーができるから、バックアップする必要がないという
うれしい点があるかもしれないけど。

メンテを考えると、過去ログは、bbsdを動かすバックエンドとは
別のバックエンドに突っ込むほうがよいのかなと思う。
(dat落ちのタイミングでコピーかな。)

ここらへんも実験！実験！なんでしょうが。

ふむふむ。

そうすれば各フロントが過去ログをバックにとりにいかなくてよくなるから、
バックも軽くできる気がしますね。

cobra2247をバックにしたら、今のtiger2522をそれに転用してみるとか。

新 epg.2ch.net の Apache を、event MPM にしてみた。
設定そのものはこんなかんで、worker MPMと変わるところがないみたい。

<IfModule mpm_event_module>
StartServers 24
ServerLimit 36
MaxClients 1152
MinSpareThreads 128
MaxSpareThreads 768
ThreadsPerChild 32
MaxRequestsPerChild 1000000
ThreadLimit 32
MaxMemFree 64000
</IfModule>

確かに今の過去ログのやり方のままだと，今後大変になるかも知れないんですよね．
とはいえ，ライブな dat と同じように mod_proxy でやると offlaw.cgi の改造が必要だし，
さらに mod_cache を使用するとなると /md を過去ログで食い潰すかも知れないし......

となると，いっそ NFS を使ってみるとか．以前雪だるまでライブな dat の読み出しに
NFS 使ってた時の問題，例えば不規則に dat の内容が壊れるとか ESTALE 発生が
カーネルごとコケる引き金になるとか，そういうのは過去ログでは発生しにくいのでは，
と思えなくもないですし......

ここは一つ、全鯖規模で過去ログの一元化を

>>892
過去ログはフロントでキャッシュする必要はないんじゃないかと。
(CacheDisableで過去ログのURLをはずすことはできないんですかね？)
offlaw.cgiは、誰かさんが泣きながら書き換えてもらって。

NFSは、サーバ間がちょっと密結合になってうれしくないかも。
# 感覚だけですが。

>過去ログはフロントでキャッシュする必要はない

私も原理はそれに賛成。
ただ /doom/kako/ 以下はインデックスなんで各フロントにあった方がいいかと

Yahoo! User Interface Library
ttp://developer.yahoo.net/yui/

|∀･)ﾉ

>>894
>(CacheDisableで過去ログのURLをはずすことはできないんですかね？)

確かに可能ですね．

>offlaw.cgiは、誰かさんが泣きながら書き換えてもらって。

このあたりは，実際に書き換える中の人次第ということで......

>>886
> 普通にラウンドロビンして、次にmatdか。

matdできになっているのは、負荷への耐性がどの程度あるか
わからない点なんですよね。

動作はばっちりだと思うのですが、アプリとして
動くみたいなので、カーネルとの切り替えがばかに
ならないのかなと。
(パケット1個単位で切り替えですよね。)

そんなこともあって、いっきにつっこむのではなく、
少しずつ動かした方がよいのではないのかと。

>>898
> matdできになっているのは、負荷への耐性がどの程度あるか
> わからない点なんですよね。

まずは(他の系が安定している)どっかで、試してみるか。
携帯(c)とかか。

>>881
live22x4 を、event MPMで動かしてみた。

・live22x4: Apache 2.2.0 + event MPM
・live22x5: Apache 2.2.0 + worker MPM (比較のため)

今日 or 明日あたりに、フロントに投入予定。

>>898
>matdできになっているのは、負荷への耐性がどの程度あるかわからない点なんですよね。

確かに．

>アプリとして動くみたいなので、カーネルとの切り替えがばかにならないのかなと。
>(パケット1個単位で切り替えですよね。)

FreeBSD では BPF，Solaris では bufmod によるバッファリングが効いて
パケット取り込みはある程度まとめて行われると思いますが，
パケットの取りこぼしとか発生しないかどうかってのは，正直わかりません......

パケット送出の方は1パケット単位ですね．マルチスレッドモードなら
まとめて取り込まれたパケットの送出をコンカレントに行いますが，SMP でないと無意味
（シングル CPU だとかえってコンテキストスイッチングによるオーバヘッドが発生する）
だと思うんで，デフォルトではシングルスレッドモードになってます．

live22x4/live22x5 フロントに投入します。

以下の登録をよろしくです。

(追加)
+live22y.2ch.net:206.223.150.110
+live22y.2ch.net:206.223.150.42

>>902 訂正です。
TTLは他同様、300でお願いします。

(追加)
+live22y.2ch.net:206.223.150.110:300
+live22y.2ch.net:206.223.150.42:300

>>903

done

proxy との相性が悪かったのか、event MPM では 502 エラー出まくり。
あわてて、worker MPM に戻すことに。

【実況】 live22x 鯖 Part10
http://qb5.2ch.net/test/read.cgi/operate/1139729945/379 あたり。

event MPMのバグじゃなくて、設定に1つ抜けがあった模様。
ううむ。

＊フロント作成時の重要な注意＊

192.168.100.1 live22x.2ch.net

を、/etc/hosts に必ず追加すること。

これを入れないと、mod_proxy による dat 取得が失敗する。
(live22x[1-5]は、live22x.2ch.net という名前で live22.2ch.net のプライベート側に
とりにいくため)

しかしどうして、動いたり動かなかったりってことが起きたんだ?

あ、わかった、、、。live22x は代表名だから、
自分にアクセスが向くと、だめになるということか。

live22x4 の event MPM を復活。

様子を観察中ですが、、、。

event MPMって、何か負荷が高いですね。
たまにhttpdがいっせいにRUN状態になります(topで)。

で、Apache statusで見てみると、こんなふうに
1つのworker にほとんどがぶら下がる感じになっているようです。
つまり、分散していない。

________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________................................
________________________________________________________________
________________________________________________________________
________________________________________________________________
___________C____________________________________________________
________________________________________________________________
_____________________________________R____C____C____C___________
W_RCC_C__C____W_W__CRC_CR_CWCC__________________________________

で、こんな具合にそのhttpdが負荷高くなって、LAが上がります。
(CPU idle timeが少なくなる)

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
98662 ch2live22x 21 20 0 96076K 68860K kserel 0 13:17 7.18% httpd
2005 ch2live22x 1 97 0 14292K 13572K select 2 0:14 2.78% speedy_back
2659 ch2live22x 1 96 0 13900K 13168K select 2 0:04 2.64% speedy_back
666 dnscache 1 96 0 32804K 32116K select 2 2:08 0.00% dnscache
667 dnslog 1 -8 0 1204K 576K piperd 0 1:29 0.00% multilog
98661 ch2live22x 8 20 0 67652K 44428K kserel 1 0:25 0.00% httpd
98653 ch2live22x 9 20 0 32096K 22444K kserel 1 0:13 0.00% httpd
98651 ch2live22x 7 20 0 25360K 16552K kserel 1 0:11 0.00% httpd
98642 ch2live22x 7 20 0 22668K 14328K kserel 0 0:11 0.00% httpd
98646 ch2live22x 7 20 0 27560K 17652K kserel 1 0:11 0.00% httpd

ようはひとことでいうと、挙動不審ってかんじですね。

17:00 ぐらいまで様子見たら、worker MPM に戻そうかと。

(Apche 2.2 + worker MPMで動かしているlive22x5は、特に問題なし)

受付嬢はたくさん窓口にいるのに、いきなりみんななぜか忙しくなって開いている窓口がひとつだけ
しかもその人はごにょごにょしていてまずー

ってな状態と解釈しましたが、違いますかね？

新 epg も、worker MPM に戻した。

>>912
概ね、そんなかんじかもです。

というか空いている窓口がいっぱいあるのに、みんな同じ受付に案内されてしまうかんじ。

次は、キャッシュありの状態に挑戦か。

mod_disk_cache の場合の容量指定

Apache 2.2系ではディスクキャッシュにした場合、
htcacheclean コマンドでキャッシュのパージをする。

定期的にcron等から起動するか、-d(インターバル)をつけて
デーモンにする。

例えばこんな感じで指定する。

htcacheclean -d60 -p/md/cache -l64m

-d: デーモンモード、インターバル時間(秒)
-p: キャッシュディレクトリ(httpd.confで指定したものを指定)
-l: キャッシュ最大容量

今の設定:

CacheDisable /dome/SETTING.TXT
CacheEnable disk /dome/
CacheDisable /dancesite/SETTING.TXT
CacheEnable disk /dancesite/
CacheDisable /endless/SETTING.TXT
CacheEnable disk /endless/
... (以下、板の分だけ)

<IfModule cache_module>
Include /home/ch2live22x/test/httpd/cache.conf <= 上記を指定しているファイル
# config cache directory
CacheRoot /md/cache
</IfModule>

これだけ。
今はまだ >>882 等のチューニングは何もしてない状態。

【実況】 live22x 鯖 Part10
http://qb5.2ch.net/test/read.cgi/operate/1139729945/537

537 名前：root▲ ★[] 投稿日：2006/02/17(金) 20:35:52 ID:???0 ?#
CacheDefaultExpire 1
CacheMaxExpire 1

に再設定。

さて、キャッシュヒットの様子って、
どうやったら見られるんだろう。

で、「連打」とか「みんながいっせいに」を防げればいいわけだから、
1秒効いてくれれば、かなりいけるんじゃないかなぁと思ったり。

で、特に携帯(c)系で妙な挙動が起こったらしく、
いったんオフに戻した。

全フロントをApache 2.2にしてから、再度実験か。
Apache 2.2 @ フロントが大丈夫かの確認も伴うので、明日以降ってかんじで。

>>908-911 う〜む......まだ event MPM は発展途上ってことですかね．
今後は非同期 write / read の機能も加わるようなので，今後に期待かな．

>>919
>さて、キャッシュヒットの様子って、どうやったら見られるんだろう。

LogLevel を debug にすればわかりますが，実運用環境で debug は
さすがにきついか...... HTTP レスポンスヘッダに Age が入ってるのが
ヒットしてる目印になるかな．というか，その Age が Squid に
悪影響を与えているのが >>921 だったり!?

>>922
> HTTP レスポンスヘッダに Age が入ってるのが
> ヒットしてる目印になるかな．というか，その Age が Squid に
> 悪影響を与えているのが >>921 だったり!?

とっても高い確率で、ビンゴの予感。

そういえば、2chの鯖って(root権ありのやつ)全部root氏の管理っすか？

>>924
管理というか、おもりしているですね。
私以外にも root password を知っている人はいます。

■ XOロケーションの２ちゃんねるラックの現状(2005年2月18日現在)

合計25台(tiger: 17, cobra: 2, banana: 6)
すぐに移設可能なのは上記中6台(tiger: 3, cobra: 1, banana: 2)

○ Love affair作戦 - tiger: 8, banana: 2 = total: 10

tiger2507
tiger2508
tiger2509
tiger2510
tiger2511
tiger2512
banana405
banana406
tiger511
tiger512

○ 雪だるま作戦 - tiger: 6, cobra: 1, banana: 2 = total: 9

tiger2522
tiger2523
tiger2524
tiger2525
tiger503
tiger507
cobra2247
banana403
banana404

○ 上記のどちらでもない(移設可能) - tiger: 3, cobra: 1, banana: 2 = total: 6

tiger504 - game10
tiger509 - news19
tiger510 - hobby7
cobra2245 - BBQ
banaan402 - VIP931/stock
banana307 - BBM

現在 banana402 を別のラックに移設中。。。

>>928
了解です。リストを更新しておきます。
IPアドレスは変わらないと。

はい　変わらないように移設とお願いしました。

他のも、移設しておきますかね。

準備が整わないなら今日じゃなくてもいいですが、
割と近日中にってかんじで。

安全に移設できるなら、今日のほうがいいですが。
やるなら、該当サーバshutdownします。

配置計画とかあるから
今日は無理ー

土曜で人手不足ぎみ

>>933
了解です。

んでは、現状を現地に伝えて(私からしたほうがいいのかな: やっておきます)、
配置計画を練ってもらうということで。

【�d汁】雪だるま作戦に思いを馳せながら雑談するスレッド Part37
http://aa5.2ch.net/test/read.cgi/nanmin/1139755994/966-967

なるほど。

うげっ

VIP931/stock
同居なのか、しらなかった

ちと鬱

>>937
適当なところに場所作ってくださいー、という指令で、
root権限ありのうち、いちばん空いていたサーバに入れたです。

ちなみにcook81と同居なことは、雪だるま作戦のスレでさんざん書いていたです。

>>936 mod_cache のコード見ると，ETag が weak か否かとキャッシュは
直接関係ないように思えますが......weak になるのは mtime が
リクエストタイムから1秒以内ということのようです．


で，フロントの省電力化という課題が浮上ですか．さてさて......
http://polywell.com/us/rackservers/

いやいや

舞い上がって視野狭窄していた自分に鬱ってことだす。

>>940
そういうことすか。

>>939
さっき私も同じWebページ見てましたが、
Pentium Mあたり使ったよさげなBladeは載ってなかったです。
(なので某スレには、たまたまあったNECのやつを例示)

でも、フレキシブルに相談には乗ってくれるんじゃないかなと。< Polywell

>>939上
ほんとだ・・・>>936は撤回します

live22x4のレスポンスヘッダ見て適当に書いただけだなんて恥ずかしくて言えません

banana613 の情報受け取りました。
root 権限あり banana に変身と認識。

ちと今日は体調不安につき、明日あたりから。

【実況】 live22x 鯖 Part10
http://qb5.2ch.net/test/read.cgi/operate/1139729945/815-834

RLimitCPU での暴走リミッターは、mod_cgid (worker MPM) だと効かない模様。

で、bbs.cgi 側でリミッターを入れるというアイディアあり。
http://qb5.2ch.net/test/read.cgi/operate/1139729945/826

/usr/ports/devel/p5-BSD-Resource
この ports をbananaにも入れてもらうように手配しよう、そうしよう。

>>943

2pix.2ch.se つくってくれくれ

>>945
やるやる。

本日中にDNS登録依頼出すところまでいこうかと。

で、そのかわりといってはなんですが、
foxBEsetの株価を取って$GB->{KABU}にセットするところで、
bbs.cgiが暴走することがあるようです。

その前のsplitとかfor文のところがあやしそうなのですが、
見ていただけると助かります。

で、どうも、何十・何百種類と持っている人だと、
変なことになっている、、、っぽいなと。

暴走はこんなかんじか。

(ここから上はアドレスが違うだけ)
#76 0x28143cc1 in S_regmatch ()
from /usr/local/lib/perl5/5.8.7/mach/CORE/libperl.so
#77 0x28142b32 in S_regmatch ()
from /usr/local/lib/perl5/5.8.7/mach/CORE/libperl.so
#78 0x28146176 in S_regtry ()
from /usr/local/lib/perl5/5.8.7/mach/CORE/libperl.so
#79 0x2814a48b in Perl_regexec_flags ()
from /usr/local/lib/perl5/5.8.7/mach/CORE/libperl.so
#80 0x280f72ef in Perl_pp_match ()
from /usr/local/lib/perl5/5.8.7/mach/CORE/libperl.so
#81 0x280f3ef5 in Perl_runops_standard ()
from /usr/local/lib/perl5/5.8.7/mach/CORE/libperl.so
#82 0x280a0f3e in perl_run ()
from /usr/local/lib/perl5/5.8.7/mach/CORE/libperl.so
#83 0x0804d34d in onerun ()
#84 0x0804da5e in speedy_perl_run ()
#85 0x0804bd2c in start_child ()
#86 0x0804c17c in main ()

bbs.cgi暴走問題も、ここでやろうかと。

@ex14
%gcore 90994
gcore: read from /proc/90994/mem: Bad address

64bit 環境では、gcoreがちゃんと動かない模様。しくり。

いただいたbanana613ですが、今までのIPアドレスレンジと違うわけですが、
(それ自体はめでたくて、PIEが成長したということだと思います)、
DNSの逆引きの設定がおかしいようです。

banana613から他のホスト等にアクセスすると、DNSを引きにいって
ハングアップ状態になります。

調べてみると、ns1.pacificinternetexchange.net と ns2.pacificinternetexchange.net
の設定がまずい状態のようです。

(ns1.pacificinternetexchange.net: 自分自身を別名として指している)
%dig +norec -t ptr 110.224.29.207.in-addr.arpa. @ns1.pacificinternetexchange.net.

; <<>> DiG 9.3.1 <<>> +norec -t ptr 110.224.29.207.in-addr.arpa. @ns1.pacificinternetexchange.net.
; (2 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48850
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;110.224.29.207.in-addr.arpa. IN PTR

;; ANSWER SECTION:
110.224.29.207.in-addr.arpa. 800 IN CNAME 110.224.29.207.in-addr.arpa.

;; Query time: 1 msec
;; SERVER: 206.223.144.254#53(206.223.144.254)
;; WHEN: Sun Feb 19 14:58:24 2006
;; MSG SIZE rcvd: 59

ns2.pacificinternetexchange.net: SERVFAILエラーになる)
%dig +norec -t ptr 110.224.29.207.in-addr.arpa. @ns2.pacificinternetexchange.net.

; <<>> DiG 9.3.1 <<>> +norec -t ptr 110.224.29.207.in-addr.arpa. @ns2.pacificinternetexchange.net.
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37878
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;110.224.29.207.in-addr.arpa. IN PTR

;; Query time: 0 msec
;; SERVER: 206.223.146.254#53(206.223.146.254)
;; WHEN: Sun Feb 19 14:59:31 2006
;; MSG SIZE rcvd: 45

このため、banana613から他のサーバに設定ファイルを転送するのとかが、
とても苦しい状況に。

転送方向を変えるとかしてなんとかやりすごして設定作業しようと思いますが、
この状況だと実運用に入ってもいろんな影響が出る予感。

先方(PIE)に文句言って、直す必要ありですね。
正直、初期不良に近いかなと。

で、kill でも死なないのね(前バグありbbs.cgiで起きていたのと同じ)。

ローカルに持っている bbs.cgi @ ex14 に、

# resource limiter
use BSD::Resource;
setrlimit(RLIMIT_CPU, 120, 120);

をしかけて、120CPU秒で暴走が止まることを確認。

ex11, ex14, live22x[123] に、まずこれを入れよう。

>>955
> ex11, ex14, live22x[123] に、まずこれを入れよう。
done.

これでとりあえず、超火急ではなくなったと認識。

もしかすると、IsKoukokuを切ると収まるとか？
確かex14も稼働させているんですよね？

2pix.2ch.se の準備が整いました。
以下の登録をよろしくお願いします。

(新規追加)
+2pix.2ch.se:207.29.224.110

アカウント情報は、これからメールするです。

>>957
うーむ、keiba とか確かに稼動しているですね。
> +Rock54/54M

あとで、やってみるです。

>>957
しかし、朝の修正(http getでエラーチェック入れた)から、
暴走が起こりにくくなったのは事実ですね。

見ていますが、頻度が少なくなったんで(よいことなんですが)、
逆にデバッグがなかなかできにくいかも。

>>958
done.

>>947
管理人にあたらしい API 作ってもらったんで
それに乗り換えるべく準備中。。。
いましばらくお待ちを、

>>962
了解です。

たぶんですが、呼び側から板名を指定できるようになるのかしら。

んだんだ

なるほど。>>964

それなら、その後の微妙な処理をしなくてよさげと。

その予定でーす

で、今回はDNS逆引き設定のお願いをば。

モニタサーバで使用しているIPアドレスのうち一つを、讃岐君の環境専用にします。
ということで、以下のDNS逆引き設定の追加をお願いします。

(新規追加)
^26.0.153.223.206.in-addr.arpa:s2ch.net

>>967
done

>>958
done

鯖をまとめたら速そう。
IBMのメインフレームとか。

コンパイルﾏﾝﾄﾞｸｾになるな。

ヨナがくるまで待つか。

某もうすぐ咲くインターネットはSempronメインみたいです。
ｶﾙﾌｫﾙﾆｱと日本じゃ電気代10倍違うから、ランニングコストにもシビアになるんでしょうねえ。

じゅ、十倍…

>>972
もうすぐ咲くの社長さん、おげんきですかね。

>>973
電力会社的には、日本は5倍ぐらい信頼性高いっていうことのようです。
どっちがいいのかは、、、さて。

ということで、www2 関連のDNS登録変更&追加依頼いきます。
以下の変更をよろしくお願いします。

(現状)
+www2.2ch.net:206.223.151.10:300

(変更後)
+www2.2ch.net:206.223.150.96:300
+www2f1.2ch.net:206.223.150.64
+www2f2.2ch.net:206.223.150.74
+www2f3.2ch.net:206.223.150.84
+www2b.2ch.net:206.223.150.54

>>974
done

2chで『山梨でデータセンター』とかやったら面白い。電気はみんな自家発電。ヒロユキがぶどう作ってます、みたいな。回線はレスポンスがちと速くなるし、冬は雪を溶かすほどマシンが唸りを上げて社会に貢献。
山梨の一大観光名所になると。


山梨最近まで金融において孤島だったけどセブンイレブンにATMやっと入ったし。

目標は第二の理研スペックか。


まぁ夢物語だけどね。

>>975
どもです。観察中。
いまのところ、matd含めて問題ない模様。

>>976
建物の名称はサティアンですか。

>>978

そしてサーバのおもりはし＊ーｋ（りゃ


さあ　そろそろ　次スレの　季節じゃが　どなたか　立ててくださらんかのう？

>>979
今夜あたりに(そのぐらいでじゅうぶんかと)。

カルフォルニアでIDCだと小さい体育館ほどの自家発電装置を入れたりして
それなりにコストかかったりしそうだなぁ。
自動消火施設とか燃料の軽油とか。固定資産税とか。

>>+www2.2ch.net:206.223.150.96:300
DNSでポート指定って出来るんだ…
ちょっといい勉強になった
うちでもやってみるか

>>982
それはポートじゃなくてDNSのTTLじゃね？

あ、
そうみたいですねorz

どくどくさぼてんさん、他PVとられている方へ:

www2.2ch.net の PV ですが、

http://www2f1.2ch.net/_service/
http://www2f2.2ch.net/_service/
http://www2f3.2ch.net/_service/

の数値の合計となります。

http://www2.2ch.net/_service/

ではないので、ご注意くださいです。
(上記は上の3つのどれかが表示されるだけ)

http://www.2ch.net/_service/
http://menu.2ch.net/_service/

は、変わりありませんです。

matd からの「出」、つまり live22xN に行く経路を、
パブリック側とプライベート側のどっちにすべきか。

どっちもちゃんと動いたけど、さて、どっちがいいのかな。
今はパブリック側で設定。

その二種類で何が違うのかってとこかと、

それぞれの負荷(割り込み処理)のコスト計算ですね。
トラフィック的には、たかが知れているので。

live22x[123]のプライベート側は(非圧縮なので)、
あっしゅくしてから送っているパブリック側よりもトラフィックが多いです。
で、とりあえずパブリック側にしていると。

あと受け付け的には、同じI/Fで受けて送るのと、
違うI/Fに振るのとでは、どっちがいいのかなとか。

portsのPerlが、5.8.8になったもより。
どのへんが変わったんだべか。

>>987
パブリック側でよいのでは。
フロントのパブリック側の上りのトラフィックは基本的にはないですよね？
プライベート側の上りトラフィックはdatとかかなりのトラフィック量に
なると思うので。

LAN2個あれば……。

受付嬢にdat背負わせてもなぁ。
datだけ別鯖はないか。

■ テレビ番組欄＠2ch をつくろう 第3話
http://qb5.2ch.net/test/read.cgi/operate/1122520338/468-472

epg の DNS 書き換えは、帰宅後に新スレでやるということで。

>>990
このあたりとか（笑）
http://perldoc.perl.org/perl588delta.html

baila6.jpな鯖も入れ替えよっと♪

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

matd 自体にとっては，パケット取り込みと送出の I/F が同じでも別々でも
差はないと思います（というか，取り込みに libpcap，送出に libdnet と
別々のライブラリを使ってますし）．OS にとってはどうか，ってのは
カーネルの stat 見てみるとか（Solaris でいうところの kstat とかで）．

トラフィックということでいうと，現状のようにキャッシュなしの場合と
mod_cache でキャッシュさせた場合とでは，条件がかなり変わってきますね．

あと，live22 の bbsd のと同じように，http://www2.2ch.net/_service/ で
matd の stat (SIGUSR1 で出てくるやつ) が見られると何か参考になるかも......

>>995
定時的に kill -USR1 あてて、とってみるですか。
帰宅後にごにょごにょしてみます。

kstat に相当するのは、、、。ふむ。

このへんの詰めも、次スレに向けての課題かなと。

で、このスレの >>1 が2005年7月21日ですか。7ヶ月で1スレと。
いろいろなことが進みました。
でも >>18 の問題は、結局スレの最後まで解決をみなかったなぁ。

家庭の保守は愛情つぎ込めw

鯖をローテンさせるのもﾏﾝﾄﾞｸｾ。

下の二つは仕方ない？

死なない程度にシステム移行出来ればいいのに。
私はプログラム書けないしネットの基本もわからんので誰かよろ。

セキュリティは元締めでやると管理は楽だけど効率がいくない。やはり末端に任せるしか無さそうだ。
クッキーかジャバに任せるのも手。

中の人頑張ってくんなまし。

>>985 一部バグっていました。今直しました。

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

新スレ立てました。

matd の本格稼動を祝いつつ、以降は次回の講釈にて。
↓１００１

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。