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

**root▲ ★** · NG

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

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

等を取り扱います。

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

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

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

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

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

株価【450】 ▲ ◆cZfSunOs.U · 2006/03/03(金) 15:20:32

matd の挙動調査から思わぬ展開に......
でもまぁこういう問題を発見できたのはよかったと．

● ◆ANGLERlqvM · NG

>>199
そうですね。
こういうのは、何かきっかけが無いと分かりにくいですから。
問題が発見できたのは良かったと思います。

**root▲ ★** · NG

banana273 から、

banana405 ×
--- banana405.maido3.com ping statistics ---
30 packets transmitted, 24 packets received, 20% packet loss
round-trip min/avg/max/stddev = 0.657/7.266/158.052/31.441 ms
banana406 ○

不思議だ。同じOSバージョン同じサブネット同じネットワークI/Fなのに。
やはり、スイッチですね。

**root▲ ★** · NG

まさか「proxyに繋がらない。。。」の頻発も、これが原因?

ってことは、プライベート側もきちんと精査しないといかんということですね。

**root▲ ★** · NG

banana273 (XOの外にあるone of standard banana)から、まとめ。

パブリック側I/Fでパケット落ちが起きているのは、
banana402 = stock
banana403 = www2
banana404 = www2
banana405 = c/c1/c-others1
tiger503 = live22x4
tiger2511 = c-docomo6
の6台。

banana402 ×
banana403 ×
banana404 ×
banana405 ×
banana406 ○

tiger503 ×
tiger504 ○
tiger509 ○
tiger510 ○
tiger511 ○
tiger512 ○

tiger2507 ○
tiger2508 ○
tiger2509 ○
tiger2510 ○
tiger2511 ×
--- tiger2511.maido3.com ping statistics ---
30 packets transmitted, 26 packets received, 13% packet loss
round-trip min/avg/max/stddev = 0.645/0.752/0.871/0.049 ms
tiger2512 ○

tiger2522 ○
tiger2523 ○
tiger2524 ○
tiger2525 ○

cobra2245 ○
cobra2247 ○

**root▲ ★** · NG

続いて、プライベート側の調査。
プライベート側は目的毎に独立した2つのサブネットあり。

雪だるま系: 192.168.100.0/24
banana403 から。

tiger507のプライベート側がだめ。

banana404 ○
tiger503 ○
tiger507 ×
--- 192.168.100.6 ping statistics ---
30 packets transmitted, 24 packets received, 20% packet loss
round-trip min/avg/max/stddev = 0.147/0.262/1.422/0.245 ms
tiger2522 ○
tiger2523 ○
tiger2524 ○
tiger2525 ○
cobra2247 ○

**root▲ ★** · NG

(続き)

携帯系: 192.168.0.0/24
banana405 から。

プライベート側I/Fでパケット落ちが起きているのは、
banana406 = c/c2/c-others2
tiger2509 = c-au6
tiger2510 = c-docomo5
tiger2512 = c-docomo7
の4台。

ごていねいに、全キャリアに一つ以上異常なのがある。
この「ババ｣を引くと、「proxyに繋がらない。。。」が頻発していると。

banana406 ×
--- 192.168.0.1 ping statistics ---
30 packets transmitted, 26 packets received, 13% packet loss
round-trip min/avg/max/stddev = 0.150/0.263/1.020/0.196 ms
tiger511 ○
tiger512 ○
tiger2507 ○
tiger2508 ○
tiger2509 ×
--- 192.168.0.163 ping statistics ---
30 packets transmitted, 27 packets received, 10% packet loss
round-trip min/avg/max/stddev = 0.140/0.307/1.027/0.204 ms
tiger2510 ×
--- 192.168.0.164 ping statistics ---
30 packets transmitted, 27 packets received, 10% packet loss
round-trip min/avg/max/stddev = 0.141/0.222/0.352/0.059 ms
tiger2511 ○
tiger2512 ×
--- 192.168.0.166 ping statistics ---
30 packets transmitted, 28 packets received, 6% packet loss
round-trip min/avg/max/stddev = 0.153/0.290/1.097/0.225 ms

**root▲ ★** · NG

ということで、

1) なぜこんなことがXOの特定のスイッチで起こったのか

状況をみる限りでは、
何らかの意図(帯域制限など)を持って設定しているとは考えられないおかしさです。

=> 先日の停電でスイッチがおかしくなった or 壊れた?
=> 何か設定を変えた?
=> その他?

2) どうすれば直るのか

