【问题标题】:StackExchange.Redis timeout and "No connection is available to service this operation"StackExchange.Redis 超时和“没有可用于服务此操作的连接”
【发布时间】:2014-05-20 18:49:33
【问题描述】:

我在我们的生产环境中遇到以下问题(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();
    }
}

实际上 dispose 现在没有被使用。我也有一些可能导致这种行为的实现细节(我只使用哈希): 1. 添加、删除哈希 - 异步 2.获取-sync

有人可以帮助我如何避免这种行为吗?

提前非常感谢!

已解决 - 评估网络功能后增加客户端连接超时。

UPDATE 2:实际上并没有解决问题。当缓存量开始增加时,例如从 2GB。 然后我看到了同样的模式,实际上这些超时大约每 5 分钟发生一次。 我们的网站每 5 分钟被冻结一段时间,直到分叉操作完成。 然后我发现有一个选项可以每 x 秒创建一个 fork(保存到磁盘):

save 900 1
save 300 10
save 60 10000

在我的情况下,它是“保存 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 操作。当我们谈论中等负载的生产环境时,当然会发生这种情况。即使你在达到内存屏障时使用带有从属的集群,它也会有相同的行为。

【问题讨论】:

  • 如果您使用的是 Asp.Net,请尝试在 stackoverflow.com/questions/25416562/… 中参考我的答案,这为我修复了队列超时错误,即您的问题 1 和 2。我尝试了其他方式(单例和锁定)来保持较少的联系,但没有运气!,希望这会有所帮助
  • 非常有帮助,谢谢!我实际上修改了保存之间的时间,以确保不会有大量的项目队列要保存到磁盘,这会导致足够的延迟导致查询超时。
  • 嘿,很不幸,我们完全停止使用 Redis,因为它证明了它的单线程架构具有超时。示例:我们有 32GB / 4 个节点的缓存服务器(集群)。当达到内存的最大阈值时,Redis 会尝试释放内存,然后发生超时。我承认我们在生产中大量使用了 Redis,它一直运行良好,直到达到内存阈值。所以我们选择了另一个多线程缓存解决方案。但正如我所说,也许对于您的音量和配置,它会起作用,但是当达到内存阈值时,您应该进行一些负载测试。
  • 谢谢,我们每天必须处理 1000 万条记录,每条记录需要多次 GET 到 Redis。其中大部分是在高峰时段内收到的。我们已经接受,有时 Redis 会同步到磁盘并锁定唯一的线程,然后耐心等待直到完成。在调整 I/O 同步时间以限制此问题(**以增加丢失记录的风险为代价)之后,我们在 Redis 运行良好的地方找到了一个很好的平衡点。似乎很遗憾没有用于 I/O 同步的单独线程!
  • @GeorgeAnisimov 所以我们选择了另一个多线程缓存解决方案,你能提供给我们这个解决方案吗

标签: stackexchange.redis


【解决方案1】:

在大多数情况下,此异常似乎是客户端问题。 StackExchange.Redis 的早期版本直接使用 Win32 套接字,这有时会产生负面影响。可能与它有关的 Asp.net 内部路由。
好消息是 StackExchange.Redis 的网络基础设施最近完全重写了。最后一个版本是 2.0.513。试试看,你的问题很有可能会解决。

【讨论】:

  • 很遗憾,我在使用 Microsoft.Web.RedisSessionStateProvider 的最新版本 (v4.0.1) 中包含的最新版本的 StackExchange.Redis (v2.0.519) 时仍然遇到此问题。作为一个对此更新感到非常兴奋的人,到目前为止,我发现它并没有解决我的问题。我已经对我们的 ThreadPool 设置进行了调整,以确保我们不会被低最小值限制,评估了我们在 Azure 中的缓存指标,仍然看到 EVAL 函数有很多超时。
  • @Kaitebug 我知道这已经快一年了,但你有没有找到解决方案?我们正在使用最新版本的 StackExchange.Redis (2.0.601.3402) 并尝试了您在此处列出的相同操作,但自升级以来仍不断遇到这些问题。
猜你喜欢
  • 1970-01-01
  • 2018-05-06
  • 2020-04-01
  • 2019-11-25
  • 2016-03-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多