Biztalk 2006アプリケーションには、頻繁に呼び出される2つのオーケストレーションが含まれています（約15要求/秒）。ホストで一定のスロットリングしきい値の変更を行うことで、アプリケーションのメモリリークの可能性を特定しました。メモリベースのスロットリングを無効にすると、プロセスメモリは1400 MBまで増加し始め、その後、メモリ不足の例外を経験し始めました。
この状況が発生した場合、強制的にホストインスタンスを再起動します。
このような場合、OrchestrationからGC.Collectを明示的に呼び出すのが効果的かどうか疑問に思っていました。このアプローチを使用することの短所は何でしょうか？BizTalkでのガベージコレクション、賢明なアプローチは何ですか？
ありがとうございました。私の答えは道オフかもしれ
を知らないのBizTalk ...私はより多くのオーケストレーションインスタンスがプロセス内で実行されていると仮定しています
は、それが完了するために、単一のオーケストレーションインスタンスに要する時間が長くなります。次に、同時に実行できるオーケストレーションインスタンスの数を増やすと、完了するまでにかかる時間が十分に長くなり、実行中のオーケストレーションインスタンスのサイズがRAMに十分に大きくなります。
私は、実行中のオーケストレーションインスタンスの数に基づいてスロットルを行う必要があると思います。 「実行中のオーケストレーションインスタンス数」に対して「完了率」をグラフ表示すると、グラフの中央に大きなフラットゾーンが表示される可能性があります。この安定ゾーンの中央に維持するための調整を選択します。
メモリ不足の例外は、ガベージコレクタが要求された割り当てを実行するのに十分なメモリを解放できなかった場合にのみ発生します。これは、メモリリークがある場合に発生します。これは、ガベージコレクションされたプラットフォームでは、オブジェクト参照が必要以上に長く保持されることを意味します。頻繁なリークの原因は、グローバルデータ（静的変数）を保持するオブジェクトです（シングルトン、キャッシュ、参照を長時間保持するプールなど）。
GC.Collectを明示的に呼び出すと、暗黙的な収集が失敗したのと同じ理由でメモリが解放されません。したがって、GC.Collectを呼び出すと、オーケストレーションが遅くなるだけです。
あなたのオーケストレーションから.NETクラスを呼び出す場合、私は
（何のBizTalkが関与していない）純粋な.NETアプリケーションから同じクラスを呼び出すことによって、問題を特定しようと提案することが、何のリークはありませんということも可能です各インスタンスが同時に多くのメモリを消費していることを示します。 BizTalkは通常、オーケストレーションが必要であると判断するとオーケストレーションを脱水できますが、オーケストレーションのステップ（またはアトミックスコープの大きいもの）が実行に時間がかかりすぎると、BizTalkがその操作を行うことを防ぐことができます。
1400 mbも、15個の同時インスタンスに対して大きく見えます。あなたはオーケストレーションの大きなメッセージの操作をしていますか？その場合、メッセージ全体を強制的にメモリにロードし、代わりにストリーミングを使用してメッセージを操作する操作を避けることで、メモリ使用量を大幅に削減できます。
私は上記のポスターに同意します。メモリをクリアしたり、ホストインスタンスをリセットしようとするのは解決策ではなく、ただのバンドアシストです。あなたはどこにメモリが漏れているのかを知る必要があります。オーケストレーションだけではなく、アプリケーション全体を見ていきます。ポートがメモリリークを引き起こす可能性があります。あなたのマップでカスタムFunctoidsを使用していますか？インラインコードについてはどうですか？カスタムxslt？ カスタムパイプラインを使用している場合は、カスタムパイプラインも参照してください。 可能であれば、私はさまざまなコンポーネントを分離し、個々にストレスとボリュームテストの下に置くことを試みます。どういうわけかあなたのオーケストレーション自体が問題ではなく、むしろマップまたはカスタムコンポーネントだと思います。
ガベージコレクトを実行しても、アプリケーションによって何らかの理由で参照されている（エラーのままである）メモリが解放されるわけではありません。 GC.Collectを呼び出すのは、短命のオブジェクトをたくさん生成し、それらを解放するのがよい時点であることがわかっている場合だけです。
漏れたコードを特定して修正する必要があります。
私は、他の人の言い伝えの大部分に完全に同意しています。あなたの漏れがどこにあるのかを調べて修正する必要があります。 GCを直接呼び出すことはあなたを助けませんし、どんな場合でも合理的な方法であることはほとんどありません。
リソース消費量が急激に増加すると、環境が停止するのを防ぐために調整が行われます。抑制することなくBizTalk（他のサーバーと同様）が処理を続行できず、効果的に「停止」する可能性があります。スロットルを使用すると、リソース消費レベル（期待どおり）が通常レベルに戻るまで、処理がまだ行われていることを確認するために処理が遅くなることがあります。
このような理由から、環境に合わせて調整を行うことをお勧めします。値はシナリオに合わせて調整する必要があります。