=> スイッチのリセット?
=> スイッチの設定修正?
=> スイッチの交換?

なお、このスイッチは1Gbps対応・VLAN設定対応等可能で、
処理能力もスイッチとしてはPIEでいちばんでかいもののはずです。

つまりもし万一スイッチのハードウェア障害だとすると
tiger サーバや cobra サーバと同様、
交換部品がどきどき、、、以下略の予感も。

**root▲ ★** · NG

いずれにせよXOの一部サーバの通信に異常が発生している、
という状況はつかみました。

また携帯系の「proxyに繋がらない。。。」が急に多発するようになったのも、
ほぼこれが原因と考えられます。

状況を書いて、Seanさんに調査と修正依頼を出すことにします。

とりあえず、以上で、
しばらく本業のため、依頼メール出すのはしばらく後になります。

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

2証で時々発生してるｴﾗｰ
「be.2ch.netとの通信に失敗しました」
これも、それのせいなのかな？

**root▲ ★** · NG

>>208
↓
>>196

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

即ﾚｽすぎて、ちょっとﾋﾞｯｸﾘ
ふむふむ、2証は402なのか・・・

原因が判明すれば諦めがつきますね、どうもでしたヽ(´―｀)ノ

**root▲ ★** · NG

このぐらいでPIEのネットワーク的がへたれる(トラフィックとか処理量とか
ことはないと思うので(*1)、たんたんと不具合報告して、たんたんと直してもらうということで。

(*1 じゃなきゃこんな↓プロモーションを大々的にやらないだろうと)
http://www.maido3.com/server/banana100/

● ◆ANGLERlqvM · NG

お疲れ様でした。
これで、多分スッキリしますね。

**root▲ ★** · NG

1) 電源春暖によりおかしくなったかもしれないので、
まずはスイッチをリセット・電源再投入してもらう

2) それでもだめなら、じっくり取り組む

で、いこうかと。

1) は Sean さんとのタイミングがあった時にやろうと思うので、
ショートノーティスでいきなりやる可能性あるです。

つまり「やるよー」「ぼん」で、一時的に実況とニュー速と携帯が、
数分程度全部死にます。

というわけで、あらかじめ告知(これがそれに相当)をば。

**root▲ ★** · NG

>>213
> 1) 電源春暖によりおかしくなったかもしれないので、

うわーん。瞬断だってば。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/03(金) 18:17:55

もう春ですからね～
北海道は雪降ってますけどｗ

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

　　　　　　　∧__∧
　　　　　　（＞＜*　）いつでも来てくださいませっ！
　　　　　　（⊃⌒*⌒⊂)
　　　　　　　/__ノωヽ__）

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

>root氏
何時ごろになるんでしょ？

**root▲ ★** · 2006/03/03(金) 20:06:44

366 名前：root▲ ★[] 投稿日：2006/03/03(金) 20:06:22 ID:???0
Davidさん、Jimさん、私(Seanさん)にまずはパケット落ちの状況を送ってくれ、
という話になりました。そのうえで対応すると。

すぐのリブートはなくなりました。
以降は別スレにて。

>>217
ということで、状況次第ですね。

**root▲ ★** · 2006/03/03(金) 20:29:15

Seanさん、Davidさん、Jimさんにメールを送った。
管理人と関係者にCc:。

**root▲ ★** · 2006/03/03(金) 20:45:05

Sean-san, David-san, Jim-san,
Cc: 2ch related folks, (中の人)-san,

This is Mumumu.

As I already reported to Sean-san, now we encountered suspicious packet
dropping (approx. 15%-30%) at XO location servers.

I investigated the current status of the trouble, and I will report to
you about it per-server basis.

Please be careful: A part of XO servers are connected two network I/Fs.
So, I call "primary I/F", it is xx0 I/F on FreeBSD (em0, fxp0, bge0),
and "secondary I/F", it is xx1 I/F on FreeBSD (em1, fxp1, bge1).

The following I/Fs of servers are now in trouble.

banana402 (primary I/F: fxp0, 100Mbps FDX)
banana403 (primary I/F: fxp0, 100Mbps FDX)
banana404 (primary I/F: fxp0, 100Mbps FDX)
banana405 (primary I/F: fxp0, 100Mbps FDX)
banana406 (secondary I/F: fxp1, 100Mbps FDX)
tiger503 (primary I/F: em0, 1Gbps FDX)
tiger507 (secondary I/F: em1, 1Gbps FDX)
tiger2510 (secondary I/F: em1, 1Gbps FDX)
tiger2511 (primary I/F: em0, 1Gbps FDX)
tiger2512 (secondary I/F: em1, 1Gbps FDX)

