test

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

メッセージストアのパフォーマンスの考慮事項

メッセージストアのパフォーマンスは、次のようなさまざまな要素に影響を受けます。

  1. ディスク入出力

  2. インバウンドメッセージレート (メッセージ挿入レートとも呼ばれる)

  3. メッセージサイズ

  4. ログインレート (POP/IMAP/HTTP)

  5. IMAP および HTTP のトランザクションレート

  6. さまざまなプロトコルの並行接続数

  7. ネットワーク入出力

  8. SSL の使用

前の要素リストは、メッセージストアに影響を与えるおおよその順序で記載されています。メッセージストレージに関するパフォーマンス問題のほとんどは、ディスクの入出力能力が不十分なことに原因があります。さらに、物理ディスク上のストアのレイアウトもパフォーマンスに影響を与えます。より小規模のスタンドアロンシステムでは、単純なディスクのストライピングでも十分な入出力が得られます。ほとんどの大規模システムでは、ファイルシステムを分離し、ストアのさまざまな部分に入出力を提供します。

メッセージングサーバーのディレクトリ

Messaging Server は 6 つのディレクトリを使用して大量の入出力活動に対応しています。これらのディレクトリは高頻度でアクセスされるため、ディレクトリごとにディスクを用意するか、より理想的には、ディレクトリごとに RAID を用意します。次の表で、これらのディレクトリについて説明します。

表 11–1 アクセス頻度の高い Messaging Server ディレクトリ

高入出力ディレクトリ 

説明とパラメータの定義 

MTA キューディレクトリ 

このディレクトリでは、MTA チャネルを通る各メッセージについて 1 つずつのファイルが、大量に作成されます。ファイルが次の目的地に送信されると、そのファイルは削除されます。ディレクトリの場所は、imta_tailor ファイルの IMTA_QUEUE オプションにより制御されます。MTA キューディレクトリを変更する前に、 『Sun Java System Messaging Server 6 2005Q4 Administration Reference』にあるこのオプションについての説明を参照してください。

デフォルトの場所: /var/opt/SUNWmsgrsr/queue

Messaging Server ログディレクトリ 

このディレクトリには、新しいログ情報が常に追加されるログファイルがあります。変更の回数は、ログレベルの設定によります。ディレクトリの場所は、configutil のパラメータ logfile.*.logdir によって制御されます。ここで「*」は、admin、default、http、imap、pop など、ログを生成するコンポーネントを示します。MTA ログファイルは imta_tailor ファイルの IMTA_LOG オプションを使用して変更できます。

デフォルトの場所: /var/opt/SUNWmsgsr/log

メールボックスデータベースファイル

これらのファイルはキャッシュの同期と継続的な更新を必要とします。このディレクトリは最も高速なディスクボリュームに配置します。これらのファイルは常に /var/opt/SUNWmsgsr/store/mboxlist ディレクトリに格納されます。

メッセージストアインデックスファイル 

これらのファイルにはメールボックス、メッセージ、ユーザーに関するメタ情報が含まれます。デフォルトではこれらのファイルはメッセージファイルと共に格納されます。configutil パラメータの store.partition.*.path はディレクトリの場所を制御します。ここで「*」はパーティション名です。リソースに余裕がある場合は、これらのファイルを 2 番目に高速なディスクボリュームに配置します。

デフォルトの場所: /var/opt/SUNWmsgsr/store/partition/primary

メッセージファイル 

これらのファイルにはメッセージが含まれており、メッセージごとに 1 つのファイルとなっています。ファイルは頻繁に作成され、変更されることはなく、最終的には削除されます。デフォルトでは、これらのファイルはメッセージストアインデックスファイルと同じディレクトリに格納されます。ディレクトリの場所は、configutil のパラメータ store.partition. partition_name.messagepath で制御されます。ここで partition_name はパーティション名です。

サイトによっては、store.partition.primary.path によって指定される、primary と呼ばれる単独のメッセージストアパーティションがあります。大規模なサイトの中には、store.partition. partition_name.messagepath により指定される追加パーティションを持つものもあります。ここで partition_name はパーティション名です。

デフォルトの場所: /var/opt/SUNWmsgsr/store/partition/primary

メールボックスリストデータベース一時ディレクトリ 

すべての一時ファイル格納用としてメッセージストアによって使用されるディレクトリ。パフォーマンスを最大化するには、このディレクトリを最も高速なファイルシステムに配置する必要があります。Solaris の場合は、configutil コマンドを使用して tmpfs の下のディレクトリ (たとえば、 /tmp/mboxlist) に store.dbtmpdir 変数を設定します。

デフォルトの場所: /var/opt/SUNWmsgsr/store/mboxlist

次の節では、Messaging Server の高頻度アクセスディレクトリについてさらに詳しく説明します。

MTA キューディレクトリ

LMTP 以外の環境では、メッセージストアシステム内の MTA キューディレクトリもかなりの頻度で使用されます。LMTP は、インバウンドメッセージが MTA キューに置かれず、ストアに直接挿入されるように機能します。このメッセージの挿入により、メッセージストアマシンの全体的な入出力要件が少なくなり、メッセージストアマシンの MTA キューディレクトリの使用頻度が大きく減少します。システムがスタンドアロンの場合、または Web メール 送信のためのローカル MTA を使用する場合は、アウトバウンドメールトラフィックのためのこのディレクトリに、まだかなりの入出力が発生します。LMTP を使用した 2 層環境では、このディレクトリが使用されることがあったとしても、ごくまれです。Messaging Server の前のバージョンでは、大規模なシステムではこのディレクトリをそれ自身のストライプまたはボリューム上に設定する必要がありました。

MTA キューディレクトリは通常、専用のファイルシステム上に配置し、メッセージストア内のメッセージファイルから分離すべきです。メッセージストアには、ディスク容量がある定義済みのしきい値を下回った場合にメッセージの配信と追加を停止するメカニズムが備わっています。しかしながら、ログディレクトリとキューディレクトリがどちらも同一ファイルシステム上に存在しており、かつそれらのサイズが増大し続けた場合、ディスク容量不足によりメッセージストアの動作が停止する可能性があります。

ログファイルディレクトリ

ログファイルディレクトリでは、設定されているログのレベルにより、さまざまな量の入出力が要求されます。メッセージストアのその他の高入出力要求とは異なり、ログディレクトリへの入出力は非同期です。典型的な配備シナリオでは、LUN 全体をログ専用には使用しません。かなり規模の大きなストア配備、または大量のログが必要な環境では、専用の LUN を使用するのが理に適っています。

ほとんどすべての環境で、メッセージストアをデータ喪失から守る必要があります。要求される損失からの保護と継続的な可用性のレベルは、RAID5 のような単純なディスク保護から、ミラーリング、日常的なバックアップ、データのリアルタイムレプリケーション、リモートデータセンターまで、さまざまです。データの保護に関しても、Automatic System Recovery (ASR) が可能なマシンから、ローカル HA 機能、自動リモートサイトフェイルオーバーまで、さまざまなものがあります。これらの決定は、ハードウェアの量とサービスの提供に必要なサポート要員の数に影響します。

mboxlist ディレクトリ

mboxlist ディレクトリには入出力が非常に集中しますが、特にサイズが大きいというわけではありません。mboxlist ディレクトリには、ストアとトランザクションログで使用されるデータベースがあります。高頻度の入出力があり、データベースを構成する複数のファイルを複数のファイルシステム間で分割できないことから、大規模な配備では mboxlist ディレクトリをそれ自身のストライプかボリューム上に配置する必要があります。これは、メッセージストアの多くの操作がデータベースにアクセスするため、垂直的スケーラビリティーの喪失の原因にもつながります。アクセスが激しいシステムでは、これがボトルネックになります。mboxlist ディレクトリの入出力パフォーマンスのボトルネックによって、ストアの raw パフォーマンスと応答時間が悪くなるだけでなく、垂直的スケーラビリティーも減少します。バックアップから高速に復旧することが要求されるシステムでは、このディレクトリを Solid State Disks (SSD) 上に配置するか、パフォーマンスの高いキャッシングアレイを使って、ファイルシステム上でサービスを継続したまま復元処理を進行できるような高い書き込みレートを許可します。

複数のストアパーティション

メッセージストアは、複数のストアパーティションをサポートしています。各パーティションを、それ自身のストライプまたはボリューム上に配置します。ストア上に配置するパーティションの数は、さまざまな要素により決定されます。明確な要素としては、サーバーのピーク負荷時の入出力要件があります。追加のストアパーティションとしてファイルシステムを追加することで、メールの配信や取得のためにサーバーで可能な IOPS (1 秒あたりの総入出力) を引き上げます。ほとんどの環境で、大きくて数が少ないストライプあるいは LUN よりも、多数の小さなストライプあるいは LUN のほうが、より大きな IOPS が得られます。

いくつかのディスクアレイを使用すると、アレイを 2 つの異なる方法で設定できます。それぞれのアレイを LUN として設定し、それをファイルシステムにマウントします。または、それぞれのアレイを LUN として設定し、それをサーバー上でストライプします。どちらも有効な設定です。ただし、複数のストアパーティション (小さいアレイでは 1 つのパーティション、または LUN のストライプセットをサーバーボリュームにした大きなアレイ上の多数のパーティション) は最適化と管理が容易です。

ただし、通常は raw パフォーマンスは、ストアパーティションの数を決定する場合の優先事項とはなりません。企業環境では、IOPS よりも容量のほうが重要となる場合が多いでしょう。また、LUN をソフトウェアストライプで設定し、1 つの大きなストアパーティションとすることも可能です。ただし、複数の小さなパーティションのほうが、一般に管理は容易です。ストアパーティションの数を決定する際に適切な最優先事項は、一般的には回復時間です。

ストアパーティションの回復時間は、いくつかのカテゴリに分類されます。

ストレージアレイで使用されるドライブのサイズは、容量要件に対する IOPS 要件という問題になります。ほとんどの家庭用 ISP POP 環境では、「より小さなドライブ」を使用します。大規模な割り当てによる企業配備では、「より大きな」ドライブを使用します。繰り返しになりますが、すべての配備は異なっており、一連の要件を個別に検討する必要があります。

