私は現在、ファイル ストアとデータベースを利用したメッセージ ストアを組み合わせて使用する複数のメッセージング エンジンを使用していた環境で作業しています。この設計は、もともと IBM のコンサルタントによって行われました。しかし、ファイル ストアを使用して構成されたメッセージング エンジンは多くの問題を引き起こし、ミッション クリティカルな運用環境での使用に必要な信頼性が不足しているという結論に達しました。最終的に、すべてのファイル ストアを排除し (ビジネス クリティカルではないいくつかのユース ケースを除く)、データベースを利用したメッセージ ストアに変更しました。
次の IBM レベル 3 サポートの声明 (予期せず満杯と報告されたファイル ストアに関する PMR への対応) は、発生している問題を明らかにする可能性があります。
観察された問題は、最適化プロセスがなく、制限のみがあるファイルストアの断片化に関連していると思われます。説明されているテストでのメッセージングのパターンは、
PM10591 にもかかわらず、ファイルストアがいっぱいになり、回復しない可能性があるパターンとまったく同じです。
基本的に、この問題は、ログ ファイルの全体のサイズがストア ファイル内に連続して収まる必要があるという要件によるものです。通常の状況では、この連続した空き領域 (使用されることはありませんが、存在する必要があります) はストア ファイルの末尾にあります。たとえば、次のようになります。
0...メッセージデータ...400Mb....空き連続容量...500Mb
ストア ファイルがいっぱいになると、ログ ファイルを格納するのに十分な連続した空き領域がストア ファイルにないことを意味します。0 から 400Mb までのファイルをメッセージ データで満たしてから、0 から 200Mb までのメッセージ データを消費したとします (MDB 入力キューは排出されますが、システム例外の宛先は満杯のままです)。ストア ファイルは基本的にファイル システム自体であり、ノードおよびディレクトリのメタ データはファイル内のさまざまな場所に格納されるため、メッセージ データを消費したという理由だけで、0 ～ 200Mb のストア領域は連続した空き領域ではありません。むしろランダムな間隔で少量のメタデータがあります。したがって、合計で 300Mb の空き領域がありますが、ログが移動できる連続した 100Mb の断片は 1 つもありません。これは、現在最適化ソリューションがない問題です。
通常、すべてのキューからメッセージ データを消費すると、重要な数バイトが解放され、ストア ファイルの最後に連続した空き領域が再作成されます。つまり、例外宛先でメッセージ データを消費します (これは、最初のキューからメッセージ データを消費していっぱいにするよりも便利です)。
この問題の完全な解決策は、ストアがいっぱいにならないようにすることです。必要な最大サイズを知る唯一の方法は、すべてのキューを構成された制限までメッセージの可能な最大サイズで満たし、必要なストア ファイルのサイズを確認することです。または、無制限のサイズを持つようにファイル ストアを構成することもできます。
v7 では、断片化に抵抗するための変更がありますが、デフラグ ツールはありません。これは、オンラインでのデフラグには非常にコストがかかるためです。この問題の真の解決策は、最悪のシナリオで予想されるすべてのメッセージ データを格納できる十分なスペースを確保することです。
これが実際に意味することは、永続ストアが実際に格納されたメッセージの数とサイズに基づいて予想されるよりもはるかに多くのスペースを必要とする特定の使用パターンがあるということです。明らかに、これにより、ファイル ストアのストレージ要件を計画することは基本的に不可能になります。