0

WebアプリケーションでNServiceBusを使用していますが、最近、接続状態にもかかわらずアウトバウンドキューに留まるだけで、決して離れないメッセージがいくつかあることがわかりました。それらを削除する最も簡単な解決策は、MSMQサービスを再起動することです。私がこれに遭遇した問題は、MSMQサービスを再起動または停止すると、CPUが100％にジャンプすることでした。

誰かがこれに出くわし、この高負荷を防ぐ方法を見つけましたか？サービスを停止しただけで停止するという考えは好きではありませんか？私が知っている1つの方法は、送信専用モードを使用することですが、これは理想的ではありません。

更新：global.asaxアプリケーション内で使用される構成コードの開始：

  IBus bus = Configure
            .With()
            .DefaultBuilder()
            .FileShareDataBus("c:\\storage")
            .XmlSerializer()
            .MsmqTransport()
            .IsTransactional(false)
            .PurgeOnStartup(false)
            .UnicastBus()
            .ImpersonateSender(false)
            .CreateBus()
            .Start(() => Configure.Instance.ForInstallationOn<Windows>().Install());
4

1 に答える 1

0

あなたの問題は問題に関連していると思います。MSMQパーマが正しくないと、閉じているGitHubのWebアプリケーションでCPUが高くなりますが、まだリリースされていない4.0リリースを対象としています。

問題は、NServiceBusがキューから読み取ろうとしているが、キューがないことです。そのため、プロセッサをペグするCheck-Error-Retryのタイトなループに入ります。

MSMQを停止することは、MSMQを必要とするWebサーバーに対して行うのはかなり腹立たしいことです。本番環境でこれを行う必要がある場合は、サーバーを負荷分散プールから取り出し（ロードバランサーを使用していると想定/期待しています）、MSMQを再起動してからIISを再起動することをお勧めします。サーバーがリクエストを処理していない場合、短時間の高いCPUアクティビティは実際には大したことではありません。

Bus.Send()4.0がリリースされたら、CPUの問題に対処する必要がありますが、MSMQが使用できないときにスローされるため、サーバーをローテーションから外すことをお勧めします。

于 2013-01-24T18:13:05.570 に答える