現在のサーバの構成、と言うようなもんじゃないですが、postfix, postgres, apache, php がすべて1サーバに入っています。
同様のサイトで外部のメール配送エンジン(sendmagicなど)を導入することで改善した事例があるので、メール配送後にアクセスが集中したことによる負荷がメインではないことは確認済みです。vmstat などでの調査によると、特に disk に負荷がかかっているようです。
できる限り、アプリケーション側(PHP)での解決を望んでいますが、メールサーバを分け、SMTPを直接喋るのが良いのでしょうか。
私の認識では、アプリケーションと同じサーバに入っているMTAに mail関数 で配送を依頼するのと、SMTPで接続して HELO...QUIT するのとでは差はない、と認識していますが間違っていませんでしょうか。
また、よくあるモバイル向けメール配送エンジン流量調整をどのような方法で行い、高速大量配送(1IPで数万通/h)を実現しているのかについても、方法がわかればトライしたいと思っています。
よろしくお願いします。
これは製品ですか、こういう風にCPUの使用率を制限して、他に支障の出ないようにsendmail(postfix)を動かしたらどうですか?
http://hitachisoft.jp/Products/Sendmail/products/switch/index.ht...
製品を使わなくても、テクニック的にはもっと簡単にできると思うのですが。
このあたりのpostfixの設定で、メモリやプロセス数などを制限できるようなのですが。リソース制限および速度制限というところです。
postfix 自体のチューニングは詳しくないですが、
CPUの使用というよりは通信・ディスクに問題が出るんじゃないでしょうか。
これは一般的な設定での注意事項なので、サイト側が多量のメールを送る場合ではないのですが、留意点としてはやはりメモリやCPUの制限、プロセス数などが挙げられています。
いろいろありがとうございます。
少しプロセス数を絞ってみるなどの実験は必要そうですね。
もうちょっと設定まわり見直してみたいと思います。
postfixボトルネックの分析
http://www.kobitosan.net/postfix/trans-2.1/jhtml/QSHAPE_README.h...
たとえば、届かないメールがあると、キューにたまって何回も配送を試みるので、負荷がかかりやすくなる、これをなんとかするなどの話です。
ありがとうございます。
エラーメールは当然クリーニングしているので、届かないメールは最小限に抑えられています。
アプリケーションと同じサーバに入っているMTAに mail関数 で配送を依頼するのと、SMTPで接続して HELO...QUIT するのとでは差はない
技術的な差は当然あります。
mail 関数では sendmail 互換インターフェイスを使って(大抵 /usr/sbin/sendmail )送信するのに比べ、SMTP をしゃべる場合は当然 smtp デーモンと通信する事になります。
ただ、同一サーバー上にあるのであればその差はあまり大きくはありません。
現時点ではディスクに負荷がかかっているとの事なのでまずはディスクの増設をオススメします。
以下は qmail の例ですが、ログの書き込み負荷を抑えることで高速化を実現しています。
http://www.drk7.jp/MT/archives/001098.html
Postfix が原因となっているのであれば
/var/spool/postfix
以下とログの書き込みディレクトリを別ディスクにするだけでも効果はあると思われます。
また一般的な携帯あてのメール配信のコツですが、キャリア側では同一IPアドレスからのコネクションを絞っているような節があるので固定IPアドレスを複数用意しておき、それぞれのIPアドレスからのコネクション数は少なめに制限して並列に送る形を良く見ました。
この意味からは外部のメールサーバーに投げられるようにプログラムを変更しておけば対応が容易になる事が考えられます。
ただし、自分のやっていたのは半年以上前なので現状では変わっているかもしれません。
ありがとうございます。
同一サーバ上MTAでの負荷について確認できてよかったです。もちろん技術的な差はありますね^^;
ディスクの増設は確かに。。DBも動いていることを考えると、RAID5や10の検討もいいですね。
URLにある、tmpfs 化はやってみる価値ありそうだと思いました。この場合、ログについて設定しているようですが、/var/spool/postfix でも面白いかもしれません。
モバイルメール配信新でIPを複数用意する方法は知っていますが、「ひとつのIP」でもそれなりの通数をはくことができるというのが気になっています。
キャリアの機嫌をうかがって通数を調整しているようなのですが、方法は見当もつきません。。
http://k-tai.impress.co.jp/cda/article/news_toppage/8366.html
少し気になったのですが、ドコモの特定接続サービスは利用されていますか?
10万会員というのが総ユーザー数であれば、これを2~4セッションほど契約するだけで相当の効果がありますよ。
ただ、送信するメールの From 部分が限定されると言う欠点はありますが。
利用したことはないです。
キャリア別メールサーバを別に用意する、とアプリケーションから見ればそういう感じですね。
お墨付きを貰えるなら、ランニングコスト的にも安いかもしれません。
これを各キャリア導入して、複数の MAIL~DATA を送りつける、とかが解決法の1つでしょうか。
とても参考になります。
これを各キャリア導入して
この類のサービスが存在するのはドコモとソフトバンクのみです。
ドコモは存在しないメールアドレスが多いと(SPAM とみなされる)契約を一方的に解除されるという欠点はありますが効果は絶大です。
ソフトバンク版は利用した事はありませんが、あまり変わらないという噂は聞いた事があります。
AU/TUKA はそもそも全てのメールを受け取ってから処理を行っているようなので、サービス自体存在しませんし必要もないようです。
複数の MAIL~DATA を送りつける
Postfix であれば、transport テーブルの設定だけで対応できます。
なるほど、知らなかったです!
すみません、書き漏れましたができれば現状の配信数をさらに増やしたい、つまり、より高速・大量を目指すこともしたいです。なので、稼働率を下げるのはちょっと違います。