Biztalk 2006 アプリケーションには、頻繁に (毎秒約 15 要求) 呼び出される 2 つのオーケストレーションが含まれています。ホストで特定のスロットリングしきい値を変更することにより、アプリケーションで発生する可能性のあるメモリ リークを特定しました。メモリ ベースのスロットリングを無効にすると、プロセス メモリが 1400 MB まで増加し始め、その後、メモリ不足の例外が発生し始めました。
この状況が発生すると、ホスト インスタンスを再起動する必要があります。
このような場合、Orchestration から GC.Collect を明示的に呼び出すことが有益かどうか疑問に思っていました。このアプローチを使用することの短所は何ですか？
ありがとう。
メモリ不足の例外は、ガベージ コレクタが要求された割り当てを実行するのに十分なメモリを解放できなかった場合にのみ発生します。これは、メモリ リークが発生した場合に発生する可能性があります。これは、ガベージ コレクションされたプラットフォームでは、一部のオブジェクト参照が必要以上に長く保持されることを意味します。リークの頻繁な原因は、グローバル データ (静的変数) を保持するオブジェクト (シングルトン、キャッシュ、または参照を保持しすぎるプールなど) です。
GC.Collect を明示的に呼び出すと、暗黙的なコレクションが失敗したのと同じ理由で、メモリの解放にも失敗します。したがって、明示的な GC.Collect 呼び出しは、オーケストレーションの速度を低下させるだけです。
オーケストレーションから .Net クラスを呼び出している場合は、純粋な .Net アプリケーション (BizTalk は関係ありません) から同じクラスを呼び出して、問題を分離することをお勧めします。
リークはなくても、各インスタンスが同時に大量のメモリを消費している可能性もあります。BizTalk は通常、必要に応じてオーケストレーションを脱水できますが、オーケストレーション (または大きなアトミック スコープ) のステップの実行に時間がかかりすぎる場合は、それを実行できない場合があります。
1400 mb は、15 の同時インスタンスのみでは大きく見えます。オーケストレーションで大きなメッセージを操作していますか? その場合、メッセージ全体を強制的にメモリにロードする操作を回避し、代わりにストリーミングを使用してメッセージを操作することで、メモリ使用量を大幅に削減できます。
私は他の人が言ったことのほとんどに完全に同意します-あなたはあなたのリークがどこにあるかを調べてそれを修正する必要があります。GCを直接呼び出すことは役に立ちません。いずれの場合も、合理的な方法である可能性はほとんどありません。
ただし、リソース消費量の急激な増加に遭遇した場合に環境が停止するのを防ぐために、スロットルが存在することを付け加えておきます。スロットリングを行わないと、BizTalk（他のサーバーと同様）が処理を続行できず、効果的に「スタック」する可能性があります。スロットルを使用すると、リソース消費レベルが（うまくいけば）通常のレベルに戻るまで、処理が引き続き行われていることを確認するために速度を落とすことができます。
そのため、ご使用の環境に合わせてスロットリングを構成することを検討することをお勧めします。その値は、シナリオに合わせて調整する必要があります。
上記のポスターに同意します。メモリをクリアしたり、ホスト インスタンスをリセットしたりすることは解決策ではなく、バンドエイドにすぎません。メモリリークが発生している場所を見つける必要があります。オーケストレーションだけでなく、アプリケーション全体を検討します。ポートがメモリ リークを引き起こしている可能性もあります。マップでカスタム Functoid を使用していますか? インラインコードはどうですか？カスタム xslt? カスタム パイプラインを使用している場合は、それも検討します。可能であれば、さまざまなコンポーネントを分離し、それらを個別にストレステストとボリュームテストにかけます。どういうわけか、オーケストレーション自体が問題だとは思いませんが、むしろマップまたはカスタム コンポーネントです。
ガベージ コレクションを実行しても、アプリケーションによってまだ (エラーで) 参照されているため、リークしたメモリは解放されません。GC.Collect を呼び出すのは、存続期間の短いオブジェクトを大量に生成し、それらを解放するのに適した時点にあることがわかっている場合のみです。
漏れているコードを特定して修正する必要があります。