Q1001: 私は大きいメールサーバーを実行しています。 私が万一設定するならばsplit_spool_directory 性能を改善するため？
A1001: 列の上に多くのメッセージがある時があるならば、スプールディレクトリを分割することはほとんどの利益を持っています。 すべてのメールが非常に迅速に配達されて、列がたとえば数百のメッセージよりいつも少ないならば、これをするどのような必要もありません。 より大きい列によって、スプールを分割することへの明確な性能利点があります。 それは他に比べていくつかのタイプのファイリング・システムの上でより早く際立ちます。
Eximは、大きい列を処理するためにデザインされませんでした。 たくさんのメッセージが長い間の間列の上に残っている所に、enviromentにいるならば、主要なホストの列が短くあり続けるように、これらのメッ セージを手渡すホストの上に後ろを実施することを考慮してください。 使うことができます。 fallback_hosts これまたは$message_ageを条件としているルータをするため。
Q1002: どれほどよくEximは測量しますか？
A1002: 作者が、特に、高性能MTAを書くことを試みなかったけれども、Eximは、かなり効率的であるようです。 忙しい日(それは20,000より上のユーザーを持っています)に、ケンブリッジ大学(大きいSunボックス)の最も大きいサーバーは1日あたり 100,000回の配達を入念に調べます。 大きいLinuxボックス--177,000回の配達(合計における791MB)であるレコード--上に時々、1日に100,000より上の配達を処理す るメーリングリスト爆発物のリポートがありました。 13,000回の配達まで、1時間は報告されました。
これらは何人かのEximユーザーからの引用文です：
"..." カナダの最も大きいインターネットプロバイダー--私達のメールのすべての上のEximが加工し、私達がそれのために完全に喜んでいる用途。 バックログと高いロード平均によって悩まされた私達のマシンの1台の中にそれはライフを返しました。 ここに、単に、私達の最も大きいメールサーバー(クワタSS1000)がどれくらいEメールを見るかの例があります… 「1日での[230,911配達：」 4,475MB]
"..." Eximは、それ…に行ないgethostbyname()sとRBLルックアップを受信メールサーバーのうちのすべてに抱き、彼はinetdから走りま す（TCP帯封は接続しました）。 それでも、私に、彼が私達のSCO 5.0.4ボックス(1 ペンティアム166)上の稲妻と同じくらい速く走るように思われます。 私(そして多くの顧客)が"前に持っていたMMDFよりずっと速い。
「128MのRAM運転Linux2.2.5を持つPII400上で、私は時間(発信のユニークなメッセージと受領者)あたり36656のメッセージを達 成しました」。 5分期間のまわりでは、私は1秒あたり平均30のメッセージを達成することができました（それは108000m／時間です）！ 私達は使っています： (違いを生じさせるオプション)：
queue_only
split_spool_directory
queue_run_max = 1 remote_max_parallel = 1
私達はcronに、5を産むすべての5分帽子ランを売買させます。exim -q より少しがあるならば、その120eximは現在運転を処理します。 私達は、それの協力を手動でコントロールしてそれを見つけましたexim -q 私達がかなりの性能を得たとスプールのためにremote_smtp配 達のために主張しているプロセス 10000m/時間"。
Q1003: 私達は大きいパスワードファイルを持っています。 Eximは、物を加速するために配達の間に代わりのルックアップを使うことができますか？
A1003: FreeBSDを使っているならば、それが自動的に索引を付与されたパスワードファイルを使うので、この問題は生じるべきでありません。 他のオペレーティングシステムの中で、これが、また起こるように手配することができます。 例えば、Linuxにおいて、あなたたちが、する必要があるすべてはそうです。
#cd /var/db#構成
そして、置いてください。db 前ファイル dbを使いたいどのような/etc/nsswitch.confラインで。
索引を付与されたパスワードファイルへの支持を含まないシステムの上で、自身で1を築き、Eximコンフィギュレーションからそれを参照することができま す。 例えば、ローカルなメールボックスに発送するために、これを使うことができました：
localuser:
driver = accept
条件=${ルックアップ{$local_part}cdb{/など／passwd.cdb}{はい}{無}}輸送=local_delivery
ユーザー=${抜粋{1}{：}{${ルックアップ{$local_part}cdb{/など／passwd.cdb}}}
これはパスワードファイルのcdbバージョンを仮定します。
Q1004: 私はただ、規則的な操作の間にヒントデータベースをRAMディスクに置くことが役立っているかもしれないかどうかと思っていました。 誰かがそんなにもうトライしましたか？
A1004: このように報告されたAユーザー： 「私は、これが大きい下のSolarisを作動させると気付きました」。 RAMディスクにそれの上のdbディレクトリの中ですべてを仕切 り、保持させてください。 しかし、私がLinuxにおける同じ物を試す時に、私は同じ景気づけを見ません。 私は、Linuxのファイルバッファキャッシュがほぼ同じを作動させると思います。 「動くために、プラス、これはプロセスに向けて多くの部屋を出発します」。
Linuxの延期されたバッファが、よりよい全体の性能を提供するのを手紙で知らせる他のリポートが一般にありました。
見たところ、Linuxにおけるのように、遅延した文書のためにSolarisカーネルの中にサポートがあるけれども、サーバーが壊れるならば、そんなに 多く負けるわけではないように、Sunのサーバー方針は、それを使用不可にさせることです。 このサポートを可能にし、使用不可にするためにfastfsと 呼ばれたプログラムがあります。 自身でそれをダウンロードし、コンパイルする必要があります； それを捜してそれを見つけてくださいfastfs.c サーチ・エンジンの中。 Solaris性能は、多く改善されると報告されるけれども、潜在的な危険を理解するために注意するべきです。 特に、fsckは、 衝突の後に自動的にディスクを「固定する」ことができないかもしれません。