[debian-users:17357] Re: 大量メール配送時の不具合

[タロン <taron@xxxxxxxxxxxxxxx>]

タロンです

Hiroyuki Hasegawa <admin@xxxxxxxxxxxx> さんは 大量メール配送時の不具合 にて
> 長谷川です。
> 
> > これは　ファイルオープンが　Linux カーネルの制限　255 - 3 (stdin/stdout/stderr)
> > 分に引っかかって　いるとおもいますが
> > > これは、プログラムからの呼び出しの問題なのでしょうか・・・
> > > C言語から、popenでsendmailと通信して、pcloseで閉じているだけなのですが。
> > 上記　252 を超えることは　ありませんか？
> 
> popen〜pcloseまでの処理が繰り返し行われる回数は、252を超えています。
> pcloseしてもファイルオープンされている扱いなのでしょうか。
> たとえば、fopen 〜 fcloseを何度繰り返しても、問題はないですよね？閉じてる
> わけですから。
> それとも、呼び出されたsendmailのプロセスがファイルをオープンしているために
> 出るエラーなのでしょうか。
> 
> もしpcloseしてもオープンされている扱いなら、一度に処理できるメール数が252通
> （あるいはそれ以下）に限られてしまうということですよね。
> 
> うーん。困った。。。
> 大体psコマンドで見ていると、130ほどsendmailプロセスで埋め尽くされた時点で
> segmentation fault か、Too many open files in system などが表示され、psコマンド
> 自体も実行できなくなります。
> 
> > > maxQueueRunSize =10000
> を100などにしても、起動されるプロセスは抑制できないみたいです。
でしょうね
これは　キューを吐き出すためのものじゃないかな？

CGI　-＞　sendmail
で起動されて　コネクションする場合の話ではないように感じます
＃知ったかぶりかな？

/var/spool/mqueue に溜まってるファイルが　たくさんあったりした場合
は　相手のサーバが　なかなか応答してくれない場合にこの状況になった
覚えが　あったりします

私の遭遇したケース　
　応答してくれなかったのが　たまたま　Nifty のsmtp だったりするんですが
　これがラウンドロビンで　11個のmx が並んでいますが
　この状況になると　コネクションをはってからhelo をぜんぜんお話してくれ
　ません。
　それで　linux の場合のデフォルトのタイムアウトが　90分だったりします
　から 最悪　11 × 90分　ひとつのコネクションでまたされます
　（　90分=> O'REILLY　ジャパン
　　　sendmail リファレンス　sendmail 2nd Edistion　p350より）

ですから　

対策１　コネクションタイムアウトを短くする
まず　このコネクションタイムアウトを　通常の　5m にしました
O Timeout.connect=5m
　　コメントアウトされた状態

対策２　smtpfeed の導入
それでもキューから　nifty宛てに　メールが吐けないので
smtpfeed を導入したわけです

smtpfeed だと　同じMX のサーバだと　コネクションを切らずに
続けて　smtpでのお話をしてくれます

この辺は　/usr/sbin/sendmail -q -v
とすると　キューに溜まったメールを吐き出す状況が見えるので
分かりやすいです
単体のsendmail の場合と　smtpfeed 導入した場合とで動きの違いが
良く分かります

> 
> カーネル再構築しか手がないのでしょうか。そのパッチでどのくらいのファイルオープ
> ン数の増加が見込めるのでしょうか・・
たしか　３０００ぐらいだったと思います


Linux 2.2.xx カーネルのほうは　自分で解決
http://www.linux.or.jp/JF/JFdocs/kernel-docs-2.2/proc.txt.html
に記述が　ありました　(^^ゞ
file-nr / file-max 関連

*********************************
タロン　　　　
   <taron@xxxxxxxxxxxxxxx>
   　他論　ではなぁい
*********************************