2ch特化型サーバ・ロケーション構築作戦 Part32
■ このスレッドは過去ログ倉庫に格納されています
2ch特化型サーバ・ロケーション構築作戦のスレッドです。
・2ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更関連の各種作業や調整事項
・2ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携
等を取り扱います。
前スレ:
2ch特化型サーバ・ロケーション構築作戦 Part31
http://qb5.2ch.net/test/read.cgi/operate/1235553306/ connect() に対して connection aborted が返ってくるのは早かったので帯域じゃないと思います。
connection aborted はソケットの backlog(listernキュー)があふれて撥ね返されている状態
なので httpd がリクエストを捌けてないんだと思います。
StartServers が小さいので「どーん」に弱いというお話でしたが、一度 MaxSpareServers まで
上がってしまえば(MaxSpareSreversが適正ならば)徐々に回復するはずで、
今回はリブートするまで長時間ずっと回復しなかったので、StartServers のせいかどうか。
逆にサーバー性能に対して MaxSpareServers を大きくとりすぎたために、「どーん」と来たときに
Apacheが身動き取れなくなったんじゃないかという気がします。
一番疑わしいのはディスクの iowait ですが、もしかしたら Apache内の排他制御とかで詰まってたのかも。
いずれにしてもボトルネックがわかrないと対策しようがないですね。 >>541
アランドロン風に「それが2ちゃんねるさ!」 yutori7鯖のMaxClientsだかなんだかの設定って教えてくれないかにゃ? tsushima httpd を強制的にリスタートしてみた。 >>542
自己レス
× MaxSpareServers
○ MaxClients or SreverLimit こういう見切り発進で知らずにやってきた利用者を
巻き込むあたりが実に2chらしいわなw
こういうのを楽しめないでマジ怒りする無粋な奴は
黙って寝てろってノリだしw >>542
> connect() に対して connection aborted が返ってくるのは早かったので帯域じゃないと思います。
なるほど。
その他の分析もきわめて論理的ですね。
MaxSpareServers が大きすぎるのも確かにつらいです。
「どーん」の時に fork しまくりになるわけで。
因みに私は「どーん」が予想されるサーバでは基本的に、
・httpd は最初から最大数待たせる
・ひまでも数は減らさない、「どーん」はいつ何時起こるかわからないから
ようにしているです。 誰だよ、復活一番乗り書き込み目指してリロードしてる馬鹿はw >>550
りょうかいです。私のほうでも確認しました。
今日は私のほうではもうこれ以上手の施しようがないかんじですね。(´・ω・`)
しばらくは涙流しながら放置ということで。 >>546
Linuxのは、商用のディストリビューションをテストする時のやり方。
想定クライアント数を越える、Max Client数を割り出すときのやり方。
基本は、サービスをとめないというテスト法。
FreeBSDは、カーネルハッキングできるような人間がやることを前提にしている。
そのため、資料は乏しい。どっちかといえば、つっけんどん。 落ちる→リブートの繰り返し何度もやるくらいなら
しばらく放置して熱冷めるの待った方が安全ですな。
帯域が問題ならいつかの時みたいにgzipで圧縮すれば?
CPUパワー有り余ってるんだろ PIEの中の人とICQして、tiger3547のグラフ見せてもらいました。
ここにはちと出せないですが(非公開URLにつき)、
100Mbps 天井までは行ってなかったです。70Mbpsぐらい。
しかもグラフがピンっと上がる*前に*、つぶれていました。
つまり一撃でKO負けした感じ。
ということで、
>>542
> connection aborted はソケットの backlog(listernキュー)があふれて撥ね返されている状態
> なので httpd がリクエストを捌けてないんだと思います。
というのが正解のようですね。
いきなり「どーん」と来て、httpd が起動というか fork() しきれなくて、
> 「どーん」と来たときに
> Apacheが身動き取れなくなったんじゃないかという気がします。
という状態になった、というのが農耕かな、という気がします。 今日は諦めてくれ
というかそう言ってくれたら寝られるし 寝る前にもう1回ずつリブート要請かな。< yutori7、tsushima
1:00 回れば人も減ってくるだろうから。 「今はあきらめてください」 >>561
これでよいかしら。 >>556
なるほど。
にしても試してないけどUbuntu上だと
sudo aptitude install ltp
して
sudo ltpmenu
するだけでいいとか簡単すぎワロタ。
>>560
メモリ足りてるならforkも問題なくできるはずでは? rootさんが寝たら明日の朝まで復活しないじゃん・・・ >>565
> メモリ足りてるならforkも問題なくできるはずでは?
いやぁ、そうはイカのなんたらかと。
fork() のコストはものすごいから。 root頼むよ何とかしてくれ
ついでにキャップくれ >>564
明日からもがんばれって言ってくれたら
がんばれる気がする 工具足りなかったらうちいっぱいドライバーあるから言ってね。 forkが負荷高くて駄目ならしないようにすればいい→誰も来ない状態で大量にfork? >>568
cpuも余ってたんでしょ? 追いつかなくても適切な処理はなされるはずだし、なされてないなら原因はやっぱりデッドロックだし。 >>572
> forkが負荷高くて駄目ならしないようにすればいい
↓
やばそうなサーバでははじめから最大数(>>551)
というかんじで。 今日はもう寝るから
明日も朝から仕事だし
帰宅する20:00までには復帰しておいてくれ これ以降はPIEに常時yutori7とtsushimaを
監視しといてとでも言うしかないな >>563
>寝る前にもう1回ずつリブート要請かな。< yutori7、tsushima
その後落ちたら、そのまま放置? rootもおまいらも早く寝ろ
体壊さない程度にしとけ A-tiger相当の性能のサーバを立てたのですがFreeBSDも奥が深いですね >>573
上のほうでもありましたが、
> backlog(listernキュー)があふれて撥ね返されている
というかんじですね。
ちなみに httpd は普通に kill できるので、
わたし的にはデッドロックという印象は持っていないです。 >>578
> その後落ちたら、そのまま放置?
あとは適宜リブート要請(誰でも可能)というパターンかと。
ただすぐ落ちる状態でリブート要請しても、またすぐ落ちるだけかと。 人が減ったっぽいので、さっき 1:00 頃に httpd を kill してみた。< tsushima >>584
了解です。
取り敢えず、ゆっくり寝てくださいませ。 >>591
数えるプログラムが謎のハングアップしてた。
リスタート完了。 いつの間にか新生ゆとりが投入されたと思いきや、なんかありそうな感じで・・・
# あまり流れがよくわかってませんが tsushimaが復活したし、yutori7は今夜は諦めようよ。
rootさんお疲れ様でした。 るーたん今日はもう寝ていいよ
お疲れさまであります(´・ω・`) 1:30 になったので、
httpd を kill してみた。< yutori7 ツイッターにサイバー攻撃か 利用不可能に
2009年8月7日1時15分
【ワシントン=勝田敏彦】短い「つぶやき」を自由に書き込んだりできる人気の交流サービス
(SNS)のツイッターが米東部時間6日朝、トラブルのため、利用できなくなった。
7月に韓国や米国の政府機関などが受けたのと同様の、DoS(サービス拒絶)攻撃と
呼ばれるサイバー攻撃を受けている可能性があり、ツイッターの運営会社が原因を調べている。
AP通信によると、ツイッターは利用者が多すぎる場合や点検などのためにサービスを停止する場合があるが、
今回はそうではないという。
http://www.asahi.com/international/update/0807/TKY200908060372.html
これ今回のと関係ありそう? そういえばこれってもう修正されたんだっけ? まだだっけ?
Apacheに新たな脆弱性発見
http://slashdot.jp/security/article.pl?sid=09/06/23/0455215
>この脆弱性は、これを利用したHTTP DoSツール「Slowloris」がリリースされたことから明らかになったとのこと。
>この攻撃ツールはApacheに不完全なリクエストヘッダーを送り続けるもので、Apacheが最後のヘッダが送られてくるのを待つ間、偽のヘッダを送ることで接続をオープンにし続け、Apacheのプロセスを一杯にさせるものだという。 >>600
yutori7復活した!!
無利しやがって…(´;ω;`)
rootさん乙です。 >>600
GJであります。
おつかれさまでした。 今回みたいな場合、あらかじめ
「1時になったらやります」「1時30分になったらやります」みたいなことは言えないですね。>>605
だって、そんなこと言ったらみんなその瞬間に(りゃ。
あとは朝に向けて人は減る一方だと思うので、
とりあえずお手柔らかにおながいします、というかんじで。 >>607
こういうケースなら人が減ってきただろう頃合いにしれっとやらないと…
あとは、落ちないことを願うのみです。
お疲れさまでした。 あらかじめ鯖を増強しておくのも必要かと。
本日はお疲れ様でした。 >>607
ごもっとも。
どうぞ、ゆっくり寝てください。
近所だったら寝酒を差し入れしたい気分だ。 ざっと見てきましたが、おかしくなってる板は無い様で
rootさん乙でした。 >>613
お酒飲めません。。。
下戸遺伝子ということで。 >>615
じゃ、甘味大量投下。
rootさんがFOXと同じ都市なら郵便受けに入れておくw おいちゃんにおねだり
じっぷら(liveplus)を、yutori7からatlantaに移転してほしい 高木先生の日記。
高木浩光@自宅の日記 - やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合
http://takagi-hiromitsu.jp/diary/20090802.html
「蛸壺化」というのはなかなか。 んで、のりぴーが発見されたらまた落ちる可能性があるわけだけども >>431
いや、PIEも儲かるのわかってて、コストに見合うと判断すれば帯域を解放するでしょ。
そのへんはパケモンの技術担当兼PIE COOのJimさんの判断になるんだが。 >>560
さあ、オレンジ畑で農耕してくるんだ(ぇ
>>564
Releaseになる時点で、今よりはややましにはなりますかね。
所詮観測的希望ってやつですが まあ、rootさんで設定できる箇所が限られてる鯖ですんで
全設定を触れる人が根本的に直さないことには
常時こんなことだらけと思ったほうがいいっすね rootさんがsudoできるようにすればいいような。
そういう訳にはいかないのか こっちに書いておくか。
top すると、
39597 ch2yutor7 1 44 0 79308K 13560K keglim 7 0:00 0.00% httpd
39531 ch2yutor7 1 44 0 80252K 13484K keglim 5 0:00 0.00% httpd
39506 ch2yutor7 1 44 0 78192K 13488K keglim 3 0:00 0.00% httpd
39557 ch2yutor7 1 44 0 79296K 13632K keglim 2 0:00 0.00% httpd
というのがいっぱい並んでいるですね。
状態欄が keglim というのはあまり見かけないけど、
この状態になると、もうだめぽな模様。 カーネルソース grep してみた。これかな。
%find . -name '*.[ch]' -print | xargs grep keglim
./vm/uma_core.c: msleep(keg, &keg->uk_lock, PVM, "keglimit", 0); どうやら ./kern/kern_mbuf.c か。
keg とかこのへんに結構ある。
ということは、ネットワークの鍛えが足りないかんじかも。
mbuf が少ない、というより増やしてないとか。 これかな。
ソケットのバッファ最大値がデフォルト値のままなのね。< yutori7
・changi namidame anchorage 等
%sysctl kern.ipc.maxsockbuf
kern.ipc.maxsockbuf: 20480000 <= 増やしてある
・yutori7
%sysctl kern.ipc.maxsockbuf
kern.ipc.maxsockbuf: 262144 <= デフォルトのまま ■ このスレッドは過去ログ倉庫に格納されています