test

Sun Java System Communications Services 6 2005Q4 配備計画ガイド

Messaging Server システムパフォーマンスの評価

負荷シミュレータを使用してハードウェアとユーザーベースの評価を行ったら、システムパフォーマンスを測定する必要があります。次のトピックで、システムの全体的なパフォーマンスを向上させる方法について説明します。

Messaging Server のメモリー使用率

配備で使用するそれぞれのマシンに、適切な量の物理メモリーが搭載されていることを確認してください。物理メモリーを追加するとパフォーマンスが向上し、ピークボリューム時でもサーバーが適切に動作するようになります。メモリーが不足していると、Messaging Server で過剰なスワッピングが発生し、効率的に動作しません。

少なくとも、1 つの CPU あたり 1G バイトのメモリーを用意してください。ほとんどの配備で、UltraSPARC® III システムの CPU 1 つにつき 2G バイトのメモリーが必要になります。

Messaging Server のディスクスループット

ディスクのスループットとは、システムでメモリからディスクに、またはディスクからメモリに転送されるデータ量のことです。このデータ転送レートは、Messaging Server のパフォーマンスに重大な影響を及ぼします。システムのディスクスループットを向上させるには、次のことを考慮します。

ディスク I/O を、帯域幅ではなく IOPS (1 秒あたりの I/O の合計) で測定することをお勧めします。システムがきわめて短い応答時間 (10 ミリ秒未満) で処理できる、個別のディスクトランザクションの数を測定する必要があります。

Messaging Server のディスク容量

サーバーシステムのディスク容量を計画する際には、環境ソフトウェア、Messaging Server ソフトウェア、およびメッセージの内容を運用するための容量、さらにトラッキングのための容量を確実に含める必要があります。可用性が要求される場合には、必ず外部ディスクアレイを使用します。ほとんどのシステムで、内部システムディスクでは 4 台までのディスクしかサポートされないため、パフォーマンスを向上させるには外部ディスクが必要となります。

メッセージストアパーティションでは、全メッセージの合計サイズに 30 % のオーバーヘッドを加えたストレージサイズが必要です。

さらに、ユーザーディスク容量を割り当てます。この容量は、通常、サイトのポリシーに従って決定されます。

注 –

配備計画には、障害回復のためのメッセージストアのバックアップ方法を含める必要があります。Messaging Server では、Solstice Backup (Legato Networker)、imsbackup ユーティリティ、およびファイルシステムスナップショットバックアップがサポートされています。バックアップメディアを遠隔地に格納した方がよい場合もあります。バックアップは、サーバーの処理に影響しない範囲で、できるだけ頻繁に実行することをお勧めします。

MTA メッセージキューのディスクサイズ決定

Messaging Server の MTA キューの動作は、配信されるのを待機しているメッセージ用の一時記憶域を提供することです。保証されたサービス提供を維持するために、メッセージは持続的方式でディスクに書き込まれます。メッセージを配信できない場合、MTA は最終的に断念してメッセージを送信者に戻すまで再試行します。

メッセージキューのパフォーマンス

MTA キューのディスクサイズ決定は、MTA のパフォーマンスを改善するための重要なステップです。MTA のパフォーマンスは、ほかのどのシステムリソースにもましてディスク I/O に直接影響されます。したがって、複数のディスクスピンドルで構成されるディスクボリュームを計画することをお勧めします。これらのディスクスピンドルは、ディスク RAID システムを使用して連結およびストライプ化されます。

MTA のパフォーマンスに問題があると、エンドユーザーはすぐにその影響を受けます。ユーザーが電子メールクライアントの「送信」ボタンを押すとき、MTA はメッセージがメッセージキューにコミットされるまで、メッセージの受信を完全には受理しません。したがって、メッセージキューのパフォーマンス改善は、エンドユーザーの立場から見ると応答時間の短縮につながります。

メッセージキューの可用性

SMTP サービスは、保証されたメッセージ配信サービスであると考えられます。これは、サービスが配信しようとしているメッセージを途中で失わないことを、メッセージングサーバーがエンドユーザーに対して保証するという意味です。MTA キューシステムを設計するときは、メッセージが失われないことを保証するためにあらゆる努力を払う必要があります。この保証は通常、さまざまな RAID 技術を使用して、冗長化されたディスクシステムを実装することによって達成されます。

メッセージキューの利用可能なディスクサイズの決定

次のいずれかの条件が発生した場合、キューのサイズは非常に大きくなります。

次節以降で、これらの問題について説明します。

ネットワーク接続の問題に備えた計画

