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

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

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 の本格稼動を祝いつつ、以降は次回の講釈にて。
↓１００１

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