Postfix Configuration - Resource Controls
上のレベルへ | 基本
設定 | UCE 制御 | 速度制御 | リソース制御 | アドレス操作
イントロダクション
Postfix システムは有限のメモリ予算内で走るように設計されています。
この文書の終わりまでに、テキストラインフラグメントのようなメモリ内
オブジェクトのサイズや、そのようなオブジェクトの
インスタンスの数、一つのオペレーションにかかる 時間に
関する設定可能な制限があります。さらに、リソースの枯渇を扱う適切な
戦略があります。負荷がかかった状況下でも、問題を悪化させずに
走り続けようという考え方です。
オブジェクトサイズ制限
固定されたメモリリソース予算に対する最初のステップは、
それぞれのメモリ内オブジェクトのサイズを制限することです。
いったんメモリ内オブジェクトのサイズが制限されると、
メモリの総消費量はオブジェクトインスタンスの数を制限することで
制限されます。簡単でしょ?
- line_length_limit (デフォルト: 2048 bytes)
- 分割されずに扱われる1行のテキストの長さ。全ての Postfix の周辺
プログラム (SMTP サーバ や SMTP クライアント, ローカル pickup, local 配送) が信頼できないところから
データを読み込む際に、この1行の長さ制限を強制します。
長い行は配送の際に再構築されます。
- header_size_limit (デフォルト: 102400 bytes)
- 複数行メッセージヘッダで配送されるテキストの量。
$header_size_limit バイトに収まらないヘッダテキストは
削られます。この制限は cleanup
ヘッダ書き換えコードによって強制されます。
- header_address_token_limit (デフォルト: 10240 トークン)
- メッセージヘッダのアドレスを書き換えるのに Postfix が使う、
メモリや CPU の量の制限。これ以上のトークンのテキストは削られます。
この制限は cleanup ヘッダ書き換え
コードによって強制されます。
- extract_recipient_limit (デフォルト: 10240 受信者)
- Postfix があきらめる前にメッセージヘッダから抽出する受信者の数。
これは暴走したプログラムが "sendmail-t" で実行するダメージを
制限します。
以下のパラメータはファイルシステムストレージの利用を制限します:
- message_size_limit (デフォルト: 10240000 bytes)
- エンベロープ情報 (送信者、受信者など) を含めた、Postfix
キューファイルの最大サイズ。
- queue_minfree (デフォルト: no restriction)
- キューファイルシステムに必要な空き容量のバイト数。
十分な空きがないと、SMTP サーバ は
内向けメールの配送要求を断ります (再び十分な空き容量が得られたら
メールを受け取ります)。デフォルトの制限はありません; しかし
一つの大きなメッセージでメールシステムが止まらないようにするために、
最低 $message_size_limit の数倍要求するのはよい考えだと
思われます。
- bounce_size_limit (デフォルト: 50000 bytes)
- 送信者に送り返される、配送できないメッセージの大きさ。
オブジェクトカウント制限
いったんメモリオブジェクトのサイズが制限されると、Postfix の有限
メモリ予算を実装する次のステップはメモリ内オブジェクトインスタンスの
数を制限することです。
- qmgr_message_recipient_limit (デフォルト: 20000)
- キューマネージャ のメモリ内
受信者アドレスデータ構造の数の上限。このパラメータは
他のメモリ内データ構造のインスタンスの数も制御します。
例えば delivery rate control
ドキュメントを参照してください。
- qmgr_message_active_limit (デフォルト: 20000)
- active キューにあるメッセージの数の上限。
Postfix キュー機構の紹介は Postfix の概要
ドキュメントを参照してください。
- duplicate_filter_limit (デフォルト: 1000)
- local 配送エージェントやアドレス cleanup デーモンがメッセージを
配送する際に覚える受信者アドレスの数。受信者のアドレスが
覚えているリストに見つかると無視されます。
時間制限
外部コマンドは完了までの有限の時間を与えられます。このような
コマンドは "|command" 配送先が alias データベースや :include: ファイル、 .forward ファイルの中に見つかった時に、
local 配送エージェントにより
実行されます。pipe メーラは外部コマンドへ
パイプする代わりの方法を実装しています。
- command_time_limit (デフォルト: 1000 秒)
- local 配送エージェントが外部コマンドを
強制終了するまでに待つ時間。
- service_name_time_limit (デフォルト:
$command_time_limit)
- pipe メーラを通して外部コマンドに配送する時の時間制限。
service_name はサービス名 (master.cf ファイルの最初の
フィールド) で置き換えます。
排他的ファイルロックの獲得
内部では、Postfix プログラムは非常に統率された方法で協調し、
排他的ファイルアクセスで戦う必要はほとんどありません。しかし、
例えばユーザがメールボックスにアクセスしている時にメールを配送
する場合など、外部でアクセスの衝突がおこるかもしれません。
Postfix は二つのタイプのファイルロックをサポートしています:
- fcntl() や flock() システム権限で実装された
内部ロック。
- file.lock と名付けられたファイルで実装された
外部ロック。
ホストシステムによっては、Postfix は片方もしくは両方使います。
次の設定パラメータは Postfix のファイルロックの扱い方を制御します:
- deliver_lock_attempts (デフォルト: 5)
- あきらめるまでにファイルをロックしようとする回数。
- deliver_lock_delay (デフォルト: 1 秒)
- ファイルをロックしようとする間の時間。
- stale_lock_time (デフォルト: 500)
- 強制的に外部ロックファイルを削除するまでの時間。
エラー回復
サーバに負荷がかかった状況では、得られるシステムリソースは
Postfix が必要とする量を調達するには不十分かもしれません。
Postfix 設定ファイルが壊れていたり、Postfix プログラムが不完全な
場合に、世界もバラバラに壊れるように見えるかもしれません。
災害に直面した時に取る一般的なアプローチは致命的なランタイム
エラー(もしくはソフトウェアの問題の場合 panic)で終了し、
しばらくしてから再び試す方法です (master
デーモンはいくらかの遅延の後プロセスをリスタートします。
それぞれの失敗した試行はログに記録されます; だれかが問題に気づいて
修正することを期待します。
いくつかの回復のための戦略が Postfix 開発の非常に早い段階で実装され、
まだ設定可能にはなっていません。次に続くものは回復制御パラメータの
大きくなりつつあるリストのはじまりです:
- fork_attempts (デフォルト: 5 回)
- あきらめるまでに新しいプロセスの生成を試みる回数。
- fork_delay (デフォルト: 1 秒)
- 新しいプロセスを生成しようとする間の遅延。
- transport_retry_time (デフォルト: 60 秒)
- キューマネージャが明らかに死んでいる Postfix 配送サービスと
接触しようと試みる時間量。
上のレベルへ | 基本
設定 | UCE 制御 | 速度制御 | リソース制御 | アドレス操作