ネットワーク接続の問題により、MTA がメッセージを配信できない場合があります。そのような場合、定義された再試行間隔に従って MTA が配信を再開できるようになるまで、メッセージはキューに格納されます。

そのような中断に備えたディスク領域の計画は、「メッセージキューのサイズ決定の一般則」という単純なルールに基づいて行います。

  1. 配信が予測される 1 分あたりの平均メッセージ数を決定します (N)。

  2. メッセージの平均サイズ (K バイト) を決定します (S)。

  3. 典型的なネットワーク接続障害の最大持続時間 (分) を決定します (T)。

ディスクキューサイズを見積もるための式は次のようになります。

ディスクキューサイズ (K バイト) = N x S x T

MTA の配信再試行設定の調整

システムがメッセージをまったく配信できなくなることがあります。この状態では、MTA は配信を再試行するまでの一定期間 (再試行間隔として定義された期間)、メッセージをメッセージキューに保留します。この状態は、MTA が配信を断念してメッセージを送信者に戻すまで続きます。メッセージが配信できなくなる理由の多くは予測不可能です。メッセージが配信できない理由には、ネットワーク接続の問題、送信先サーバーのビジー状態、ネットワークの混雑などさまざまなものがあります。

ビジー状態のサーバー上では、高ボリュームアクティビティの期間中、このような一時的に格納されるメッセージが大量に蓄積される可能性があります。大量の蓄積によって、ディスク容量の問題が発生する可能性があります。そのような蓄積を防ぐには、より短い間隔で配信を再試行するように MTA を調整します。

再試行間隔は、imta.cnf ファイルの「Channel Block」設定で設定します。このファイルの構造としては、書き換えルールとチャネルブロックの 2 つの部分から構成されています。チャネルブロックは、特定のディスクキューと、それに関連するプロセスの動作を定義します。ここでの説明に関係するのは tcp_local チャネルです。tcp_local チャネルは、企業のローカルネットワークの外部のサイト、すなわち、インターネットを経由した場所への配信を提供します。

tcp_local チャネルの再試行間隔は当初、デフォルトチャネルブロックによって設定されます。デフォルトチャネルブロックを使用すると、設定を複製することによって設定の繰り返しを防ぐことができます。

デフォルトチャネルブロックの例を次に示します。


defaults notices 1 2 4 7 copywarnpost copysendpost postheadonly
noswitchchannel immnonurgent maxjobs 7 defaulthost
red.siroe.com red.siroe.com

チャネルブロックの構造の先頭はチャネル名です。前述の例において、これは、これらの設定を持たないチャネルに適用されるデフォルトチャネルブロックです。2 番目の部分はチャネルキーワードのリストです。

notices キーワードは、メッセージ配信通知 (MDN) が送信者に返送されるまでに経過可能な時間を指定します。このキーワードは notices キーワードで始まり、それに続けて、再試行期間を設定する一連の数値を指定します。デフォルトでは、MTA は配信を再試行し、送信者に通知を返送します。これらの通知は「ポストマスター」からエンドユーザーの受信箱に送られます。

この例では、MTA は 1 日、2 日、および 4 日を経過するタイミングで配信を再試行します。7 日経過すると、MTA はメッセージを送信者に戻し、そのメッセージを配信失敗とみなします。

多くの場合、MTA のデフォルト設定で適切なパフォーマンスが得られます。場合によっては、メッセージキュー用のディスク領域不足などのリソース枯渇の可能性を回避するため、MTA を調整する必要があります。これは製品の制限ではなく、ハードウェアおよびネットワークリソースを含めた Messaging Server システム全体の制限です。

ディスクサイズに関して起こりうるこれらの問題を考慮すると、ユーザー数の多い配備では、あまり短い間隔でメッセージ配信を試みるのは好ましくない場合があります。そのような状況に該当する場合は、次に示すドキュメントを参考にしてください。

参考資料

詳細については、次のマニュアルを参照してください。

Messaging Server のネットワークスループット

ネットワークスループットは、一定時間内にクライアントアプリケーションとサーバー間のネットワークで転送可能なデータ量のことです。ネットワークに接続されたサーバーがクライアントからの要求に応答できない場合、通常クライアントは要求の再送信を何度も行います。再送信のたびに、システムにはオーバーヘッドと余分なネットワークトラフィックが生じます。

データの完全性とシステムのパフォーマンスを向上させて、ネットワークの混雑を解消することで、再送信の数を減らすことができます。

Messaging Server の CPU リソース

メッセージストア、MTA、および複合サービス (MMP および Messenger Express マルチプレクサ) だけを実行しているシステムに対して、十分な CPU を用意します。さらに、使用を計画している RAID システムにも十分な CPU を用意します。