【Project peko】2ch特化型サーバ構築作戦 Part13

>>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
>>969

>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の場合、重くなっても最終的に立ち直ることが多いあたりに
何かヒントがありそう。