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

**root▲ ★** · NG

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

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

等を取り扱います。

現在、複数サーバによる連携により、
サーバ能力のさらなるスケールアップをめざすための「雪だるま作戦」が進行中です。

また、次世代の携帯アクセス環境をめざした「べっかんこ作戦」も稼動しはじめました。
「２ちゃんねる証券取引所」や、「Be」の機能強化等、
２ちゃんねるは今日も変化し続けています。

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

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

おつかれさまでしたー。

**動け動けウゴウゴ２ちゃんねる** · 2006/02/28(火) 07:09:26

ありがとうございます。お疲れ様です。

**root▲ ★** · NG

eaccelerator.debug=0

をphp.iniに入れないと、延々とデバッグメッセージが出てちょっと遅くなるみたい。

**root▲ ★** · NG

>>98 はもちろん、
AllowOverride All

でもだめなので注意。

AllowOverride All Options=All,MultiViews と、
なんと All を2回も書いたうえで、かつ MultiViews を明示的に有効にしないといけない。

**root▲ ★** · 2006/02/28(火) 16:46:09

c.2ch不具合報告総合スレ5
http://qb5.2ch.net/test/read.cgi/operate/1138289353/347-360

Apache 2.2 + mod_proxy + mod_cache で
squid の代わりをしようと思ったのですが、
トラフィックを乗せたとたんに過負荷で爆死。

squid はとてもよくできていることと、
Apache 2.2 ではその代わりは務まらないことを痛烈に認識。しくり。

**root▲ ★** · 2006/02/28(火) 16:50:52

いきなりLAが急上昇し、
プロセスを止めることもできず、そのまま無反応状態へと。>>103

squid はこのへん、きわめてよくできているんだなと。

**root▲ ★** · 2006/02/28(火) 16:58:27

あと試す余地があるのは、5.4R時代に一度試して
高パフォーマンスだったけどカーネルパニックで落ちた-lthrぐらいか。

今日明日はもうやらなくて(c-docomo系の結果を見ようかと)、
その後にでもまたぼちぼちと。

株価【750】 ▲ ◆cZfSunOs.U · 2006/02/28(火) 21:27:03

>>86 乙です．

>まず、worker MPM では httpd がどんどん暴走状態になり、だめ。
>prefork MPM では問題なく動作。

OS が 5.4R なのが問題なのか，それとも PHP5 (or eaccelerator) の
thread safety problem なのか......

あと，MultiViews も何か曲者みたいですね．まぁ元々，パフォーマンス面を考えても，
毎回 readdir(_r) することになるんで使わずに済ませられるならそうした方がいいんですけどね．

>>103-104 まぁ prefork MPM ならそんなもんかと......event MPM に
async read / write も実装した段階では Squid なみになるかも知れませんが．

>>105 Solaris でも 7 までは M:N モデルだったのが，8 では代替スレッドライブラリとして
1:1 モデルも用意されるようになり，9 からは 1:1 モデルに全面移行しましたからね．
理屈上のことはともかく，現実的には多くの場合シンプルな 1:1 モデルの方が
パフォーマンスがいいというのがその背景ということのようで．

**root▲ ★** · 2006/02/28(火) 23:33:04

http://lists.freebsd.org/pipermail/freebsd-current/2006-February/060833.html

いままさに、やってるわけか。

**root▲ ★** · 2006/02/28(火) 23:34:00

