- 締切済み
sendmailメールの一斉配信に失敗します
業務系webアプリの運用担当者です。 システムの機能としてメールの一斉配信ができるのですが、 webアプリからの一斉配信に部分的に失敗します。 300通の配信指定に対し、実際には50通前後で配信が中断されていました。 (前後、というのは何度か配信を実行し50通程度なら一斉配信できたという意味です) ログレベルが低く細かい解析はできていないのですが、 syslogをみると配送できていたアドレスのみ「Sent OK」で記述されていました。 実際の負荷量によるとは思うのですが、 想定しているのは300通程度の一斉配信です。 宛先MTAはほぼばらばらになります。個人向けフリーアドレスも相当数あります。 配信にたとえ数十分かかっても、ちゃんと送信できればいいのです。 現在の設定では、子プロセスを一切生成しないようになっています。 そこで、sendmail.cf内下記を変更することで解決を試みようと 考えました。 ・変更前現在の値 #O ForkEachJob=False #O MaxDaemonChildren=0 ・変更後の想定値 O ForkEachJob=True O MaxDaemonChildren=20 私の解釈では、この変更によりキューが発生した際には子プロセスを最大20個 まで生成し分散処理され、300通のメールが無事配送されることを想定しています。 マシンスペックは大まかに、 ハードウェアはSunFire、OSはSolaris9、 CPU:1GHz、Mem:1GB となっています。 what コマンドを使用したsendmailバージョン表示が下記です。 # /usr/ccs/bin/what /usr/lib/sendmail | grep -i version $Id: version.c,v 8.163.2.8 2006/07/26 17:24:02 ca Exp $ システムの本番環境のために試しにいろいろ変えてみるというのはやりづらく、 運用実績のある方からコメントを頂戴できますと幸甚です。 どなたかこのあたりのチューニングを経験された方はいらっしゃいますでしょうか。 宜しくお願い致します。
- みんなの回答 (2)
- 専門家の回答
みんなの回答
- jf5qdk
- ベストアンサー率80% (4/5)
思いつく限りでは3点あります。 ・相手先MTAの設定 負荷分散のため、携帯キャリアのMTAなどは連続して同じMTAから大量配信があるとある一定以上は後回しにされます。確か、ログにはSENT Defferredと出たと思います。(もしかしたらISPのMTAが転送を拒否ってるのかも??) この場合はスクリプトのメール送信部分を10通送ったら10分休むという仕組みを入れて回避したことがあります。 ・リゾルバが逆引きできない この設定は嫌いですが、よく見かけます。 IPからドメインを逆引きできなければ怪しいメールと判断して自ドメインにキャッチしないという設定です。官公庁さんとかでよく見かけます。 これはDNSで自サーバを逆引きできるように設定するか、相手のMTAの管理者に相談するしかありません。 ・サーバのマシンパワー不足 恐らくよっぽど古いハードでない限り300通でダウンすることはないと思いますが・・・ ログのレベルが深くないと解決は厳しいかもしれません;;
- wwrbmania
- ベストアンサー率100% (1/1)
最近sendmailは触ってないので参考になるかどうか分かりませんが、 もう少し情報収集した方が良いように思います。 1.「宛先MTAはほぼばらばら」とのことですが、あなたのサーバから直接 それぞれのMTAに接続しているのでしょうか? 例えばデータセンターの メールサーバを一旦経由するような場合、そこがボトルネックになっている(あるいは、DoSと認識されているとか)可能性も考えられるかと思います。 2. syslogに記録されているということは、サーバ上でsendmailが利用できているものと思いますが、その場合、送信されなかったメールはキューに残ってはいないでしょうか? 残っていればいずれ送信されると思いますので、「たとえ数十分かかっても」というニーズには合致するかと思います。 3. MaxDaemonChildren はサーバとしての待ち受けデーモンの数なので、送信する際に役立つかどうかはwebアプリがメール送信する際の実装方式に依存すると思います。
お礼
情報収集とのこと、ごもっともです。 説明不足ですいません、 1.データセンターのメールサーバを経由していますがDoSへの拒否などのログは特になく、送れた分だけ送れた旨のログがでます。 2.キューには残っていません。恐らく一定程度のキュー以降はアプリが送りそびれているかsendmailが受け付けてもいないかです。 3.最終的にアプリの改修も視野に入れて可能な範囲でのチューニングに腐心しています。もしsendmailのチューニングで効果がなければ具体的な実装の変更箇所も見えてくると思います。 ご意見有難う御座います。
お礼
・相手先MTAの設定 送信間隔をスクリプトの細工で解決できるんですね。 参考になります。 ・リゾルバが逆引きできない 逆引き設定はISP側に委譲してありますので心配はないと思います。 ・サーバのマシンパワー不足 ご指摘の通りで、ログレベルを変えればかなりわかる部分が増えると思います。改善作業の際には、ログレベルを上げ且つ他に少しでも効果があると思われる変更を施し配信実行、効果の程度をみながら解析をすすめるつもりです。ご意見有難う御座います。