【実験】ミニ雪だるま作戦―ex7で3/8 3:10あたりから実験はじめます
■ このスレッドは過去ログ倉庫に格納されています
3/8 3:10 あたりから ex7 で、ミニ雪だるま作戦実験のPart2をやります。
ex7の板で、3/8 3:15ごろまで書けたのに急に書けなくなったとか、
様子がおかしくなったとかいう人は例によって、
・症状
・使用ブラウザ
・プロバイダ名
・あと、役に立ちそうな情報があれば
を、こちらに報告くださいです。 今日(9日)は狼の全板トーナメント予選日なので
あまり無茶しない方がいいですよっと これで、しばらく動かすか。
今、普段と比べて重い? 見ている範囲では、いつものex7になったような気がするけど、どうかな。 一時の重さはなくなったと思う
Jane Doe View α 0.1.11.1 YBB はけが悪いというより、K(eepalive)状態のリクエストが異様に多かったのですよ。
あ、そうか、あたりまえか。
httpd <=> squidは ローカル接続なんだから、あっという間に掃けるわけか。
Kの数が異常に多くなって、スロットが足りなくなっていたのですね。
で、それを解消して、直ったと。
あと、ローカルキャッシュのパフォーマンスが、出せるかどうかですね。
機を見て、再開してみるか。 たまに「もさっ」となることがあるですね。
これは、何が原因だろう。
これを直してから、ローカルキャッシュのテストをしてみるか。 見てる範囲では、やっぱりいつものこの時間のex7。
「もさっ」となるのも含めて、かも。
もうちょっと、観察。 2005/03/08 07:23:57| comm_accept: FD 7: (53) Software caused connection abort
2005/03/08 07:23:57| httpAccept: FD 7: accept failure: (53) Software caused connection abort
2005/03/08 07:23:57| comm_accept: FD 7: (53) Software caused connection abort
2005/03/08 07:23:57| httpAccept: FD 7: accept failure: (53) Software caused connection abort
これが出るときに、もっさりするみたい。 ex7意外にも色んな鯖でおしなべて subject.txt の読み込みが遅いのだけどここ関係ない? 重くないと、試験にならないんですよね、、、。
たぶん、峠越えちゃったんじゃないかと。 つか、根本的な問題解決してないすね。
1箇所、リブートしないといけない設定変更をします。
0:55あたりからリブートします。5分ぐらい。 おいいいいいいいいいいいいいいい
一番大事な時じゃねーか!!!!!! >>243
お前、必死すぎwwwwwwwww
お前のせいで100%絵本は無い まさかと思ってきてみればやっぱり実験wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww >>248
は?
女神の追加うpあっただろうが。
工作員乙 ベド暴れんなよwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww 何度もリブートしているのに連続稼動していることになってますか?
http://ch2.ath.cx/load/ > ex7 >>253
83 動け動けウゴウゴ2ちゃんねる 05/03/09 00:58:36 ID:jvkZTtmn0
絵本のAA作らないと
92 動け動けウゴウゴ2ちゃんねる 05/03/09 01:00:00 ID:jvkZTtmn0
絵本だぞお前ら絵本
乙wwwwwwwww たまに、微妙に重い時があると思います。(>>232)
これは、別途対策。
さて、それ以外の大きな問題は2つか。
・現象
LAは高くなかった。CPUのidle timeすらあった
のに、全体にもっさりしていた
・もっさり問題
httpdの資源が貧しくなって、datの表示までに時間がかかるようになった
対策: KeepAliveTimeoutを10から3にし、httpdが貧しい状態からは脱出
・特に一部ブラウザで、subject.txtとるのにえらい時間がかかる問題
ローカルキャッシュを一時的にスルーしたところ、速くなった。
FreeBSD+aufsだと、こういう系(すごい勢いで小さいファイルがアクセスされる)は、苦手なのかもしれない
対策: diskd使うために以下の設定を/boot/loader.confに入れ、リブート(リブート必須)
# for squid diskd
#kern.ipc.msgmni=40
kern.ipc.msgmnb=8192
kern.ipc.msgtql=2048
kern.ipc.msgssz=64
#kern.ipc.msgseg=2048
入れないと、このエラーが出る
storeDiskdSend: msgsnd: (35) Resource temporarily unavailable
(長くなったので続き) 設定変更のテストします。
数分程度、不安定になります。 いま娘ドキュが終わって盛り上がってる最中で
この実験落ちはきついものがあります
それでも応援しますよ >>264 続き
設定変えたのに、これが出続けるなぁ。
2005/03/08 08:23:57| storeDiskdSend: msgsnd: (35) Resource temporarily unavailable
2005/03/08 08:23:57| storeDiskdSend OPEN: (35) Resource temporarily unavailable
2005/03/08 08:23:57| ctx: exit level 0
2005/03/08 08:23:57| storeDiskdSend: msgsnd: (35) Resource temporarily unavailable
2005/03/08 08:23:57| storeDiskdSend OPEN: (35) Resource temporarily unavailable
2005/03/08 08:23:57| storeDiskdSend: msgsnd: (35) Resource temporarily unavailable 板一覧更新するとERRORが起きて、ノートン先生まで発動するんだけど ソース読んだら、、、SYSCTL_INTじゃん。
ごそごそしてきます。 >>273
あのスレのせいだな
まだ落ちてなかったのか.
実験とは直接関係ないよ >>264 のですが、
kern.ipc.msgmax: 131072
kern.ipc.msgmni: 40
kern.ipc.msgmnb: 2048
kern.ipc.msgtql: 40
kern.ipc.msgssz: 64
kern.ipc.msgseg: 2048
となっていて、kern.ipc.msgtql=2048 と kern.ipc.msgmnb=8192 が反映されていない。
で、sys/sysv_msg.c を読むと、、、。
%grep TUNABLE_INT sysv_msg.c
TUNABLE_INT_FETCH("kern.ipc.msgseg", &msginfo.msgseg);
TUNABLE_INT_FETCH("kern.ipc.msgssz", &msginfo.msgssz);
TUNABLE_INT_FETCH("kern.ipc.msgmni", &msginfo.msgmni);
まじかよ。この2つチューナブルじゃないじゃん。
カーネル作り直しか、、、。
作業できたら、再度リブート入れます。 # for squid
options MSGMNB=8192 # max # of bytes in a queue
options MSGMNI=40 # number of message queue identifiers
options MSGSEG=512 # number of message segments per queue
options MSGSSZ=64 # size of a message segment
options MSGTQL=2048 # max messages in system
を入れて、カーネル再構築中。
# そういえば、BlackGoatの時も、やったかな、これ。 で、ふと統計情報を見ると、、、。
今オンメモリのキャッシュだけで動かしてるのに、ヒット率下がってないですね。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/snowman/
つまり、HDDになんか無理してキャッシュしなくていいってことじゃないか。これ。
無理にdiskdを動かすの、やめにしよう、そうしよう。
つまり、再度のリブートは、いらなくなった予感。 ということで、今日重くなった時からの対策まとめ:
1) squidでのHDDへのキャッシュをやめ、オンメモリだけにした
2) httpdのKeepAliveTimeoutを10から3に変更した
これで、今日のex7の設定変更は、概ね終了、、、のはず。 設定変更中の問題?
(・∀・)サテオシゴト ε三三(; ・∀・)鯖マデオツカイ
Socket Error # 10061
Connection refused.
( ・∀・)(・∀・ )オツカイオワリ 三三3
(・∀・∀・)
(・∀・)ナンカエラーダッテ
(・∀・)カンリョウ!! squidが、5割ぐらいCPUを食うようになった。
disk I/Oに引きずられなくなったせいですね。
働けるようになったので、昨夜発生した重いのと同じ原因では、
重くはならないはず(別の原因は、ありえるかも)。
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
32734 squid 118 0 88932K 86996K CPU1 1 3:53 62.55% 62.55% squid
32202 ch2ex7 105 0 12276K 11396K select 3 1:24 26.12% 26.12% speedy_back
32947 ch2ex7 105 0 12336K 11508K select 1 1:05 25.93% 25.93% speedy_back
31904 ch2ex7 105 0 12300K 11452K CPU3 3 1:59 24.90% 24.90% speedy_back
33873 ch2ex7 102 0 11352K 10408K select 0 0:21 13.99% 13.96% speedy_back
34256 ch2ex7 100 0 11352K 10472K select 0 0:06 9.71% 8.11% speedy_back
32957 ch2ex7 106 0 12668K 11784K select 1 1:01 5.27% 5.27% speedy_back
34083 ch2ex7 102 0 10820K 9944K select 2 0:04 2.00% 1.95% speedy_back
31727 ch2ex7 99 0 12472K 11580K select 3 1:02 0.88% 0.88% speedy_back >>281
…だと思います。
再発したら、レポートください。
今夜はたぶん、何か気づかない限りもう設定変えない予定。 で、、、blackgoat4からのdatリクエストが一時的に多くなったのは、
ex7と間違って一部ローカルキャッシュのファイルを消してしまったから、
というのは、内緒にしておいてください、、、。
http://mumumu.mu/mrtg/mrtg-rrd.cgi/traffic/blackgoat4traf.html ということで、問題点の整理:
・i.i2ch.net / t1 t2 t3 の問題 => 中の人が解決
・Live2chで過去ログが見られない件 => ステータスコードだけ見るようにしてもらえるとうれしい
・Live2chで「subject取得が中断されました。」と出ることがある件 => 未解決
観察が必要なもの:
・ラッシュアワーに「もっさり」が再発するか、しないか
・ラッシュアワーに「subject.txt取得が異様に重い」が再発するか、しないか httpReadReply: Excess data from "GET http://ex7.2ch.net/test/offlaw.cgi/morningcoffee/... (以下略)
と出た。
超長いURIは、デフォルトではやばいのか。
どれ、変えればいいのかな。 これか。40 KBに変更。
# request_header_max_size 20 KB
# for long URL of offlaw.cgi
request_header_max_size 40 KB >>288 を変えるために、1回落として、上げたです。>>287 いどう。
gzipでやってないと、そういうことですか。
その場合(部分的にsubject.txtがとれた状態で)、スレッドはとれるんですか。 >rootさん
ちなみに再現性100%ではないです。
たまーに、NISをONにしてても全部読めます。
>>291
やってみます。 いきなりそのトリップすか。
たまに全部とれるってのも、ふしぎ。 >>291
受信制限して、途中までしか取得出来ない場合でも
スレッド自体はちゃんと読めますね。 gzipで取りにいくための条件ってあるんですか?
NISがそこを弾いてると思ったりするんですが、、 そちら、fusianasanして大丈夫ですか。
こっちでログみたりパケットとったりしたいので、
可能であればリモホをさらしていただけると助かります。
無理にとはいわんです。 >>296
YahooBB219018100033す。 う、セキュリティ上、bpf切ってあるんだ。< ex7
1回リブートが必要だなぁ。 >>297
ex7のApacheのログには見当たらないですね、、、。
squidのログをオンにしてきます。ちょっとまっててください。 今設定変えてるので、変えてからおながいします。>>301 >>303
>>303
ONとOFFで2回ずつぐらいやってみました。 httpdのログは、ぜんぶ200か304ですね。
つまり、正常。
squidのほうも、正常。200ばかり。
サーバ側は、ちゃんと送れた気でいるようです。 やっぱ、tcpdumpしないとわからんですね。
準備が必要だなぁ。 作者のgeroたんもおそらく何らかの対応をすると思うんですよね。
まぁ根本的にNISがgzipで取得しにいかないなら対応しないかもしれませんけど。。 んじゃ、NISありとなしで、これ踏んでみてください。
http://ex7.2ch.net/test/printenv.cgi
で、
HTTP_ACCEPT_ENCODING="gzip,deflate"
があったかなかったか、教えてもらえますか。 >>310
やはりNISを切ると出ますね。>gzip
#timecount/timecloseに引っかかった、、 ■ このスレッドは過去ログ倉庫に格納されています