Hi,
I notice that Signalr memory in IIS keeps increasing and never goes down even when the users are disconnected. Almost all the users (approx. 200 users) are connected using websockets.
Asp.net.SignalR.Client.dll - 2.2.3
Asp.net.SignalR.Core.dll - 2.2.3
Asp.net.SignalR.SystemWeb.dll - 2.2.3
Setup: Single server, dedicated app pool for Signalr WCF
O/S: Windows 2012 R2
Server : Ec2 T2XLarge ( 4 vCPU, 16 GB Mem)
Available Free memory : > 50%
Please refer to the IIS memory consumption taken for the application.
Regards,
Raja
cceraja
All 6 comments
Any update on why this is happening?
cceraja
on 3 Aug 2018
same issue here
firephantomassasin
on 6 Aug 2018
Can you use a memory profiler to determine which objects are being left alive? SignalR does intentionally hold messages in memory after a client disconnects in order to be able to re-broadcast those messages in the event of a reconnecting client. These messages are stored in a ring buffer so that it only buffers a fixed number of messages, but it is entirely expected that memory would not be released as soon as a client is disconnected.
Are you hitting specific performance issues directly attributed to this memory usage? SignalR should also be using weak references to ensure that this memory is freed when the Garbage Collector needs additional space. Can you provide information on the failures you are seeing?
anurse
on 6 Aug 2018
Likely #3850.
moozzyk
on 10 Aug 2018
As described above, this looks to be just the standard SignalR message buffer. SignalR uses a fixed-size ring buffer to hold messages (so old messages are only removed when space is needed) in order to allow messages to be replayed to clients that reconnect. You can modify this buffer size using the IConfigurationManager.DefaultMessageBufferSize option.
Closing this as we haven't heard any updates on the objects that are staying alive. Feel free to comment further if you have question. We can always re-open this if there's an issue to resolve!
anurse
on 24 Sep 2018
I still think this is a critical bug and that this issue should not be closed. It is a big memory leak that can easily consume a lot of memory and crash an application due to an OutOfMemoryException. Especially because the default value of DefaultMessageBufferSize is 1000 messages per Hub. Right now, I'm struggling with that.
rafael-biz
on 2 Apr 2020
Related issues
JoergTiedemann
·
3Comments
VrindiTeam
·
3Comments
markrendle
·
4Comments
OfirYemini
·
10Comments
yowl
·
9Comments
Most helpful comment
Can you use a memory profiler to determine which objects are being left alive? SignalR does intentionally hold messages in memory after a client disconnects in order to be able to re-broadcast those messages in the event of a reconnecting client. These messages are stored in a ring buffer so that it only buffers a fixed number of messages, but it is entirely expected that memory would not be released as soon as a client is disconnected.
Are you hitting specific performance issues directly attributed to this memory usage? SignalR should also be using weak references to ensure that this memory is freed when the Garbage Collector needs additional space. Can you provide information on the failures you are seeing?