【実験】ミニ雪だるま作戦―ex7で3/8 3:10あたりから実験はじめます
■ このスレッドは過去ログ倉庫に格納されています
3/8 3:10 あたりから ex7 で、ミニ雪だるま作戦実験のPart2をやります。
ex7の板で、3/8 3:15ごろまで書けたのに急に書けなくなったとか、
様子がおかしくなったとかいう人は例によって、
・症状
・使用ブラウザ
・プロバイダ名
・あと、役に立ちそうな情報があれば
を、こちらに報告くださいです。 重くないと、試験にならないんですよね、、、。
たぶん、峠越えちゃったんじゃないかと。 つか、根本的な問題解決してないすね。
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を片付けたところ。 勘違いした、、>tiger503では出力しないんですか とりあえずLive2ch側でどうにかなると思うですよ。
たまーに取得できたりするわけですから。
geroたん降臨待ちという事で、 というか、tiger503でやっても、意味ないと思うです。
>>333 ということですかね。
とりあえず、原因の一端がわかったということで。
おつかれさまでした。 ■ このスレッドは過去ログ倉庫に格納されています