phk: い、今の-currentなら、、、(以下略
http://lists.freebsd.org/pipermail/freebsd-current/2006-February/060836.html

**root▲ ★** · 2006/02/28(火) 23:34:51

あ、そうだ。

ハードウェアの状態、どうだっただろう。

**root▲ ★** · 2006/02/28(火) 23:35:45

http://live22.2ch.net/_service/mbmon-20060228.txt

おかしかったのは、、、何時ごろだっけ。

**root▲ ★** · 2006/02/28(火) 23:40:38

http://people.freebsd.org/~phk/

がんがってほしい、、、。

**root▲ ★** · 2006/02/28(火) 23:49:18

さて、

>>106
MultiViews なしのほうが、パフォーマンス上がるということですか。
どのくらい差があるんだろう。

> まぁ prefork MPM ならそんなもんかと

…ですか。worker MPMでしたが、やはりだめでした。
aync read/write がでかいみたいです。

-lthr は、明日夜あたりに時間とれればぼちぼちというかんじで。

株価【750】 ▲ ◆cZfSunOs.U · 2006/02/28(火) 23:51:30

乙です．毎度おなじみのパターンですか......まぁ現状で打てる手はやはり mod_cache でしょうね．

http://qb5.2ch.net/test/read.cgi/operate/1140699969/814-817n
814 ：root▲ ★ ：2006/02/28(火) 23:28:57 ID:???0
　　すぐにはハードウェアの追加は見込めないから、
　　何とかしないといけないなぁ。

　　まずは、フロントに mod_cache ですね。
　　今日作業しよう。

817 ：root▲ ★ ：2006/02/28(火) 23:30:08 ID:???0
　　calcru: runtime went backwards from 1186744 usec to 1186538 usec for pid 905 (httpd)
　　pid 17287 (httpd), uid 2001: exited on signal 10
　　pid 17309 (httpd), uid 2001: exited on signal 10
　　pid 17273 (httpd), uid 2001: exited on signal 10
　　pid 17274 (httpd), uid 2001: exited on signal 10
　　pid 17279 (httpd), uid 2001: exited on signal 10
　　pid 17318 (httpd), uid 2001: exited on signal 10
　　pid 17306 (httpd), uid 2001: exited on signal 10
　　pid 17305 (httpd), uid 2001: exited on signal 10
　　pid 908 (httpd), uid 2001: exited on signal 10
　　pid 17272 (httpd), uid 2001: exited on signal 10
　　pid 1595 (httpd), uid 2001: exited on signal 10
　　pid 1597 (httpd), uid 2001: exited on signal 10

　　いつものやつか、、、。ううむ。

**root▲ ★** · 2006/02/28(火) 23:53:52

>>113
…ですね、、、。

コンソールをいつでも問題なく触ることが出来て、
時間をもっととれるなら、phk に付き合って最新の -current で人柱する、
というのもありなのかもですが、現状の私では残念ながら、無理な模様。

**root▲ ★** · 2006/03/01(水) 00:31:52

c-docomo5 の様子を観察中。

LA=4強ぐらい。
混んでいた時のnews19ぐらいですね。
一定の効果はあったのかなってかんじで。

問題は、明日以降なわけですが。

**root▲ ★** · 2006/03/01(水) 01:16:59

live22x[123] を、Apache 2.2.0 環境に更新中。

Apache 2.0.x なサーバと、read.cgi バイナリに互換性がなくなるので、
dso の配布リストから削除。
live22x1 から配布で。

**root▲ ★** · 2006/03/01(水) 01:25:24

で、kako/ はキャッシュしなくていいのかな。
Expires: と Age: を殺そうかと。

**root▲ ★** · 2006/03/01(水) 02:37:22

>>117
kako はローカルには持ってないんだった。
とりあえず設定には入れず。

で、mod_cache 化は完了のはず。
設定内容は次以降で。

**root▲ ★** · 2006/03/01(水) 02:41:20

869 名前：root▲ ★[sage] 投稿日：2006/03/01(水) 02:40:35 ID:???0
○ mod_cache 関連

/usr/local/sbin/htcacheclean -d5 -p/md/cache -l64m

を、/md 作成時に起動するようにrcファイルに追加。

<IfModule cache_module>
# configure cache directory
CacheRoot /md/cache
# configure cache expiration time
#CacheDefaultExpire 60
#CacheMaxExpire 60
# unset unneed headers
Header unset Age
Header unset Expires
</IfModule>

というファイルを作って、2ch-cache.conf という名前で Include に放り込み。

Age: と Expires: がないとそもそもキャッシュだとわからないので
(昼間BG4でしくったときに実験した)、外からみた振る舞いに変化はないはず。

**root▲ ★** · 2006/03/01(水) 02:44:45

で、肝心のキャッシュは、

CacheDisable /dome/SETTING.TXT
CacheEnable disk /dome/
CacheDisable /dancesite/SETTING.TXT
CacheEnable disk /dancesite/
CacheDisable /endless/SETTING.TXT
CacheEnable disk /endless/
CacheDisable /eq/SETTING.TXT
CacheEnable disk /eq/
CacheDisable /eqplus/SETTING.TXT
...

という、単純なもの。

**root▲ ★** · 2006/03/01(水) 02:46:02

あ、これだと、read.cgi の出力もキャッシュされるのかな。
このへんは、微妙なチューニングが必要かも。

**root▲ ★** · 2006/03/01(水) 02:47:19

で、昔やった予備実験の結果からすると、
20%～25%ぐらい、バックエンドへのアクセス数が減少するはず。

**root▲ ★** · 2006/03/01(水) 02:47:44

アクセス数というか、実際の転送回数かな。

**root▲ ★** · 2006/03/01(水) 02:50:31

http://mumumu.mu/bremen/live22.html

それなりに減ったかな。
一定の効果は出ているっぽい。

live22のログを見てみるか。
3xx なレスポンスが多くなれば、うまくいっているということかしら。

**root▲ ★** · 2006/03/01(水) 02:52:16

2xx 3xx 4xx 5xx URL
221 13 0 0*/liveanb/dat/1141148550.dat
216 13 0 0 /livevenus/dat/1141144653.dat
57 0 0 0 /liventv/dat/1141142442.dat
50 4 0 0 /news/dat/1141142585.dat
27 0 0 0 /livetbs/dat/1141142582.dat
26 7 0 0 /liveetv/dat/1141130962.dat
26 0 0 0 /news/subject.txt
23 9 0 0 /livenhk/dat/1141148068.dat
22 4 0 0 /livewkwest/dat/1141148317.dat
19 0 0 0 /livewkwest/dat/1140972656.dat
16 2 0 0 /liveskyp/dat/1141140286.dat
12 10 0 0 /liveradio/dat/1141140643.dat
11 0 0 0 /liveanb/subject.txt
11 20 0 0 /liveanb/dat/1141147805.dat

悪くなさげ。

**root▲ ★** · 2006/03/01(水) 03:22:01

携帯系(というかSquid)への副作用が発生。対応中。

**root▲ ★** · 2006/03/01(水) 03:24:05

>>119 を修正。

<IfModule cache_module>
# configure cache directory
CacheRoot /md/cache
# configure cache expiration time
#CacheDefaultExpire 60
#CacheMaxExpire 60
# unset unneed headers
Header unset Age
Header unset Expires
Header unset Cache-Control
</IfModule>

株価【750】 ▲ ◆cZfSunOs.U · 2006/03/01(水) 03:41:22

>>114-127 乙です．Squid への副作用がなぜなのかいまいちわからないですね．
ただ......各フロントごとにキャッシュの内容が新旧入り交じっていて，
Squid から取得するたびに新しいのに当たったり古いのに当たったり
バラバラだったりすると，ひょっとしておかしくなるのかな，とも......

**root▲ ★** · 2006/03/01(水) 04:31:43

>>128
なるほど。それはあるかも。

いずれにせよ、squidの振る舞いをきっちりチェックする必要ありですね。

#LoadModule cache_module libexec/apache22/mod_cache.so
#LoadModule disk_cache_module libexec/apache22/mod_disk_cache.so
#LoadModule mem_cache_module libexec/apache22/mod_mem_cache.so

にして、今日はいったん撤退。

c.2ch不具合報告総合スレ5
http://qb5.2ch.net/test/read.cgi/operate/1138289353/374
>
> squidの振る舞いについては、じっくりした調査研究が必要そう。
> たぶん、squid側から何か言われても無視するようにすればよさげな気もしますが、
> そのへんはおいおい調べるということで。

**root▲ ★** · 2006/03/01(水) 04:35:28

で、今見たら120MBytesの/mdを64MBytesまでしか使わないはずなので、
既に90MBytesちかくになっていて、どきどきしたので、

/usr/local/sbin/htcacheclean -d1 -p/md/cache -l64m

に変えた。(インターバル1分)

**root▲ ★** · 2006/03/01(水) 04:46:27

前にもsquidのキャッシュの取り扱いではちょっと悩んだことがあるので、
現在の設定をダンプしておこう。

# added override-lastmod by mumumu, 2004/7/29
#refresh_pattern . 2 0% 2 override-lastmod reload-into-ims
# shorten delay time to 1 minutes by mumumu, 2004/8/17
#refresh_pattern . 1 0% 1 override-lastmod reload-into-ims
# extend max value by mumumu, 2005/3/25
refresh_pattern . 1 0% 60 override-lastmod reload-into-ims

このスレまだ生きてた。
http://pc8.2ch.net/test/read.cgi/linux/997328024/182-183

**root▲ ★** · 2006/03/01(水) 04:49:59

http://qb5.2ch.net/operate/kako/1107/11073/1107376477.html
の、453 か。

この 60 ってのが、とってもとってもあやしいような気がしてきたのです。

ということで、今日はここまで。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/01(水) 04:58:02

Yahoo! Developer Network - PHP Developer Center
ttp://developer.yahoo.net/php/

なんてものができてたらしい

◆Reffiz2Zh. · 2006/03/01(水) 07:18:04

ttp://lists.freebsd.org/pipermail/freebsd-current/2006-February/061134.html

**root▲ ★** · NG

>>133
お、これは。

>>134
パッチですか。
ちょっと、リスト読んでみるです。

**root▲ ★** · NG

http://lists.freebsd.org/pipermail/freebsd-current/2006-February/061137.html

> Thanks. After applying your patch, I never get calcru messages on
> 6-STABLE. It seems fine. Thanks again!

効果あるのか。

**root▲ ★** · NG

>>134
> I've been getting calcru messages on 6-STABLE when stress-testing an
> application linked with libpthread. As far as my experience goes,
> these messages are only for ones linked with libpthread. If the same
> application is linked with libthr, these messages go away.

うわってかんじなんですが。

もうちょっと調べて、たぶん試してみようかと。

**root▲ ★** · NG

>>134
http://people.freebsd.org/~davidxu/patch/calcru_r61_060227.patch

に、ゆきあたった。

**root▲ ★** · NG

>>138 を適用した。

しばらくしたら、live22 リブートの予定。

**root▲ ★** · NG

リブートした(無事上がった)。

これで、どうなるのか。

**root▲ ★** · NG

以前適用した、

#kern.timecounter.hardware=TSC

をやめた。(デフォルトのACPI-fastに戻した)

**動け動けウゴウゴ２ちゃんねる** · 2006/03/01(水) 17:45:10

http://takabsd.jp/d/?date=20070121

**動け動けウゴウゴ２ちゃんねる** · 2006/03/01(水) 17:46:46

>>142 書き込んでしまいました失礼

http://takabsd.jp/d/?date=20070121
http://dev.ariel-networks.com/blog/index.php?itemid=706
ここらの話はどうでしょう、もうやってたらすみません

**root▲ ★** · NG

>>142-143
ざっと読みました。
これはとても興味深いですね。

worker MPMはいまや使いまくりなので、相当のパフォーマンスアップが期待できると。

> ところで、APR がすでにインストールされていると、configureオプションを変えて
> 再インストールしようとしても、すでにインストールされている APR を使おうとするため、
> APR をリビルドすることができないようです。

これに気をつけないと、いかんという話もあるのか。

ちょっと、調べてみるです。

**root▲ ★** · NG

.if defined(WITH_THREADS)
CONFIGURE_ARGS+= --enable-threads
. if ${OSVERSION} > 500023
. if ${ARCH} == i386
CONFIGURE_ARGS+= --enable-nonportable-atomics
. endif
. endif
.endif

となっているのか。< portsのMakefile

問題は、これが有効になっているかだが、、、。

**root▲ ★** · NG

. if ${WITH_MPM} != "prefork"
PKGNAMESUFFIX= -${WITH_MPM:L}
WITH_THREADS= yes
WITH_THREADS_MODULES= yes
WITHOUT_MODULES+= cgi
...

なのか。< Makefile.modules

**root▲ ★** · NG

%nm /usr/local/lib/libapr-1.so.2 | grep atomic
0000ddf0 T apr_atomic_add32
0000dddc T apr_atomic_cas32
0000deb0 T apr_atomic_casptr
0000de10 T apr_atomic_dec32
0000de24 T apr_atomic_inc32
0000de58 T apr_atomic_init
0000df20 T apr_atomic_read32
0000de38 T apr_atomic_set32
0000de00 T apr_atomic_sub32
0000de48 T apr_atomic_xchg32

入っている模様。

で、mod_mem_cache はこれで動いている模様。

httpd は、、、。

**root▲ ★** · NG

…入っているようです。
(都合上、適宜折り返し)

configured by ./configure, generated by GNU Autoconf 2.59,
with options \"'--enable-layout=FreeBSD' '--with-perl=/usr/local/bin/perl5.8.7
' '--with-port=80' '--with-expat=/usr/local' '--with-iconv=/usr/local' '--enable
-http' '--enable-v4-mapped' '--with-dbm=sdbm' '--with-ssl=/usr' '--enable-thread
s' '--enable-nonportable-atomics' '--with-mpm=worker' 'i386-portbld-freebsd6.0'
(以下略)

…ということで、ports猿マンセー状態だったということか。

**root▲ ★** · NG

しかし、勉強になりました。

ということはちゃんと動くんなら、worker MPM(や将来はevent MPM)のほうが、
パフォーマンスアップするということですね。

www.2ch.net/menu.2ch.net がサーバ更新後に異様に軽くなった理由が、
相当わかった気がします。worker MPMの力だけかと思っていたけど、そういう理由だとは。

**root▲ ★** · NG

>>149 補足

もちろん、www2.2ch.net が仲間から抜けたことも相当大きいですが。

**root▲ ★** · NG

で、このコードって >>145 っていうぐらいで、i386 の時しか有効にならないのね。
cobra2247 をバックエンドに仕立てる次期計画を考えると、
amd64 でも動いてほしいなとか思ったり。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/02(木) 00:52:21

[FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:09.openssh
http://lists.freebsd.org/pipermail/freebsd-announce/2006-March/001049.html

対象はFreeBSD5.3と5.4のOpenSSHだそうで．

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

FreeBSD-SA-06:10.nfs もきたね。
[FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:10.nfs
http://lists.freebsd.org/pipermail/freebsd-announce/2006-March/001050.html

こっちはAll FreeBSD releases.が対象、だけど、nfsつかっているんだっけ？

**動け動けウゴウゴ２ちゃんねる** · 2006/03/02(木) 04:19:56

結構workerで動くもんなのだね。。

/* むやみに6.0にしたくなったけどMySQLの都合で出来ずorz */

bbs.cgiのSpeedyCGIはmod_speedycgiじゃないよね？
毎回プロセス起動のほう？

株価【650】 ▲ ◆cZfSunOs.U · 2006/03/02(木) 07:46:50

>>139-140 これで "calcru: runtime went backwards......" が出なくなれば，一つ山を越えることになると......

>>151 apr_atomic.c で↓のようになってるんで，AMD x86-64 でも行けるかなと．

#if (defined(__i386__) || defined(__x86_64__)) \

>>154 http://qb5.2ch.net/test/read.cgi/operate/1105909861/477-479n

話は変わりますが，mod_load_average なんてものがあるようで．
http://svn.force-elite.com/svn/mod_load_average/trunk/src/mod_load_average.c
http://www.mail-archive.com/dev@httpd.apache.org/msg31056.html
This way you could disable CGI when your LA is above 10,
and then disable everything when your LA is above 100:
LoadAvgMaxByHandler cgi-script 10
LoadAvgMax 100

**root▲ ★** · 2006/03/02(木) 11:15:35

おはよござます。

>>152
PAMとのconflictでうんぬんですか。
昔なら「FreeBSD only」っぽい(この項目いつの間にかなくなったっぽい?)やつかも。
状況からして、当てる必要ありで。

>>153
2ch/BBSPINKではNFSは使っていないので、
こっちは急ぐ必要ないですね。

**root▲ ★** · NG

>>154
私自身、結構驚いていたり。
前スレにも書きましたが worker MPM については、

5.2.1R 論外
5.3R だめだめ
5.4R 一応動くけど挙動不審
6.0R 今のところ大きな問題なし

という感じのようです。

> bbs.cgiのSpeedyCGIはmod_speedycgiじゃないよね？
> 毎回プロセス起動のほう？

毎回プロセス起動のほうです。
mod_ のほうは、worker MPM では動かないはず。

あと２ちゃんねるみたいな使い方(= CGIはばりばりいじられる、
全サーバのroot権限があるわけではない)だと、
プロセス起動にしておいたほうが、いろいろな意味で安全ですね。

mod_ な環境でCGI が暴走すると httpd を kill しなきゃならないので、
root 権限なかったりすると面倒です。
プロセス起動なら、speedy_backend を kill すればよいわけで。

**root▲ ★** · NG

>>155
> >>139-140 これで "calcru: runtime went backwards......" が出なくなれば，
> 一つ山を越えることになると......

そう願いたいですね。
今週は日曜夜に巨大なトラフィックがある模様。

> >>151 apr_atomic.c で↓のようになってるんで，AMD x86-64 でも行けるかなと．
> #if (defined(__i386__) || defined(__x86_64__)) \

なるほど、使えるですか。

> 話は変わりますが，mod_load_average なんてものがあるようで．

ちょっとそのスレッド読んでみました。
より細やかな制御ができると。

今は read.cgi / bbs.cgi とも LA チェック入っているので急務ではないですが、
使う機会は別にあるのかもなと。

**154** · 2006/03/02(木) 14:45:17

>>157
うーん、やはり6.0はあなどれないな。。
5.2以前のネイティブスレッドは一つのスレッドのI/Oが大きいと
他のスレッドがたちまち遅くなるっていう致命を持った貧弱さだから。。

でも5.3でもだめなんだ。うーん、うちんとこは5.4だからここはpreforkのままでいくしかないな。。

一度workerMPMで動かしたことがあって、あのプロセス数:最大接続数の多さを見たときには感激したけど、
C++で書いたCGI+mod_cgidsoのどっかの動作でMT-safeでなかったらしくApacheが暴れたことがあり(preforkならOK)orz

MT-safeな書き方を学ぼうと思ってついに2006年の春を迎えてしまった。

Thread-safeってすごく便利だけど、やっぱり対応が未だ少ないのがネックか('д`)

**root▲ ★** · 2006/03/02(木) 15:18:11

>>159
> でも5.3でもだめなんだ。

…でした。
ちょっと前に news19 で試したんですが、SIGBUSで落ちまくりで
5分ぐらい掲示板が超挙動不審になってしまい、livemarket1 の住民さんに
「昼間のザラ場の時間にメンテなんて何考えてるんだ !!」って、
ものすごい勢いでおこられました。

デイトレーダーの人たちはどうやらものすごい勢いで、
この掲示板に強く依存しているようです。

MT-safe は、たぶん何かすごくこつがあるんでしょうね。
errno が普通の方法では参照できないとかいうので目からうろこが落ちてるようじゃ、
たぶん、全然だめなんだろうなと。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/02(木) 15:47:11

>>160

> 5分ぐらい掲示板が超挙動不審になってしまい、livemarket1 の住民さんに
> 「昼間のザラ場の時間にメンテなんて何考えてるんだ !!」って、
> ものすごい勢いでおこられました。

そんな時間に株系の板で実験ですか
予告してやったんでしょうか？
でなきゃ{起こ|怒}るのも当たり前でしょう・・・・

> デイトレーダーの人たちはどうやらものすごい勢いで、
> この掲示板に強く依存しているようです。

ワロス

**FAX ★** · 2006/03/02(木) 16:27:11

怒り爆発

**root▲ ★** · NG

>>162
む、、、。何か、私まずいことしたのかしら。

**FAX ★** · 2006/03/02(木) 16:54:13

いえいえ

**動け動けウゴウゴ２ちゃんねる** · 2006/03/02(木) 22:09:19

困るrootたん萌えってことで
むぎゅって言って(*´Д｀)

**root▲ ★** · NG

Saru: Active-Active
http://ultramonkey.jp/papers/active_active/active_active.shtml

これがFreeBSD+matdでもできるようになると、とてもいいなぁとおもた。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/03(金) 04:06:52

なんとなく、pf(4)を駆使すれば似たようなことができるような気がする。
NATでだけど。
http://www.openbsd.org/faq/pf/
http://www.openbsd.org/faq/pf/pools.html

**root▲ ★** · NG

サーバダウン(鯖落ち）情報　part94
http://qb5.2ch.net/test/read.cgi/operate/1140710423/325
の件、、、。

live22x[123] の matd 化に向けて、httping(*1)で応答時間を監視していて、
(*1: http://www.vanheusden.com/httping/ )
10パケットに1パケット程度、数秒のディレイが起きていることに気づきました。

で、banana403でdevice_polling(4)を試そうと決め、
もしリブートでしくってもheartbeatによりbanana404にフェイルオーバーするはずだと、
リブートをかけました。

しかし、いつもとリブートの感じが違いました。
いつもはputtyの窓がちゃんと閉じるのですが、今回は閉じずに
ただ反応だけがなくなりました。

で、banana404へのフェイルオーバーは起きたのですが、
「俺のIPアドレスを別のやつ(banana403)も名乗っているぞ」というエラーが404で出始めました。

(続く)

**root▲ ★** · NG

で、「これはおかしいぞ」と思い、
一度 banana404 のリブートもかけてみようと思い立ちました。
(今思うとこれがまずかったと思われ)

で、banana404 は設定を変えずに、単に reboot コマンドでリブートしました。
しかしなぜか、さきほどの banana403 と同じ状態になりました。
つまり窓が閉じずに、反応だけがなくなる状態になりました。
ここで本能的に「まずい」と思いました。

案の定、両方のサーバともサービスがない状態になり、
www2.2ch.net は止まった状態になりました。
で、現在に至ります。

(続く)

**root▲ ★** · NG

今調べてみると、

banana403 実IPアドレス … ping かかる
banana403 実IPアドレス … ping かかる
サービス用 IP アドレス(www2.2ch.net) … ping かかる

という状態にあるようです。
しかし、どのサービスも応答しない状態になっています。

推測ですが、これはリブートではなく、シャットダウンの途中で止まっている
ように思えます。つまり、何らかの理由でシャットダウンできていない。
いつもは閉じる窓が閉じなかった(つまり向こうからTCPのセッションを切ってこなかった)
ことから、ほぼ間違いないと思います。

しかし、設定を変えたbanana403はともかく、
設定を全く変えていないbanana404でも同じことが起きたのは、
かなり不可解です。

heartbeatが悪さをしたのか、
あるいは、remote KVMとかが悪さをしたのか、
あるいは他の原因か、、、。

いずれにせよ現在、remote KVMにアクセスできない状態なので、
(さきほどやってみましたがだめでした。これはSeanさんにさきほど問い合わせしました)
コンソールの状況を確認できないです。

以上が現在の状況です。ううむ、、、。

**root▲ ★** · NG

> (さきほどやってみましたがだめでした。これはSeanさんにさきほど問い合わせしました)

Seanさんから返事が来て、無事にKVMにアクセスできました。

やはりbanana403/404とも、シャットダウンの途中でしくっていました。
というか、Rebooted by ... というシステムログが出て、
プロセスは切られているのに、そこから先に進まない状態。

直感ですが、matd がというか、
たぶんヘビーなパケット処理により、カーネルが何らかの形で止まっているっぽいです。

**root▲ ★** · NG

…ちとまじで限界なので、
ここから先はリブートの中の人に403/404の両サーバをリブートいただいた後に、
別途リブート入れて検証してみることにするです。ううむ。

株価【650】 ▲ ◆cZfSunOs.U · 2006/03/03(金) 07:09:39

>>166-167 フェイルオーバしつつロードバランスもするって感じなんでしょうか．興味深いですね．

>>168-172 う～む......matd の挙動も要観察ですかね．パケットのドロップが発生してるのかどうかとか......

株価【650】 ◆OSfanJsSVc · 2006/03/03(金) 07:57:16

Apache2.2.0の機能でプロセスが終わらないとサービスが切れない機能？があるらしいです。

無理矢理切ってエラー発生して結局システム真紀子み止まった。

てな感じかと｡｡｡

**動け動けウゴウゴ２ちゃんねる** · 2006/03/03(金) 10:31:49

> デイトレーダーの人たちはどうやらものすごい勢いで、
> この掲示板に強く依存しているようです。

デイトレーダーの人はモリタポ買ってね！
と言っても良さそうな気がして来た。

**root▲ ★** · NG

無事(device_pollingしたほうも)上がりました。

>>173
ちと、じっくり調べてみるです。

>>174
今回のサーバではApache 2.0系で、CGI動かしてないです。

**root▲ ★** · NG

WARNING: / was not properly dismounted

両サーバとも、やはり正しく落ちなかった模様。

**root▲ ★** · NG

354 名前：root▲ ★[sage] 投稿日：2006/03/03(金) 11:43:48 ID:???0 ?#
ふうむ、device polling ありだと、うまくないのね。
なし(前の状態)にしたら、つながりました。

まだよくわかりませんが、
device polling はいまやなしのほうが、よさげなのかも。

**root▲ ★** · NG

で、いろいろ変えてみる前に、
まずは今の設定での効率を調べて、状況をきちんと把握する

ことから始めようと。

ということで、httping -c 100 -g http://www2.2ch.net/ の結果(cvsup.peko.2ch.netから)

connected to www2.2ch.net:80, seq=73 time=18.44 ms
connected to www2.2ch.net:80, seq=74 time=3014.49 ms
(略)
connected to www2.2ch.net:80, seq=75 time=21.35 ms
timeout receiving reply from host
connected to www2.2ch.net:80, seq=77 time=16.91 ms
connected to www2.2ch.net:80, seq=78 time=14.07 ms
(略)
connected to www2.2ch.net:80, seq=87 time=17.59 ms
connected to www2.2ch.net:80, seq=88 time=11.90 ms
connected to www2.2ch.net:80, seq=89 time=3017.84 ms
connected to www2.2ch.net:80, seq=90 time=3015.85 ms
(略)
connected to www2.2ch.net:80, seq=96 time=471.73 ms
connected to www2.2ch.net:80, seq=97 time=6219.80 ms
connected to www2.2ch.net:80, seq=98 time=15.69 ms
connected to www2.2ch.net:80, seq=99 time=19.33 ms
--- http://www2.2ch.net/ ping statistics ---
100 connects, 99 ok, 1.00% failed
round-trip min/avg/max = 11.7/449.1/6219.8 ms

**root▲ ★** · NG

同じく、www.2ch.net

connected to www.2ch.net:80, seq=94 time=2.66 ms
connected to www.2ch.net:80, seq=95 time=2.71 ms
connected to www.2ch.net:80, seq=96 time=2.67 ms
connected to www.2ch.net:80, seq=97 time=2.72 ms
connected to www.2ch.net:80, seq=98 time=2.69 ms
connected to www.2ch.net:80, seq=99 time=2.84 ms
...
--- http://www.2ch.net/ ping statistics ---
100 connects, 100 ok, 0.00% failed
round-trip min/avg/max = 2.6/2.8/4.6 ms

**root▲ ★** · NG

同じく、live22x.2ch.net

connected to live22x.2ch.net:80, seq=95 time=3.17 ms
connected to live22x.2ch.net:80, seq=96 time=3.26 ms
connected to live22x.2ch.net:80, seq=97 time=3.54 ms
connected to live22x.2ch.net:80, seq=98 time=3.13 ms
connected to live22x.2ch.net:80, seq=99 time=2.97 ms
--- http://live22x.2ch.net/ ping statistics ---
100 connects, 100 ok, 0.00% failed
round-trip min/avg/max = 3.0/3.2/6.3 ms

**root▲ ★** · NG

で、感想ですが、

matd はユーザランドで動いているせいか、15ms～18ms 程度
遅延が生じるようです。(これは想定内)

しかし、たまにがくっと遅くなることがあります。(想定外です)
>>179 では100カウントやって、1つタイムアウトになりました。
これの原因が知りたいところです。

banana403 や banana404 からやってみればいいのかな。

このへんで、まずはめしを。

株価【650】 ▲ ◆cZfSunOs.U · 2006/03/03(金) 12:58:33

>>182
>matd はユーザランドで動いているせいか、15ms～18ms 程度
>遅延が生じるようです。(これは想定内)

ユーザランドということもあるかも知れませんが，
http://qb5.2ch.net/test/read.cgi/operate/1121886018/901
　　>アプリとして動くみたいなので、カーネルとの切り替えがばかにならないのかなと。
　　>(パケット1個単位で切り替えですよね。)

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

のようにバッファリングしてるわけですが，その際の待ち時間が最大 10ms に
なっているので，それもあるかも知れません．

>しかし、たまにがくっと遅くなることがあります。(想定外です)
> >>179 では100カウントやって、1つタイムアウトになりました。
>これの原因が知りたいところです。

何らかの原因でパケットの取りこぼしが発生していることも考えられますが，
そうだとするとなぜ取りこぼすのか（処理が追い付かないのか，それとも別の要因か）ってのが問題ですね．

**root▲ ★** · NG

>>183
> のようにバッファリングしてるわけですが，その際の待ち時間が最大 10ms に
> なっているので，それもあるかも知れません．

なるほど、なるほど。

> 何らかの原因でパケットの取りこぼしが発生していることも考えられますが，
> そうだとするとなぜ取りこぼすのか（処理が追い付かないのか，それとも別の要因か）
> ってのが問題ですね．

そうですね。まさにこれを調べたいということで。

**root▲ ★** · NG

そもそも、普通のpingがいまいちであるらしいことに気がついた。

...
64 bytes from 206.223.150.74: icmp_seq=4 ttl=64 time=0.175 ms
64 bytes from 206.223.150.74: icmp_seq=5 ttl=64 time=0.264 ms
64 bytes from 206.223.150.74: icmp_seq=6 ttl=64 time=0.242 ms
64 bytes from 206.223.150.74: icmp_seq=7 ttl=64 time=0.205 ms
64 bytes from 206.223.150.74: icmp_seq=9 ttl=64 time=0.273 ms
64 bytes from 206.223.150.74: icmp_seq=10 ttl=64 time=0.234 ms
64 bytes from 206.223.150.74: icmp_seq=11 ttl=64 time=0.214 ms
64 bytes from 206.223.150.74: icmp_seq=12 ttl=64 time=0.195 ms
64 bytes from 206.223.150.74: icmp_seq=13 ttl=64 time=0.155 ms
64 bytes from 206.223.150.74: icmp_seq=14 ttl=64 time=0.259 ms
...
--- live22y.2ch.net ping statistics ---
30 packets transmitted, 28 packets received, 6% packet loss
round-trip min/avg/max/stddev = 0.155/0.222/0.287/0.036 ms

株価【650】 ▲ ◆cZfSunOs.U · 2006/03/03(金) 13:37:06

tcpdump とかで，httping かけてる時の banana403 / banana404 上でのパケットの流れ見てみるとか
......と言おうと思ったら

>>185 う～む，これはネットワークとかの問題でしょうか？

**root▲ ★** · NG

>>186
XOの高性能スイッチに繋がっているサーバの間の通信について、
パケットがきちんと通っているか、精査してみます。

**root▲ ★** · NG

おさらい: XOの２ちゃんねるラックにあって、高性能スイッチに繋がっているサーバ

サーバ名ホスト名接続I/F一覧
○雪だるま系 206.223.150.0/24 192.168.100.0/24
tiger503 live22x4 em0/em1
tiger507 live22x5 em0/em1
tiger2522 live22 em0/em1
tiger2523 live22x1 em0/em1
tiger2524 live22x2 em0/em1
tiger2525 live22x3 em0/em1
banana403 live22b1/www2 fxp0 fxp1
banana404 live22b2/www2 fxp0 fxp1

○携帯系 206.223.150.0/24 192.168.0.0/24
tiger511 blackgoat3 em0/em1
tiger512 blackgoat4 em0/em1
tiger2507 c-au4 em0/em1
tiger2508 c-au5 em0/em1
tiger2509 c-au6 em0/em1
tiger2510 c-docomo5 em0/em1
tiger2511 c-docomo6 em0/em1
tiger2512 c-docomo7 em0/em1
banana405 c-others1/c1 fxp0 fxp1
banana406 c-others2/c2 fxp0 fxp1

○どちらでもない系
tiger504 game10 em0
tiger509 news19 em0
tiger510 hobby7 em1
cobra2245 bbq bge0
(banana402 stock fxp0) 移動済みのはずだが、こないだの全停電でなぜか通信が途絶えた

**root▲ ★** · NG

まずは雪だるま系のパブリック側。
ping -c 30 サーバ名を実行

tiger2522 から、
tiger2523 ○
tiger2524 ○
tiger2525 ○
tiger503 ×
--- tiger503.maido3.com ping statistics ---
30 packets transmitted, 26 packets received, 13% packet loss
round-trip min/avg/max/stddev = 0.123/0.206/0.274/0.051 ms
tiger507 ○
banana403 ×
--- banana403.maido3.com ping statistics ---
30 packets transmitted, 27 packets received, 10% packet loss
round-trip min/avg/max/stddev = 0.135/0.192/0.298/0.031 ms
banana404 ×
--- banana404.maido3.com ping statistics ---
30 packets transmitted, 24 packets received, 20% packet loss
round-trip min/avg/max/stddev = 0.135/0.229/0.309/0.044 ms

**root▲ ★** · NG

>>188 修正

サーバ名ホスト名接続I/F一覧
○雪だるま系 206.223.150.0/24 192.168.100.0/24
tiger503 live22x4 em0/em1
tiger507 live22x5 em0/em1
tiger2522 live22 em0/em1
tiger2523 live22x1 em0/em1
tiger2524 live22x2 em0/em1
tiger2525 live22x3 em0/em1
cobra2247 未割り当て bge0/bge1
banana403 live22b1/www2 fxp0 fxp1
banana404 live22b2/www2 fxp0 fxp1

○携帯系 206.223.150.0/24 192.168.0.0/24
tiger511 blackgoat3 em0/em1
tiger512 blackgoat4 em0/em1
tiger2507 c-au4 em0/em1
tiger2508 c-au5 em0/em1
tiger2509 c-au6 em0/em1
tiger2510 c-docomo5 em0/em1
tiger2511 c-docomo6 em0/em1
tiger2512 c-docomo7 em0/em1
banana405 c-others1/c1 fxp0 fxp1
banana406 c-others2/c2 fxp0 fxp1

○どちらでもない系
tiger504 game10 em0
tiger509 news19 em0
tiger510 hobby7 em1
cobra2245 bbq bge0
(banana402 stock fxp0) 移動済みのはずだが、こないだの全停電でなぜか通信が途絶えた

**root▲ ★** · NG

>>189 に追加。

cobra2247 ○

**root▲ ★** · NG

banana403 から、
banana404 ○
tiger503 ○
tiger507 ×
--- tiger507.maido3.com ping statistics ---
30 packets transmitted, 24 packets received, 20% packet loss
round-trip min/avg/max/stddev = 0.135/0.214/0.270/0.038 ms
tiger2522 ×
--- tiger2522.maido3.com ping statistics ---
30 packets transmitted, 28 packets received, 6% packet loss
round-trip min/avg/max/stddev = 0.135/0.197/0.259/0.037 ms
tiger2523 ×
--- tiger2523.maido3.com ping statistics ---
30 packets transmitted, 27 packets received, 10% packet loss
round-trip min/avg/max/stddev = 0.148/0.207/0.316/0.042 ms
tiger2524 ×
--- tiger2524.maido3.com ping statistics ---
30 packets transmitted, 26 packets received, 13% packet loss
round-trip min/avg/max/stddev = 0.136/0.206/0.375/0.048 ms
tiger2525 ×
--- tiger2525.maido3.com ping statistics ---
30 packets transmitted, 26 packets received, 13% packet loss
round-trip min/avg/max/stddev = 0.132/0.204/0.386/0.053 ms
cobra2247 ×
--- cobra2247.maido3.com ping statistics ---
30 packets transmitted, 27 packets received, 10% packet loss
round-trip min/avg/max/stddev = 0.117/0.208/0.423/0.063 ms

**root▲ ★** · NG

これは、、、。

2つの「うまく通信できるグループ」があって、
その間のパケットはぼろぼろロストしてるってことなのか?

グループA tiger507 tiger2522 tiger2523 tiger2524 tiger2525 cobra2247
グループB tiger503 banana403 banana404

株価【850】 ▲ ◆cZfSunOs.U · 2006/03/03(金) 15:03:06

>>187-193 乙です．となると......スイッチがおかしいとか？

**root▲ ★** · NG

原因切り分けのため、
まったく関係ないところ(XOの外: PIE内部)からやってみた。

banana273 [206.223.147.225] から、

tiger2522 ○
tiger503 ×
--- tiger503.maido3.com ping statistics ---
30 packets transmitted, 25 packets received, 16% packet loss
round-trip min/avg/max/stddev = 1.280/1.428/1.766/0.116 ms
banana403 ×
--- banana403.maido3.com ping statistics ---
30 packets transmitted, 28 packets received, 6% packet loss
round-trip min/avg/max/stddev = 0.658/0.899/2.144/0.365 ms
banana404 ×
--- banana404.maido3.com ping statistics ---
30 packets transmitted, 28 packets received, 6% packet loss
round-trip min/avg/max/stddev = 0.675/0.764/1.148/0.091 ms

tiger503, banana403, banana404 だけがおかしい、で正解ですね。
でも、相互の通信はうまくいくと。

スイッチの設定上の問題の予感がします。
もう少し調べてから、状況(問題発生)をSeanさんにエスカレーションする方向で。

で、ここまでやっておじさんが
「stock (= banana402) と be (= ブラジル)との間の通信が微妙」と言っていたのを
思い出しました。

banana402は移動したと言っていますが、この間の電源トラブルのときに
巻き添えで落ちたので、同じスイッチに(あいかわらず)繋がっているのかもしれません。
これもあわせて、調べてみます。

**root▲ ★** · NG

> banana402は移動したと言っていますが、この間の電源トラブルのときに
> 巻き添えで落ちたので、同じスイッチに(あいかわらず)繋がっているのかもしれません。
> これもあわせて、調べてみます。

わーい、だめだこりゃ。

--- banana402.maido3.com ping statistics ---
30 packets transmitted, 23 packets received, 23% packet loss
round-trip min/avg/max/stddev = 0.665/0.734/0.801/0.041 ms

**root▲ ★** · NG

ちょっとひどそうなので、
>>190 のやつ全部、調べなおす方向で。

で、XOだけならいいんだけどということで、age。

● ◆ANGLERlqvM · NG

なるほど、今までの不思議に思っていたことが
何か見えてくるかもしれませんね。