Geo*_*mov 41 stackexchange.redis
我的生产环境中存在以下问题(Web-Farm - 4个节点,在它之上负载均衡器):
1)Timeout performing HGET key, inst: 3, queue: 29, qu=0, qs=29, qc=0, wr=0/0
at StackExchange.Redis.ConnectionMultiplexer.ExecuteSyncImpl[T](Message message, ResultProcessor``1 processor, ServerEndPoint server) in ConnectionMultiplexer.cs:line 1699这种情况在一分钟内发生3-10次
2) No connection is available to service this operation: HGET key at StackExchange.Redis.ConnectionMultiplexer.ExecuteSyncImpl[T](Message message, ResultProcessor``1 processor, ServerEndPoint server) in ConnectionMultiplexer.cs:line 1666
我尝试按照Marc的建议实现(也许我解释不正确) - 最好与Redis的连接数少于多个.我做了以下实现:
public class SeRedisConnection
{
private static ConnectionMultiplexer _redis;
private static readonly object SyncLock = new object();
public static IDatabase GetDatabase()
{
if (_redis == null || !_redis.IsConnected || !_redis.GetDatabase().IsConnected(default(RedisKey)))
{
lock (SyncLock)
{
try
{
var configurationOptions = new ConfigurationOptions
{
AbortOnConnectFail = false
};
configurationOptions.EndPoints.Add(new DnsEndPoint(ConfigurationHelper.CacheServerHost,
ConfigurationHelper.CacheServerHostPort));
_redis = ConnectionMultiplexer.Connect(configurationOptions);
}
catch (Exception ex)
{
IoC.Container.Resolve<IErrorLog>().Error(ex);
return null;
}
}
}
return _redis.GetDatabase();
}
public static void Dispose()
{
_redis.Dispose();
}
}
Run Code Online (Sandbox Code Playgroud)
实际上配置现在没有被使用.此外,我还有一些可能导致此类行为的实现细节(我只使用哈希):1.添加,删除哈希 - 异步2.获取-sync
有人可以帮助我避免这种行为吗?
非常感谢提前!
求助 - 评估网络功能后增加客户端连接超时.
更新2:实际上并没有解决问题.当缓存容量开始增加时,例如从2GB开始.然后我看到了相同的模式实际上这些超时大约每5分钟发生一次.我们的网站每5分钟冻结一段时间,直到叉操作完成.然后我发现有一个选项可以每x秒生成一个fork(保存到磁盘):
save 900 1
save 300 10
save 60 10000
Run Code Online (Sandbox Code Playgroud)
在我的情况下,它是"保存300 10" - 如果至少发生10次更新,则每5分钟保存一次.我还发现"叉子"可能非常昂贵.评论"保存"部分解决了这个问题.我们可以评论"保存"部分,因为我们只使用Redis作为"内存中的缓存" - 我们不需要任何持久性.以下是我们的缓存服务器"Redis 2.4.6"windows端口的配置:https://github.com/rgl/redis/downloads
也许它已经在MSOpentech的最新版本的Redis windows端口中解决了:http://msopentech.com/blog/2013/04/22/redis-on-windows-stable-and-reliable/ 但是我还没有测试过.
无论如何StackExchange.Redis与这个问题无关,它在我们的生产环境中非常稳定,这要归功于Marc Gravell.
最终更新: Redis是单线程解决方案 - 它最终是快速的,但是当涉及释放内存(删除陈旧或过期的项目)时,由于一个线程应该回收内存(不是快速操作 - 无论使用何种算法),同一个线程应该处理GET,SET操作.当然,当我们谈论中等负载的生产环境时,就会发生这种情况.即使在达到内存屏障时使用带有从属的群集,它也会具有相同的行为.
小智 1
在大多数情况下,此异常似乎是客户端问题。以前版本的 StackExchange.Redis 直接使用 Win32 套接字,这有时会产生负面影响。可能 Asp.net 内部路由在某种程度上与它有关。
好消息是 StackExchange.Redis 的网络基础设施最近已完全重写。最后版本是2.0.513。尝试一下,您的问题很有可能会得到解决。
| 归档时间: |
|
| 查看次数: |
27825 次 |
| 最近记录: |