Please investigate the trouble and fix it.

These servers are very important because they have so many
mobile phone users and 2ch BBS for TV live broadcast users.

Best regards,

**root▲ ★** · 2006/03/03(金) 20:57:55

スイッチのリブート by Seanさん、入りました。

これから確認しますが、パケロスなくなったっぽい。

--- tiger503.maido3.com ping statistics ---
30 packets transmitted, 30 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.204/1.502/3.830/0.451 ms

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

お疲れ様です。

PCのこちら側で小躍りしてみます。

**root▲ ★** · 2006/03/03(金) 21:04:44

www2のパケットロス・遅延ともになくなりました。
全てがうまくいっているように見えます。

64 bytes from 206.223.150.96: icmp_seq=23 ttl=63 time=0.832 ms
64 bytes from 206.223.150.96: icmp_seq=24 ttl=63 time=0.779 ms
64 bytes from 206.223.150.96: icmp_seq=25 ttl=63 time=3.529 ms
64 bytes from 206.223.150.96: icmp_seq=26 ttl=63 time=0.754 ms
64 bytes from 206.223.150.96: icmp_seq=27 ttl=63 time=10.495 ms
64 bytes from 206.223.150.96: icmp_seq=28 ttl=63 time=13.702 ms
64 bytes from 206.223.150.96: icmp_seq=29 ttl=63 time=21.688 ms

--- www2.2ch.net ping statistics ---
30 packets transmitted, 30 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.668/2.298/21.688/4.608 ms

**root▲ ★** · NG

banana403 = www2 の受付嬢

にログインしてみました。

生まれ変わったように反応が速くなっていました。

どうやら先日の停電以来、
XOロケーションのスイッチが、ずっと本来の力を発揮できない状態に陥っていたようです。

**root▲ ★** · NG

Seanさんは明日に備えてオフラインになりました。

こうなれば急ぐことはないので、
じっくり調べて、結果を別途メールで報告する旨伝えました。

私もいったん、オフラインで。

**root▲ ★** · NG

これなら、live22x系もmatdにのっけても大丈夫な予感。

明日昼にでも改めて、banana403/404のリブートテストとかそのへんを。

**root▲ ★** · NG

概ね問題ないことを確認しました。

教訓: 高性能でインテリジェントなスイッチはある種サーバと同じところがあり、
電源を手順に従ってきちんと落としたりきちんと上げたりしないと、
不可解な状態に陥ることがある。

で、不可解な状態になると原因の切り分けは結構大変。

株価【520】 ▲ ◆cZfSunOs.U · 2006/03/03(金) 21:36:57

>>223-226 乙です．すんなり解決でめでたしめでたしですね．

**動け動けウゴウゴ２ちゃんねる** · 2006/03/03(金) 21:43:44

>>224
ごみでもたまっていたんでしょうかね。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/03(金) 21:54:23

メモリにゴミファイルと虫が....カサコソしてた。

まぁ今は順調だからよかた。

#いつからパケットロスあったんだろう？
#これはパケロスしてるかいちいちping掛けないといかんのね。

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

>>230
瞬断のあとって意外にメモリの内容がごく一部化けているケース多い

それでエラーが出て変な状態になるケースは
エンタープライズなレベルではよくある話みたいですな

◆TWARamEjuA · 2006/03/03(金) 22:50:05

そういえば、httpdのレスポンスが変な鯖があったような希ガスるです。。。＠いまさら

**root▲ ★** · NG

>>232
どれかしら、、、。

◆TWARamEjuA · NG

>>233
えっと、もう記録が残っていないので何とも云えないのですです（苦笑）＠監視係。のliveデータ

**root▲ ★** · NG

>>220 への自己フォロー
Folks,

Sean-san rebooted the Summit switch and all of the trouble of packet
dropping is now fixed.

I've checked servers and I verified all 2ch XO servers are fine.
Sean-san, thank you for your work.

So, we've got a good experience for intelligent switch management.
It is very sensitive and suddenly power outage is sometimes very
harmful for intelligent switch, too.

Regards,

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

>>227
瓢箪から駒のようで、乙でした。
public側も電車男スイッチにつながっていたのですね。
てっきりprivate側用のスイッチと思っていました。

>>166
FreeBSDだったら、CARPで仮想IPをそれぞれに割り当てて、
DNSラウンドロビンでできるようなきがする。
マルチキャストフレームが同一VLAN内に流れると思うので、
同じネットワークに属するホストの負荷が高くなるかもしれませんが。

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

