【Project peko】2ch特化型サーバ構築作戦 Part13
レス数が1000を超えています。これ以上書き込みはできません。
>>950
これ(2ch.netのNSのTTL)が300secなのはたしかにいまいちすね。
maido3.comのNS(下記)のように、glueと同じ259200がいいと思われ。
$ dig +norec -t ns maido3.com @ns1.maido3.com.
; <<>> DiG 9.3.0beta4 <<>> +norec -t ns maido3.com @ns1.maido3.com.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52168
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; QUESTION SECTION:
;maido3.com. IN NS
;; ANSWER SECTION:
maido3.com. 259200 IN NS ns1.maido3.com.
maido3.com. 259200 IN NS ns2.maido3.com.
;; ADDITIONAL SECTION:
ns1.maido3.com. 259200 IN A 206.223.148.254
ns2.maido3.com. 259200 IN A 206.223.147.254
;; Query time: 218 msec
;; SERVER: 206.223.148.254#53(ns1.maido3.com.)
;; WHEN: Thu Jun 17 12:12:17 2004
;; MSG SIZE rcvd: 96 ここにも貼っておこうと。
read.cgi再開発スレ
http://qb5.2ch.net/test/read.cgi/operate/1087199303/49
49 名前：root ★[] 投稿日：04/06/17 12:04 ID:???
>>16 で言及した、
mmap()を使用しないread.cgiをgame6サーバに実験的に入れてみた。
これでしばらく実験してみるということで。 もうご存じでしたらスマソ
http://qb5.2ch.net/test/read.cgi/operate/1087192862/745,762
745 名前：あいとまこと [sage] 投稿日：04/06/17(木) 02:06 ID:RkTSpuVo
sports2.2ch.netのDNSのTTLを増やしたほうがいい気がする。
762 名前： ◆BDFCNV1.to [sage] 投稿日：04/06/17(木) 02:19 ID:OxK2wp5V
>>745
86400 にしてみた。 >>952
というわけで、以下を入れてみた。
read.cgi再開発スレ
http://qb5.2ch.net/test/read.cgi/operate/1087199303/52
52 名前：root ★[] 投稿日：04/06/18 03:43 ID:???
20日以上動いていたgame6が、read.cgiを上げたら半日で死にました。
mmap()ではなかったと。
ということで、
live8(read.cgiを動かしている)とcomic4(携帯の負荷に耐えている)で実績のある、
以下の設定を追加してみた。
(従来)
<IfModule prefork.c>
StartServers 64
MinSpareServers 5
MaxSpareServers 32
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 0
</IfModule>
(現在)
<IfModule prefork.c>
StartServers 64
MinSpareServers 5
MaxSpareServers 32
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 100000 <= 変更
MaxMemFree 2048 <= 追加
</IfModule> >>954
そこを追加したり変更したりすると
どんな期待が持てたりするんですか? >>955
MaxRequestsPerChild は、ここで書いた回数だけリクエストを処理すると、
httpdプロセスが再起動します。これで、メモリが開放されることが期待できます。
c.2ch.netではこれを入れたおかげで、異常なスワップ消費によるハングアップ
(例のswap_pagerエラー)が出なくなりました。
MaxMemFreeは、Apacheのメモリアロケータが保持することができる
メモリを制限するものです。これで、httpdがどんどんメモリをつかんでしまうことを
抑制します。これもc.2ch.netのチューニングでわかったノウハウです。
これを入れた上で、read.cgiを動かしはじめたです。< live8/live9
参考: http://ns1.php.gr.jp/pipermail/php-users/2004-May/022181.html ちなみに、c/comic4についてはこれの131あたりから。
【漫画アニメ系】comic4が重い重い重い重い重い重い×５
http://qb5.2ch.net/test/read.cgi/operate/1086507653/ (dat落ち) >>958
乙です。
昨日(今朝)のgame6突然死ですが、例の901-244シリアル直結
作戦でも歯が立たなかったんでしょうか？
http://qb5.2ch.net/test/read.cgi/operate/1084429098/444 まだハードのせいにしてごまかそうとしているとは恐れ入った。
Jimさんも「日本人ってこんなんばっかし」とあきれ顔。 comic4は、/home (掲示板システム)のディスクI/Oの詰まりが原因でした。
datキャッシュと携帯との遅いI/Oの影響がもろに出たかんじ。
できるだけこうならないようにチューニングはしているのですが、
何らかのタイミングで詰まった模様。
ということで、掲示板以外のI/O処理(バックアップ等)を一時的にとめます。 >>959
そういえばと思い出して、tipコマンドでつないでいざDDBに落とそうとしたら、
options DDBとoptions BREAK_TO_DEBUGGERが
game6で有効になっていなかったことに気づきました。
仕方なく通常のリブート要請して改めてチェックしてみたところ、通常の
ログインプロンプトも来ないようです(gettyは動かしている)。
シリアルケーブルが抜けている状態かもしれません。
別途確認してみます。 ということで、リモートからデバッガに落とせない状態なので、
いったんgame6のread.cgiを止めます。 なんとなくなんですが、不具合の原因で
BBQなどの管理システムとの衝突の可能性(いわゆる相性)ってありえますかね。 なんか自分で>>964を読んでいてもわけわかめですわ。スマソ。
いわゆる2chが投入している複数鯖を介している各種システムが
システムクラッシュを起こすような悪さをしていないか、ということ。
read.cgiをとめている状態ならば安定していることを考慮すると、
read,cgiでコールしていてdat直読みでコールしていない関数の
いづれかが犯人かもしれないってことです。 >>966
とはいえ、read.cgiにシステムクラッシュを引き起こす
致命的なバグが潜んでいる可能性もありえますがね。
その説でいくとわかっていることは
「mmap()は犯人ではなかった」ということだけ。 >>967
今明らかになっているのは、
http://qb5.2ch.net/test/read.cgi/operate/1087199303/53
にあるように、apache-2.0.xのCGI周りにメモりリークの問題がある
ということだけ。この問題は、最悪のケースで、CGIの出力4096バ
イトごとに32バイトずつのメモリがリークするというもの。
なので、apacheの設定変更で改善の兆しが見えるということは、
メモりリークの影響がシステム陥落の引き金の一つになっている
らしいことはうっすらと見えてきた。
read.cgiを有効にしていると、これまたシステム全体が落ちやすくなる。
ということは、read.cgiも引き金の一つのようだ。ただし、read.cgiを
動かしただけで落ちるわけじゃないので、read.cgiが直接システムを
落としているわけではない。古いread.cgiのソースを見る限り、
read.cgiはDATファイルをmmap()し、要求された部分をhtmlソースと
して出力するCGIプログラムで、特徴としては、実行終了までDAT
ファイルをmmap()し続けるというあたり。つまり、プロセス終了まで
の間、仮想メモリをDATファイルサイズ以上握りっぱなしになる。
なので、処理中のread.cgiプロセスが溜まると、仮想メモリの消費
量が増える。
fox.cgiもたしか仮想メモリを消費しまくるものだったように記憶している。
以上から乱暴に予想すると、FreeBSDの仮想メモリ周りにバグが
いるんじゃないかな。実メモリが不足し始めるあたりで落ちている
のかも。……とすると、mmap()版と非mmap()版のread.cgiの影響
はシステムへの負荷のかけ具合という点でやや違いがある可能
性はある。 >実メモリが不足し始めるあたりで落ちている
これは肌で感じました。 >969
>969
オフィシャル見ると今月だけもで重要な修正かなり入ってるようですね。
ttp://www.freebsd.org/cgi/query-pr-summary.cgi >>968
なるほど。この線は「本筋」である気がします。
i386(banana)は同じ5.2.1Rでも概ね安定に動いているので、
amd64版で特に顕在化する問題であるということは考えられます。
メモリ2Gや3Gのマシンが、4Gのマシンより不安定になるというのも、
> 実メモリが不足し始めるあたりで落ちている
というのを裏付けている気がします。 >>968
なるほど。
実を言うと最近はうっすらとしか状況を見ていなかったので
よくわかっていなかったんですが・・・・w
FreeBSDとapache両方でパッチあての必要がある悪寒。
というわけで>>968を某スレへ投げておきます。 短期的に取れそうな対策としては、
- メモり不足に陥らないためにapacheの設定をつめる。
- read.cgiが暴走してたりしないかチェックする。
- read.cgiを、なるべく早めにmunmap()するように書き換える。
- 敗北感が漂うけれど、シングルプロセッサ設定を試して見る。
comic4の場合、重くなっても最終的に立ち直ることが多いあたりに
何かヒントがありそう。 - TimeOutのデフォルト300秒は多分長すぎるので、思い切って短縮。
- KeepAlive Off。
あたりも効くかも。 >>976
#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 300
なるほど、これを短くするのは意味がありそうですね。
特に携帯相手とかだと。
KeepAlive Offは既に全pekoサーバで実施済みです。 >>977
さっそく、c.2ch.netでTimeoutを300 => 30にしてみた。
【漫画アニメ系】comic4が重い重い重い重い重い×６【もうダメぽ】
http://qb5.2ch.net/test/read.cgi/operate/1087641975/80-91 ということで、c/comic4のTimeoutを20に再設定。
【漫画アニメ系】comic4が重い重い重い重い重い×６【もうダメぽ】
http://qb5.2ch.net/test/read.cgi/operate/1087641975/105-110
105 名前：root ★[sage] 投稿日：04/06/19 23:13 ID:???
詰まってきたので、Timeoutを30=>20にしてみた。
これ以上短くすると、ちょっと副作用がありそうだなぁ。
110 名前：root ★[sage] 投稿日：04/06/19 23:27 ID:???
今日はこれでしばらく様子見してみようかなと。< c
このTimeoutは、
・クライアントがつながってからGET要求を受け取るまで待機する時間
・POSTまたはPUT要求時にTCPパケットを受け取るまで待機する時間
・TCPパケットに応答するACKを受け取るまで待機する時間
だから、携帯がいくら遅いといっても、10秒ぐらいにまではしてもいいかも。 あぼーん過去ログ再構成プロジェクト
http://qb5.2ch.net/test/read.cgi/operate/1080237257/177-180
ということで、memoriesの全ホストについて
残っていたライブdatを全部dat落ちさせました。(174124スレッド)
また、>>954 の設定を追加しました。 >>980
乙でーす。
240 名前： ◆BFzK/mtqM2 投稿日：04/06/12 15:32 ID:4m0m2MQA
すみません。
移転した鯖の携帯用ページが生きています。
確認できたのは、
【etc】
http://etc.2ch.net/utu/i/
【comic2】
http://comic2.2ch.net/rcomic/i/
その他の旧鯖（現在はmemories上）も同様な気がします。。。。
この辺もそのうち直してほしいな。。。 >>979 続き。
それでもピーク時間には詰まってしまい、LAが3ぐらいなのに全然つながらない状態となったため、
(newsplus/mnewsplus等のニュース系は携帯読者が多い)
思い切ってTimeoutを5秒にしてみた。
>>981
これは具体的にどうすればいいのかしら。 >>982
PCと同様に新しい鯖へのリダイレクトがよいです。
>>985
了解です。
いよいよ、あれに対応するのかな。 なんだか対策本部になるかもしれないので、次スレ立ててきます。 あれあれ、あれだよアレ!
ところで、付き合ってる奴を孕ませちゃって、
おろしたいんだけど、金が足りないんだよ。
かねかしてくんねーかなー。
今から口座番号教えるからー 乙です。
いよいよアレですか。
微力ながら協力いたします。 立てました。タイトルをちょっと変更。
【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part14
http://qb5.2ch.net/test/read.cgi/operate/1087666806/ このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。 レス数が1000を超えています。これ以上書き込みはできません。
