[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[postfix-jp:01153] Re:
- Subject: [postfix-jp:01153] Re:
- From: ARAKI Yasuhiro <yasu@xxxxxxxxxxxx>
- Date: Sat, 13 Oct 2001 20:10:29 +0900 (JST)
荒木です。
答えを言ってしまえば、回線を使いつくすのはわけないことだと思います。
しかしながら単にリモートへの速度で競争するならsmtpfeedをつかうのをおすすめ
します。
> 早川です。
<snip>
> メールのサイズを1KB・帯域保証された1Mbpsの回線があるとすると
> 単純な計算による限界値は125通/秒になるわけですよね。
> 想定するマシンは、
> ・1GHzクラスのCPU
おそらくCPUは十分です。
> ・256-512MB程度のメモリ
配送数に比例します。
> ・20-80GBのHDD(数十MB/sの書込み速度)
local配送がないならば十分でしょう。
> ・100Mbpsのネットワークカード
> を装備しているとして、ここまでいけるでしょうか。
> 足かせになるとしたら何でしょうか。
> 直観的にはMTAのDNS引き作業がネックかなぁと思うのですが、
> 並列度を上げていくとするとメモリにくるんでしょうか、それとも回線でしょうか。
ひとつめのキューの配送がはじめるまでは主にDNSが回線を消費します。
早川さんのメールを見る限りlocal配送ではないように見えますので
HDDはキューでしか使いませんね。
qmgr_message_active_limitで制限はできますが、
qmgrを使うならほぼ配送バイトの和以上のメモリを消費します。
キューにいれたぶんだけDNSを引いてから配送になるので、その速度が
メモリ滞留時間になります。
配送開始を早くしたいなら、あえて小さくしたり、分割してpostfixに
渡すのが得策です。
> ある程度までメモリを増やすのはたやすいですが、
> 回線環境をよくするとなると明確にコストにはね返ってきますよね。
> 回線環境は現実的に一番制約されやすいとこかなと思いますし、
> 相手のサーバーからの反応具合については改善しにくいでしょうから
> その辺から限界がきそうな気がしますが、どんなもんでしょうか。
リモート配送の場合は相乗りをするので、相手サーバからの反応速度はそれほど問題に
ならないはずです。せいぜいdefault_destination_concurrency_limit以上には
並列に通信はおこなわれません。
一般的なpostfix単体でのチューンなり、危険なチューンをしたいならば、
こちらを御覧ください。御参考まで。
http://www.araki.net/presen/lw-postfix.pdf
-----
荒木靖宏
- Follow-Ups
-
- [postfix-jp:01155] Re: 配信性能に対する環境の影響具合, HAYAKAWA Hiroshi
- References
-
- [postfix-jp:01152], ARAKI Yasuhiro
[検索ページ]
[Postfix-JP ML Home]