春ということで全サーバ/スイッチの再起動をしておくとかするとどうなるのかな

◆Reffiz2Zh. · 2006/03/04(土) 08:38:24

スケジュールには載ってないんですがBETA3出ましたねぇ
そろそろRCだと思ったんですが

**動け動けウゴウゴ２ちゃんねる** · 2006/03/04(土) 13:56:46

某有名メーカーのHUBはAutoネゴシエーション設定の状態で
ケーブルの抜き差しすると認識状態が変わったりします。
(100MFull→100Mhalf)

一部機器では100MFullしか受け付けないものもあり
問題になります。(なりました(つД｀) )

各HUBのポート設定はどうなってますか？

**root▲ ★** · 2006/03/04(土) 15:14:13

>>236
> public側も電車男スイッチにつながっていたのですね。

ですね。VLAN切っていると。

で、CARP使うですか。
マルチキャスト(というかたぶんエニーキャストの方が適切かな)なわけですが、
それ(フレームが流れること)は、私もちょっと気になったです。

>>237
不可解なトラブルが出てからでもいいかんじ。

>>238
BETA3いきましたか。
ということは、多分例によってちょっと遅れですね。

>>239
PIEでも、これまでもたまに問題になったです。
今は、
10Mbpsなサーバでは、full-duplexを明示的に指定していて、
100Mbpsなサーバでは、autoでネゴがうまくいくやつはautoで、
autoだとhalf-duplexになってしまうものはfull-duplex指定しているです。

前、100Mbps full-duplex固定指定で一度パフォーマンスが出なくなってしまう
症状が起こったので、そうしているです。(このスレの過去ログにあるはず)

**root▲ ★** · 2006/03/04(土) 15:15:42

で、週明けにでも live22x 系を matd 環境に移行しようかなと。

**root▲ ★** · 2006/03/04(土) 15:40:53

>>155 のテストも含めて、ex14をApache 2.2系にしてみるか。

**root▲ ★** · NG

こんなものが、davidxuさんのところに。
http://people.freebsd.org/~davidxu/patch/libc_thr_stubs.patch

何のパッチだろう。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/05(日) 00:43:46

>>243
davidxuさんといえば、かなり前から1:1 threadの改良をやっているんで、
その一環じゃないですかね?
ttp://www.freebsd.org/news/status/report-jan-2005-mar-2005.html#libthread
ttp://lists.freebsd.org/pipermail/freebsd-threads/2005-January/002778.html

**root▲ ★** · NG

>>242
%httpd -V
Server version: Apache/2.2.0
Server built: Mar 4 2006 07:15:17
Server's Module Magic Number: 20051115:0
Architecture: 64-bit
Server MPM: Worker
threaded: yes (fixed thread count)
forked: yes (variable process count)
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/worker"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_FLOCK_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT="/usr/local"
-D SUEXEC_BIN="/usr/local/sbin/suexec"
-D DEFAULT_SCOREBOARD="/var/run/apache_runtime_status"
-D DEFAULT_ERRORLOG="/var/log/httpd-error.log"
-D AP_TYPES_CONFIG_FILE="etc/apache22/mime.types"
-D SERVER_CONFIG_FILE="etc/apache22/httpd.conf"

で、Makefile.local に
CONFIGURE_ARGS+= --enable-nonportable-atomics

って書いてみた。

**root▲ ★** · NG

>>244
リンク先読みました。そのようですね。

今試し中のパッチもdavidxuさんのもの(>>138)です。
で、明日夜は何やら高トラフィックが来るとか、なんとか。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/05(日) 16:16:10

うちの環境だと
ttp://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libpthread/thread/thr_kern.c.diff?r1=1.120&r2=1.121
の修正を入れないとMySQL+libpthreadが高負荷で落ちるんですが、
apache workerは大丈夫ですか?
いつMFCされるのかな。

**root▲ ★** · 2006/03/05(日) 18:17:27

>>247
Revision 1.121 / (download) - annotate - [select for diffs], Thu Feb 16 01:33:36 2006 UTC (2 weeks, 3 days ago) by deischen
Branch: MAIN
CVS Tags: HEAD
Changes since 1.120: +1 -0 lines
Diff to previous 1.120 (colored)

Don't forget to initialize a tailq before using it.

MFC candidate
Noticed by:luoqi

んーむ、当てたほうがよさげですね。