メッセージストアのプロセッサスケーラビリティー

マルチプロセスとマルチスレッドにより、メッセージストアは良好なスケール化がなされています。実際には、メッセージストアは 1 つのプロセッサから 4 つのプロセッサまで、一次直線形の比率を上回るスケール化が行われています。これは、4 つのプロセッサシステムは、1 つのプロセッサシステムを 4 つ合わせたものよりも大きな負荷を処理できることを意味します。メッセージストアは 4 から 12 のプロセッサ数についてもかなり直線形でスケール化されます。12 から 16 のプロセッサ数では、能力は増強されますが、直線形ではなくなります。LMTP を使用すると、同じサイズのストアシステムでサポートされるユーザー数は大きく増加しますが、メッセージストアの垂直的スケーラビリティーはより制限されます。

メールボックスデータベースキャッシュサイズの設定

Messaging Server は、メールボックスデータベースの呼び出しを頻繁に行います。 そのため、そのデータができるだけ迅速に返されることが重要です。メールボックスデータベースの部分をキャッシュ化すると、メッセージストアのパフォーマンスが改善されます。最適なキャッシュサイズを設定することで、メッセージストア全体のパフォーマンスを大きく向上させることができます。キャッシュのサイズは、configutil のパラメータ store.dbcachesize を使用して設定します。

メールボックスデータベースの場所を /tmp、つまり /tmp/mboxlist に定義し直すには、configutil のパラメータ store.dbtmpdir の使用をお勧めします。

メールボックスデータベースは、データページに格納されます。さまざまなデーモンにより stored、imapd、 popd などのデータベースが呼び出されると、指定されたページがキャッシュに格納されているかどうかが、システムによりチェックされます。ページがキャッシュ内に存在する場合は、それがデーモンに渡されます。存在しない場合は、システムは 1 ページをキャッシュからディスクに書き戻し、指定されたページを読み込んでそれをキャッシュに書き込む必要があります。ディスクの書き込みと読み取り回数を減らすことはパフォーマンスの向上につながりますが、それだけに、キャッシュサイズを最適に設定することが重要となります。

キャッシュサイズが小さすぎる場合は、指定されたデータをディスクから必要以上の頻度で読み込む必要があります。キャッシュサイズが大きすぎる場合は、ダイナミックメモリー (RAM) が浪費され、ディスクとキャッシュの同期に余計な時間がかかります。これら 2 つの状況の中では、キャッシュが大きすぎる場合よりも小さすぎる場合の方が、より大きなパフォーマンスの低下を招きます。

キャッシュ効率は、「ヒットレート」により測定されます。ヒットレートは、データベースがキャッシュにより処理される回数の割合のことです。最適化されたサイズのキャッシュでは、ヒットレートは 99 パーセントに達します。すなわち、要求されたデータベースページの 99 パーセントが、ディスクから取得されることなくデーモンに返されます。要求されたデータの 95 パーセント以上を返せるページ数をキャッシュが保持することを目標にしてキャッシュを設定します。キャッシュから返されるページが 95 パーセント未満の場合は、キャッシュサイズを大きくする必要があります。

キャッシュのヒットレートは、データベースコマンド db_stat を使用して測定できます。次の例では、configutil のパラメータ store.dbtmpdir を使用して、メールボックスデータベースの場所を /tmp、つまり /tmp/mboxlist に定義し直しています。db_stat コマンドは、次の場所に対して実行されます。

# /opt/SUNWmsgsr/lib/db_stat -m -h /tmp/mboxlist 


2MB 513KB 604B  Total cache size.
1                   Number of caches.
2MB 520KB           Pool individual cache size.
0                   Requested pages mapped into the process’ address space.
55339               Requested pages found in the cache (99%).

この例では、ヒットレートは 99 パーセントです。これは、キャッシュサイズが最適であるか、大きすぎることを示します。これをテストするには、ヒットレートが 99 パーセント以下になるまでキャッシュサイズを小さくしていきます。ヒットレートが 98 パーセントになったら、データベースキャッシュサイズが最適化されたことを意味します。逆に、db_stat が 95 パーセント未満のヒットレートを示した場合は、store.dbcachesize パラメータを使用してキャッシュサイズを大きくします。最大サイズは、store/mboxlist ディレクトリ内のすべての *.db ファイルを合計したものになります。キャッシュサイズは、store/mboxlist ディレクトリに格納されるすべての .db ファイルの合計サイズを超えてはいけません。

注 –

ユーザーベースが変化すると、ヒットレートも変化します。このパラメータを定期的にチェックして、必要に応じて調整します。このパラメータの上限はデータベースの制約による 2G バイトです。

ディスクストライプ幅の設定

ディスクストライピングを設定するときには、システムを通過するメッセージの平均サイズにストライプ幅を合わせます。128 ブロックのストライプ幅は、通常の使用には大きすぎて、パフォーマンスに悪影響を与えます。代わりに、8、16、32 ブロック (それぞれ 4、8、16K バイトのメッセージサイズの場合) の値を使用します。