やあ、
IISのSignalrメモリは増加し続け、ユーザーが切断されてもダウンすることはありません。 ほとんどすべてのユーザー(約200ユーザー)がWebSocketを使用して接続されています。
Asp.net.SignalR.Client.dll-2.2.3
Asp.net.SignalR.Core.dll-2.2.3
Asp.net.SignalR.SystemWeb.dll-2.2.3
セットアップ:単一サーバー、SignalrWCF専用のアプリプール
O / S:Windows 2012 R2
サーバー:Ec2 T2XLarge(4 vCPU、16 GB Mem)
使用可能な空きメモリ:> 50%
アプリケーションで使用されるIISのメモリ消費量を参照してください。
よろしく、
ラジャ
なぜこれが起こっているのかについての更新はありますか?
ここで同じ問題
メモリプロファイラーを使用して、どのオブジェクトが生き残っているかを判断できますか? SignalRは、クライアントが再接続した場合にそれらのメッセージを再ブロードキャストできるようにするために、クライアントが切断した後、意図的にメッセージをメモリに保持します。 これらのメッセージは、固定数のメッセージのみをバッファリングするようにリングバッファに格納されますが、クライアントが切断されるとすぐにメモリが解放されないことが完全に予想されます。
このメモリ使用量に直接起因する特定のパフォーマンスの問題に直面していますか? SignalRは、ガベージコレクターが追加のスペースを必要とするときにこのメモリが解放されるように、弱参照も使用する必要があります。 発生している障害に関する情報を提供できますか?
おそらく#3850。
上記のように、これは単なる標準のSignalRメッセージバッファのように見えます。 SignalRは、固定サイズのリングバッファを使用してメッセージを保持し(したがって、古いメッセージはスペースが必要な場合にのみ削除されます)、再接続するクライアントにメッセージを再生できるようにします。 このバッファサイズは、 IConfigurationManager.DefaultMessageBufferSizeオプションを使用して
生き続けているオブジェクトの更新を聞いていないので、これを閉じます。 ご不明な点がございましたら、お気軽にコメントしてください。 解決すべき問題がある場合は、いつでもこれを再度開くことができます。
これは重大なバグであり、この問題を解決するべきではないと私はまだ考えています。 これは大きなメモリリークであり、 OutOfMemoryExceptionが原因で大量のメモリを簡単に消費し、アプリケーションをクラッシュさせる可能性があります。 特に、 DefaultMessageBufferSizeのデフォルト値はハブあたり1000メッセージであるためです。 今、私はそれに苦労しています。
最も参考になるコメント
メモリプロファイラーを使用して、どのオブジェクトが生き残っているかを判断できますか? SignalRは、クライアントが再接続した場合にそれらのメッセージを再ブロードキャストできるようにするために、クライアントが切断した後、意図的にメッセージをメモリに保持します。 これらのメッセージは、固定数のメッセージのみをバッファリングするようにリングバッファに格納されますが、クライアントが切断されるとすぐにメモリが解放されないことが完全に予想されます。
このメモリ使用量に直接起因する特定のパフォーマンスの問題に直面していますか? SignalRは、ガベージコレクターが追加のスペースを必要とするときにこのメモリが解放されるように、弱参照も使用する必要があります。 発生している障害に関する情報を提供できますか?