【実験】ミニ雪だるま作戦―ex7で3/8 3:10あたりから実験はじめます
■ このスレッドは過去ログ倉庫に格納されています
3/8 3:10 あたりから ex7 で、ミニ雪だるま作戦実験のPart2をやります。 ex7の板で、3/8 3:15ごろまで書けたのに急に書けなくなったとか、 様子がおかしくなったとかいう人は例によって、 ・症状 ・使用ブラウザ ・プロバイダ名 ・あと、役に立ちそうな情報があれば を、こちらに報告くださいです。 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だと振る舞いが違うんだろう。 news19のprintenv.cgiは、消しました。 >>314 振る舞いが違うというよりは、もっさりしてるとでも言うでしょうかね。 >HTTP_ACCEPT_ENCODING= これ自体が表示されないので、ちょっとNISの設定を色々見てみます。 私もNIS+Live2chにできるので、待機しますね。 NISはブラウザのgzipのヘッダを隠避します。。。 設定等で変更もできないので、●で過去ログ読む時もNIS切らないとダメだったり。 VIPスレ一覧取得できねーと思って運営覗いてみたら何かの実験中だったのね 原因はNISか… NISもLive2chも手放しがたいなぁ >>316 それ自体が表示されないってことは、 NISありだとそっちから、 Accept-Encoding: gzip,deflate が、サーバに送られていないということです。 これだとサーバ側は、圧縮しないで普通に送るしかなくなります。 なんだかなぁ。 news19でも起こったということは、、、。 いったい、何が違うんだろう。 news19のprintenv.cgiを復活させますので、 NISありで両方でやってみて、表示に違いがあったら、教えてください。 >>317 >NISはブラウザのgzipのヘッダを隠避します。。。 そでしたね、、忘れてた。 http://info.2ch.net/wiki/pukiwiki.php?%A5%CE%A1%BC%A5%C8%A5%F3%C6%FE%A4%EC%A4%BF%A4%E9%A3%B2ch%A4%CB%BD%F1%A4%AD%A4%B3%A4%E1%A4%CA%A4%A4%BF%CD%A4%D8#faq09 > 696 名前:●持ち 投稿日:02/11/05 19:44 > ブラウザのgzipのヘッダを隠避する為に、 > ●の過去ログ閲覧が出来ない件でシマンテックから電話が来た。 > > 「過去ログ見るときはファイヤーウォール無効にしてください。」 > > 馬鹿野郎ぉぉぉぉぉぉぉー(ノ ̄ ̄∇ ̄ ̄)ノ~~~━━┻━┻━━ もしかすると、NIS利用者は2ch利用時常にNISを切らなきゃならなくなるのか… 馬鹿野郎ぉぉぉぉぉぉぉー(/ ̄▽)/┳━┳~┫~┻━┻~┣~┳━┳\(▽ ̄\) 馬鹿野郎ぉぉぉぉぉぉぉー #当方ルーター入れたので、NISはアンインスコしたが。 全部ex7仕様になると、そういう事ですかね。。>>322 ex7とnews19の出力の違いは、、、 -SERVER_ADDR="127.0.0.1" +SERVER_ADDR="206.223.152.65" -SERVER_PROTOCOL="HTTP/1.0" +SERVER_PROTOCOL="HTTP/1.1" か。 SERVER_ADDR、あやしいかも。 ていうか、subject.txtだけ変になるってのも、いまいちだなぁ。 正直、こっちではどうしようもない予感もする。 >>325 それで、HTTP_ACCEPT_ENCODINGの隠避の制御は出来ないよ。 #NIS2005は、どうだか知らないが。 あと、live2chだけおかしいってのも、納得できないすね。 >>325 それはRefererを送るようにする設定なのですね。 >>324 tiger503では出力しないんですか? >ex7 >>329 それって、どういう意味かしら。 # 今、printenv.cgiを片付けたところ。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる