我们在服务器上运行的Windows节点有一个独立的Redis（2.8.2104）。
另外两台服务器正在与此实例进行通信。
我们将它与SignalR一起使用并用于缓存。转储的大小约为700MB
我们有时会挂机1-3分钟。在此之后它会自行恢复。
错误似乎只发生在我们页面上有一些流量时。
在这段时间我们得到了您可以在下面看到的例外
StackExchange.Redis.RedisConnectionException：EVAL上的SocketFailure 在System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess（任务 任务） System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification（任务 任务）在Microsoft.Owin.Cors.CorsMiddleware.d__0.MoveNext（） ---从抛出异常的先前位置开始的堆栈跟踪结束--- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess（任务 任务） System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification（任务 任务）在Microsoft.Owin.Mapping.MapMiddleware.d__0.MoveNext（） ---从抛出异常的先前位置开始的堆栈跟踪结束--- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess（任务
当我搜索Redis日志时，我可以偶尔发现这些错误：
[33144] 18 Feb 18：18：44.843＃
=== REDIS BUG REPORT START：Cut＆amp;从这里开始粘贴=== [33144] 18 Feb 18：18：44.844＃Out of Memory分配308457个字节。 [33144] 18 Feb 18：18：44.844＃--- ABORT [33144] 18 Feb 18：18：44.844＃--- 堆栈跟踪 Redis的-SERVER.EXE LogStackTrace！（C：\发布\的Redis的\ src \ win32_interop \ win32_stacktrace.cpp：95）（0x00000016， 0x042E0028,0x00000000,0x00000001） Redis的-SERVER.EXE AbortHandler！（C：\发布\的Redis的\ src \ win32_interop \ win32_stacktrace.cpp：206）（00000001， 0x89EE7767,0x40150880,0xBB7A5ED7） Redis的-SERVER.EXE提高！（F：\ DD \ vctools \ CRT \ crtw32 \杂项\ winsig.c：587）（00000001， 0x00000000,0x0004B4E9,0x042E0028） ！Redis的-SERVER.EXE中止（F：\ DD \ vctools \ CRT \ crtw32 \杂项\ abort.c：82）（00000001， 0x4013F888,0x0004B4E9,0x00008000） Redis的-SERVER.EXE redisOutOfMemoryHandler！（C：\发布\的Redis的\ src \ redis.c：3397）（0x0004B4E9， 0x4007DA07,0x042E0028,0x4007A27B） Redis的-SERVER.EXE zmalloc！（C：\发布\的Redis的\ src \ zmalloc.c：147）（0xBDF01150， 0x4007EB2C，0xBDF01150,0x446D6B10） Redis的-SERVER.EXE sdsnewlen！（C：\发布\的Redis的\ src \ sds.c：59）（0xBDF01150， 0xBDF01150,0x3E74FD95,0x00000003） Redis的-SERVER.EXE _addReplyStringToList！（C：\发布\的Redis的\ src \ networking.c：271）（0xBDF01150， 0xBDF01150,0x042E0028,0x400E34FE） Redis的-SERVER.EXE addReplyBulkCBuffer！（C：\发布\的Redis的\ src \ networking.c：517）（0xFFFFFFFF的， 0x042E0028,0x01B77260,0x01B77260） Redis的-SERVER.EXE luaReplyToRedisReply！（C：\发布\的Redis的\ src \ scripting.c：792）（0x00000004， 0xBDF01150,0x00000002,0x00000002） Redis的-SERVER.EXE luaReplyToRedisReply！（C：\发布\的Redis的\ src \ scripting.c：839）（0xFFFFFFFF的， 0x00A7F690,0x67897B20,0xBDF01150） Redis的-SERVER.EXE evalGenericCommand！（C：\发布\的Redis的\ src \ scripting.c：1048）（0x71E66870， 0x00000000,0x00000001,0x000000B2） Redis的-SERVER.EXE来电！（C：\发布\的Redis的\ src \ redis.c：2016）（0x56C60B04， 0x4008B000,0x00000000,0x000000B2） Redis的-SERVER.EXE processCommand！（C：\发布\的Redis的\ src \ redis.c：2235）（0xBDF01150， 0x000000B2,0x000023B5,0x00000001） Redis的-SERVER.EXE processInputBuffer！（C：\发布\的Redis的\ src \ networking.c：1274）（0xBDF01150， 0x00000000,0x00000000,0x00000001） Redis的-SERVER.EXE readQueryFromClient！（C：\发布\的Redis的\ src \ networking.c：1329）（0xFFE51650， 0x00000001,0x44726F20,0x0000012C） Redis的-SERVER.EXE aeMain！（C：\发布\的Redis的\ src \ ae.c：487）（0x56C5C7F8， 0x00000002,0x00000000,0x00000002） Redis的-SERVER.EXE redis_main！（C：\发布\的Redis的\ src \ redis.c：3524）（0x0024BA50， 0x00000002,0x56C5C7EB，0x00000002） Redis的-SERVER.EXE主！（C：\发布\的Redis的\ src \ win32_interop \ win32_qfork.cpp：1363）（0x00000016， 0xFFFFFFFF，0x00000016,0x0023F3A0） Redis的-SERVER.EXE ServiceWorkerThread！（C：\发布\的Redis的\ src \ win32_interop \ win32_service.cpp：485）（0x4000B3D0， 0x00000000,0x00000000,0x00000000） ！KERNEL32.DLL BaseThreadInitThunk（C：\发布\的Redis的\ src \ win32_interop \ win32_service.cpp：485）（0xBB0113B0， 0x00000000,0x00000000,0x00000000） ！ntdll.dll中RtlUserThreadStart（C：\发布\的Redis的\ src \ win32_interop \ win32_service.cpp：485）（00000000， 0x00000000,0x00000000,0x00000000） ！ntdll.dll中RtlUserThreadStart（C：\发布\的Redis的\ src \ win32_interop \ win32_service.cpp：485）（00000000， 0x00000000,0x00000000,0x00000000）[33144] 18 Feb 18：18：44.857＃ === REDIS BUG报告结束。确保从START到END包含。 ===
maxheap设置为3000mb 服务器总共有64 GB RAM，大约10GB是免费的
还有一件事，但我不确定它是否真正解决了这个问题。
大多数情况下，问题会增加其频率。然后，当我重置其中一个服务器的iis时，问题就完全消失了几个小时或几天。我想到可能有挂/堆信号队列。但我没有任何进一步的迹象表明情况可能就是这样。
有关于此的任何提示吗？
答案 0 :(得分：0)
我发现解决方案与signalR本身无关，但客户端signalR Scaleout正在使用。
我发现如果您使用默认的Microsoft.AspNet.SignalR.Redis包，它包含对旧StackExchange.Redis客户端的私有引用。
此客户端在释放客户端连接句柄时遇到问题。现在，当重新启动IIS或redis服务器时，所有这些句柄都被释放，一切都再次运行。
一种解决方案是构建自己的signalR Scaleout流实现
另一个（对我们来说更容易）就是禁用signalR scaleout流。
正在访问redis的所有其他组件都使用ServiceStack.Redis，它可以正常工作。
现在大约一个月后，我们在redis服务器上遇到了更多问题。