**247** · 2006/03/05(日) 18:41:09

ソースを見る限り、TAILQを初期化せずに使用しているという明らかなバグなの
で、パッチ当てた結果、動作が変になることはないはずです。
ちなみに、MySQLはsignal 10で落ちます。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/05(日) 18:43:31

シグナル10！！！！

**root▲ ★** · 2006/03/05(日) 18:49:33

>>249
どうもです。live22に当ててみました。
live22x[123] にも、当てたほうがいいかもですね。

httpd も例の虫を踏んだ場合には signal 10 で落ちているです。
同じ理由かもですね。

とりあえず libpthread.so を作り直して、httpd と bbsd をリスタートしました。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/05(日) 18:50:28

これは期待しちゃっていいのかな？
今夜がすげえ楽しみです

**root▲ ★** · 2006/03/05(日) 18:57:33

>>252
虫取りを2つ当てたので、それが効果あるかということになるですね。
手ごたえは確かですが、さて、どうなるのか。

**root▲ ★** · 2006/03/05(日) 19:15:28

>>247 を、live22x[123] にも当ててみた。

**247** · 2006/03/05(日) 20:33:53

よくコードを見てみたら、M:N スレッドの場合は、問題の部分が実行される可能
性はほとんどないですね・・。なので、パッチ当てなくても大丈夫だったかも。

あと、FreeBSD + Apache 2.2.0(worker)の場合、configureスクリプトが
pthread_kill()関数の検出に失敗するんですが、これってよく知られているのかな。
上記理由により、apacheの終了時に
child process XXXX still did not exit, sending a SIGTERM
のログが出て、結構うざかったりします。
% env CFLAGS="-O2 -pthread" ./configure --with-mpm=worker
のように-pthreadを環境変数に指定するときちんと検出するんで、うちでは
そうやってます。
ただ、mod_perl2なんかを組み込むと、上のようにconfigureをやってもやっぱり
still did not exitのログは出ちゃいますね。

**root▲ ★** · 2006/03/05(日) 20:45:20

>>255
> 上記理由により、apacheの終了時に
> child process XXXX still did not exit, sending a SIGTERM
> のログが出て、結構うざかったりします。

原因はそれだったのですか、、、。

で、M:Nスレッドやめて、1:1にしてみるかな。
やっぱり虫踏むんで。

**247** · 2006/03/05(日) 20:50:00

個人的には、6.0-RELEASE以降のlibthrはお薦めです。
ほとんどの場合、libpthreadより速いですし、現在も活発に開発されてますし。

**root▲ ★** · 2006/03/05(日) 21:13:02

httpdが暴走する症状が、出るようになった。 < フロント
Apache 2.2 系の虫なのかも。

**root▲ ★** · 2006/03/05(日) 21:28:49

うーん、どうやろうが、

os_version="600034"
# 502102 is when libc_r switched to libpthread (aka libkse).
if test $os_version -ge "502102"; then
apr_cv_pthreads_cflags="none"
apr_cv_pthreads_lib="-lpthread"
else

が選ばれるようになっている、、、。
( in srclib/apr/configure )

これは、libthr 化するのは容易ではないっぽい。

**247** · 2006/03/05(日) 21:32:31

/etc/libmap.confを使用すれば良いのでは?
echo "libpthread.so.2 libthr.so.2" > /etc/libmap.conf

**root▲ ★** · 2006/03/05(日) 21:45:44

>>260
やはりそれですか。

今日の騒ぎが落ち着いたら、やってみるです。

# prefork MPM にしました。< live22

**root▲ ★** · 2006/03/05(日) 21:48:55

LA=340 かぁ。

prefork MPM でも、
やっぱりだめなものはだめか。

ということは、スレッドが原因じゃないっぽいですね。

**動け動けウゴウゴ２ちゃんねる** · 2006/03/05(日) 21:49:50

>>262
落ちてますorz

**root▲ ★** · 2006/03/05(日) 21:49:53

LA=750

手が出せないや。

**root▲ ★** · 2006/03/05(日) 21:50:58

装置が働けば、それなりに動くと思うけど、
また死ぬ予感。

◆Reffiz2Zh. · 2006/03/05(日) 21:52:52

数値があり得ない値に（滝汗
完全に何かが暴走している伊予柑

ttp://mumumu.mu/mrtg/mrtg-rrd.cgi/load/live22load.html

**root▲ ★** · 2006/03/05(日) 21:53:50

live22x のスレは、流れまくりなんで、ここで。

もう1回落とします。< live22