Asp.net Core 3.1 SignalR Hub内存过高OOM，DefaultMessageBufferSize如何设置？

关于DefaultMessageBufferSize配置的说明 #

DefaultMessageBufferSize是传统ASP.NET SignalR（非Core版本）的专属配置参数，ASP.NET Core 全版本SignalR均未提供该配置入口，你检索到的该参数不适用于Core 3.1的开发场景。

Asp.Net Core 3.1 SignalR 内存过高、WebSocket断开解决方案 #

基础配置优化 #

在Startup.cs的ConfigureServices方法中添加如下SignalR全局配置，从框架层面限制内存开销：

services.AddSignalR(hubOptions =>
{
    // 限制单条接收消息最大大小，默认值为32KB，可根据业务场景向下调整，避免大消息占用过多内存
    hubOptions.MaximumReceiveMessageSize = 10 * 1024;
    // 限制单客户端并发调用Hub方法的数量，默认值为10，并发不高的场景可下调
    hubOptions.MaximumParallelInvocationsPerClient = 5;
    // 生产环境关闭详细错误输出，减少内存开销
    hubOptions.EnableDetailedErrors = false;
    // 调整连接超时参数，自动清理僵死连接
    hubOptions.HandshakeTimeout = TimeSpan.FromSeconds(10);
    hubOptions.KeepAliveInterval = TimeSpan.FromSeconds(12);
    hubOptions.ClientTimeoutInterval = TimeSpan.FromSeconds(30);
})
// 调整Json序列化配置，避免序列化生成超大对象
.AddJsonProtocol(options =>
{
    options.PayloadSerializerOptions.MaxDepth = 32;
});

同时配置Kestrel服务器的WebSocket帧大小限制，减少单连接内存占用：

services.Configure<Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerOptions>(options =>
{
    options.Limits.WebSocket.MaxFrameSize = 4 * 1024;
});

业务层面优化 #

• 不要在服务端全局缓存消息用于重放：ASP.NET Core SignalR默认不提供断线重连的消息持久化能力，如果你的业务自行实现了消息缓存逻辑，必须严格限制缓存队列的最大长度，超过阈值时主动移除最早的消息，避免队列无限膨胀。
• 大消息拆分发送：单条消息大小不要超过16KB，超过该大小的对象会进入大对象堆（LOH），GC回收效率极低，容易造成内存碎片化，最终触发内存不足异常。
• 连接生命周期管理：在Hub的OnDisconnectedAsync方法中及时清理当前连接关联的所有业务缓存，避免无效内存占用。
• 排查连接泄漏：如果内存增长速度远超业务预期，可先统计当前活跃的SignalR连接数，如果连接数远大于实际在线用户数，说明存在客户端未正常关闭连接导致的连接泄漏，可结合上面的超时配置自动清理无效连接。

内容的提问来源于stack exchange，提问作者Trilok Kumar