【実験】ミニ雪だるま作戦―ex7で3/8 3:10あたりから実験はじめます
■ このスレッドは過去ログ倉庫に格納されています
3/8 3:10 あたりから ex7 で、ミニ雪だるま作戦実験のPart2をやります。 ex7の板で、3/8 3:15ごろまで書けたのに急に書けなくなったとか、 様子がおかしくなったとかいう人は例によって、 ・症状 ・使用ブラウザ ・プロバイダ名 ・あと、役に立ちそうな情報があれば を、こちらに報告くださいです。 これで、しばらく動かすか。 今、普段と比べて重い? 見ている範囲では、いつもの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に引っかかった、、 >>311 まじっすか。 じゃ、http://news19.2ch.net/test/printenv.cgi はどうですか。 おなじく、NISあるなしで、 HTTP_ACCEPT_ENCODING="gzip,deflate" があるのかないのかを調べてみてください。 >>312 同じっす、、 しかしNIS利用者は多いけど、みんなgzipで取りに行ってないのかしら、、 えーーー、まじかよ。 NIS使うと、gzip無効ってことかい。 しかしどうして、ex7だと振る舞いが違うんだろう。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる