約 14000 のメッセージであふれたシングルトン (シーケンシャル コンボイ) オーケストレーション インスタンスがあります。これは、インスタンスが 8 日間処理されていることを意味しますが、現在の処理速度は非常に遅いです (7 分に約 1 回)。インスタンスは高速で起動しましたが、ここ数日で現在のパフォーマンス レベルまで低下しました。
このインスタンスからさらにメッセージを迂回させました。バックログの処理が完了したら終了する予定です。
問題は、計算した現在の処理速度に基づいて、処理が完了するまでに 3 日あることです (約 660 メッセージの処理が残っています)。
私の質問は次のとおりです。これをスピードアップする方法はありますか?
これに対する回避策を作成することができました。
この新しいインスタンスは、前のインスタンスのすべての履歴 (消費されたメッセージ) によって妨げられていないため、実行速度が約 60 倍速くなり、残りのバックログが高速にクリアされました。
消費されたが処理されていないメッセージを特定する方法は、ここに記載されている方法を使用することでした。
メッセージ ボックス データベースからメッセージ GUID のリストを取得したら、残りは次の場所に文書化されています。
要約すると、メッセージ ID を取得したら、メッセージ ボックス db の Parts テーブルから imgPart 列を選択します。これにより、メッセージ本文のバイナリ エンコードされた圧縮バージョンが得られます。次に、上記の記事のコードを使用してメッセージを再構築します。
この後、すべてのメッセージを取得し、MSMQ 受信場所を介してそれらを biztalk に送り返すだけでした。
長期的には、この問題の発生につながった設計上の欠陥に対処する必要があります。フラッディングは予想されていませんでしたが、実行中のプロセスのパフォーマンスが重い負荷の下で床を突き破ってしまうことは決して良いことではありません。
私たちが抱えている問題は、コンシューマー システムの大部分で、ソース メッセージの順序を維持する必要があることです。このため、どこにでもシングルトンがあり、そのすべてがこの問題にさらされる可能性があります。
ここで、BizTalk でのメッセージの再シーケンス戦略について投稿しました: BizTalk での順序付けされた配信のための再シーケンス戦略
最初のシングルトン/マルチトン パターンで同様の動作に気付きました。原因は、非常に多くのメッセージがオーケストレーションと「相関」しているためであると思われました。メッセージの処理が完了しても、オーケストレーション インスタンスがまだ実行されていたため、メッセージボックスから確実に削除されません (BTS 2009、SP なし)。スプール テーブルが最大 50 万行に達すると、すべてのホストがスロットリング状態になり (6だったと思います)、スループットが劇的に低下しました。
以下が役立ちました：
メッセージボックス/スプールテーブルのレベルが原因でサーバーがスロットリングしていることが判明した場合、「データベースのメッセージ数のしきい値」を一時的に 10 倍に増やしてからホストを再起動すると、現在のバックログがクリアされる可能性があります。
BTSデータベースジョブが稼働中であり、正しく構成されていることを確認してください。