負荷シミュレータを使用してハードウェアとユーザーベースの評価を行ったら、システムパフォーマンスを測定する必要があります。次のトピックで、システムの全体的なパフォーマンスを向上させる方法について説明します。
配備で使用するそれぞれのマシンに、適切な量の物理メモリーが搭載されていることを確認してください。物理メモリーを追加するとパフォーマンスが向上し、ピークボリューム時でもサーバーが適切に動作するようになります。メモリーが不足していると、Messaging Server で過剰なスワッピングが発生し、効率的に動作しません。
少なくとも、1 つの CPU あたり 1G バイトのメモリーを用意してください。ほとんどの配備で、UltraSPARC® III システムの CPU 1 つにつき 2G バイトのメモリーが必要になります。
ディスクのスループットとは、システムでメモリからディスクに、またはディスクからメモリに転送されるデータ量のことです。このデータ転送レートは、Messaging Server のパフォーマンスに重大な影響を及ぼします。システムのディスクスループットを向上させるには、次のことを考慮します。
保守作業を検討し、バックアップのための十分な帯域幅があることを確認します。特にリモートバックアップの場合は、ネットワーク帯域幅にも影響を与えます。私設バックアップネットワークは、より効率的な代替バックアップ手段となります。
ストアのパーティションと、tmp や db のようなストアデータ項目の分割を慎重に行なって、スループットを向上させます。
大規模な配備では、ユーザーベースが必ず RAID (Redundant Array of Independent Disks) 環境全体に分散されるようにします。
ディスクからデータを取得する操作のスピードを向上させるために、データを複数のディスクでストライピングします。
RAID がハードウェア上に存在しない場合は、RAID のサポートに十分な CPU リソースを割り当てます。
ディスク I/O を、帯域幅ではなく IOPS (1 秒あたりの I/O の合計) で測定することをお勧めします。システムがきわめて短い応答時間 (10 ミリ秒未満) で処理できる、個別のディスクトランザクションの数を測定する必要があります。
サーバーシステムのディスク容量を計画する際には、環境ソフトウェア、Messaging Server ソフトウェア、およびメッセージの内容を運用するための容量、さらにトラッキングのための容量を確実に含める必要があります。可用性が要求される場合には、必ず外部ディスクアレイを使用します。ほとんどのシステムで、内部システムディスクでは 4 台までのディスクしかサポートされないため、パフォーマンスを向上させるには外部ディスクが必要となります。
メッセージストアパーティションでは、全メッセージの合計サイズに 30 % のオーバーヘッドを加えたストレージサイズが必要です。
さらに、ユーザーディスク容量を割り当てます。この容量は、通常、サイトのポリシーに従って決定されます。
配備計画には、障害回復のためのメッセージストアのバックアップ方法を含める必要があります。Messaging Server では、Solstice Backup (Legato Networker)、imsbackup ユーティリティ、およびファイルシステムスナップショットバックアップがサポートされています。バックアップメディアを遠隔地に格納した方がよい場合もあります。バックアップは、サーバーの処理に影響しない範囲で、できるだけ頻繁に実行することをお勧めします。
Messaging Server の MTA キューの動作は、配信されるのを待機しているメッセージ用の一時記憶域を提供することです。保証されたサービス提供を維持するために、メッセージは持続的方式でディスクに書き込まれます。メッセージを配信できない場合、MTA は最終的に断念してメッセージを送信者に戻すまで再試行します。
MTA キューのディスクサイズ決定は、MTA のパフォーマンスを改善するための重要なステップです。MTA のパフォーマンスは、ほかのどのシステムリソースにもましてディスク I/O に直接影響されます。したがって、複数のディスクスピンドルで構成されるディスクボリュームを計画することをお勧めします。これらのディスクスピンドルは、ディスク RAID システムを使用して連結およびストライプ化されます。
MTA のパフォーマンスに問題があると、エンドユーザーはすぐにその影響を受けます。ユーザーが電子メールクライアントの「送信」ボタンを押すとき、MTA はメッセージがメッセージキューにコミットされるまで、メッセージの受信を完全には受理しません。したがって、メッセージキューのパフォーマンス改善は、エンドユーザーの立場から見ると応答時間の短縮につながります。
SMTP サービスは、保証されたメッセージ配信サービスであると考えられます。これは、サービスが配信しようとしているメッセージを途中で失わないことを、メッセージングサーバーがエンドユーザーに対して保証するという意味です。MTA キューシステムを設計するときは、メッセージが失われないことを保証するためにあらゆる努力を払う必要があります。この保証は通常、さまざまな RAID 技術を使用して、冗長化されたディスクシステムを実装することによって達成されます。
次のいずれかの条件が発生した場合、キューのサイズは非常に大きくなります。
サイトにおいてネットワーク接続に重大な問題がある
MTA の設定で、メッセージの保持期間が長すぎる
メッセージに関して、このマニュアルで扱っていない何らかの問題がある
次節以降で、これらの問題について説明します。
ネットワーク接続の問題により、MTA がメッセージを配信できない場合があります。そのような場合、定義された再試行間隔に従って MTA が配信を再開できるようになるまで、メッセージはキューに格納されます。
そのような中断に備えたディスク領域の計画は、「メッセージキューのサイズ決定の一般則」という単純なルールに基づいて行います。
配信が予測される 1 分あたりの平均メッセージ数を決定します (N)。
メッセージの平均サイズ (K バイト) を決定します (S)。
典型的なネットワーク接続障害の最大持続時間 (分) を決定します (T)。
ディスクキューサイズを見積もるための式は次のようになります。
ディスクキューサイズ (K バイト) = N x S x T
システムがメッセージをまったく配信できなくなることがあります。この状態では、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 システム全体の制限です。
ディスクサイズに関して起こりうるこれらの問題を考慮すると、ユーザー数の多い配備では、あまり短い間隔でメッセージ配信を試みるのは好ましくない場合があります。そのような状況に該当する場合は、次に示すドキュメントを参考にしてください。
詳細については、次のマニュアルを参照してください。
『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の「通知メッセージの配信間隔を設定するには」
『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 12 章「チャネル定義を設定する」
ネットワークスループットは、一定時間内にクライアントアプリケーションとサーバー間のネットワークで転送可能なデータ量のことです。ネットワークに接続されたサーバーがクライアントからの要求に応答できない場合、通常クライアントは要求の再送信を何度も行います。再送信のたびに、システムにはオーバーヘッドと余分なネットワークトラフィックが生じます。
データの完全性とシステムのパフォーマンスを向上させて、ネットワークの混雑を解消することで、再送信の数を減らすことができます。
ボトルネックを解消するには、ネットワークインフラストラクチャーが負荷を処理する能力を確保します。
ネットワークを分割します。たとえば、クライアントアクセスに 100Mbps のイーサネットを、バックボーンに 1G バイトイーサネットを使用します。
将来の拡張に備えて十分な容量を確保するには、ネットワークを構築するときに理論最大値を使用してはなりません。
トラフィックのフローを異なるネットワークパーティションに分割して衝突を減らし、帯域幅の使用を最適化します。
メッセージストア、MTA、および複合サービス (MMP および Messenger Express マルチプレクサ) だけを実行しているシステムに対して、十分な CPU を用意します。さらに、使用を計画している RAID システムにも十分な CPU を用意します。