У нас есть несколько веб-ролей и рабочих ролей в Azure, подключающихся к нашему кэш-памяти Redis Azure через библиотеку StackExchange.Redis, и мы получаем регулярные тайм-ауты, из-за которых наше комплексное решение останавливается. Пример одного из них ниже:

System.TimeoutException: время ожидания выполнения потока GET: 459, инстанс: 4, мгр: неактивно, очередь: 12, qu = 0, qs = 12, qc = 0, wr = 0/0, in = 65536/0 в StackExchange.Redis .ConnectionMultiplexer.ExecuteSyncImpl [T] (Сообщение сообщения, ResultProcessor1 processor, ServerEndPoint server) in c:\TeamCity\buildAgent\work\58bc9a6df18a3782\StackExchange.Redis\StackExchange\Redis\ConnectionMultiplexer.cs:line 1785 at StackExchange.Redis.RedisBase.ExecuteSync[T](Message message, ResultProcessor1 процессор, сервер ServerEndPoint) в c: \ TeamCity \ buildAgent \ work \ 58bc9a6df18a3782 \ StackExchange.Redis \ StackExchange \ Redis \ RedisBase.cs: строка 79 в StackExchange.Redis.RedisDatabase.StringGet (ключ RedisKey, флаги CommandFlags) в c: \ TeamCity \ buildAgent \ work \ 58bc9a6df18a3782 \ StackExchange.Redis \ StackExchange \ Redis \ RedisDatabase.cs: строка 1346 в OptiRTC.Cache.RedisCacheActions. <> C__DisplayClass41.<Get>b__3() in c:\dev\OptiRTCAzure\OptiRTC.Cache\RedisCacheActions.cs:line 104 at Polly.Retry.RetryPolicy.Implementation(Action action, IEnumerable1 shouldRetryPredicates, Func`1 policyStateFactory) в OptiRTC.Cache.RedisCacheActions.Get [T] (строковый ключ, логический allowDirtyRead) в c: \ dev \ OptiRTCAzure \ OptiRTC.Cache \ RedisCacheActions.cs: строка 107 в OptiRTC. .d__e4.MoveNext () в c: \ dev \ OptiRTCAzure \ OptiRTC.Cache \ RedisCacheAccess.cs: строка 1196; Событие TraceSource 'WaWorkerHost.exe'

Все тайм-ауты имеют разные номера очередей и номеров, но остальные сообщения соответствуют друг другу. Эти вызовы StringGet относятся к разным ключам в кэше. В каждом из наших сервисов мы используем класс доступа к одноэлементному кешу с одним мультиплексором ConnectionMultiplexer, который зарегистрирован в нашем контейнере IoC при запуске веб-роли или рабочей роли:

        container.RegisterInstance<ICacheAccess>(cacheAccess);

В нашей реализации ICacheAccess мы создаем мультиплексор следующим образом:

            ConfigurationOptions options = new ConfigurationOptions();
            options.EndPoints.Add(serverAddress);
            options.Ssl = true;
            options.Password = accessKey;                    
            options.ConnectTimeout = 1000;
            options.SyncTimeout = 2500;

            redis = ConnectionMultiplexer.Connect(options);

где объект redis используется на протяжении всего экземпляра. У нас есть около 20 экземпляров веб-ролей и рабочих ролей, подключающихся к кешу через эту реализацию ICacheAccess, но консоль управления показывает в среднем 200 одновременных подключений к кешу.

Я видел другие публикации, которые ссылаются на версию 1.0.333 StackExchange.Redis, которую мы делаем через NuGet, но когда я смотрю на добавленную реальную версию ссылки StackExchange.Redis.dll, она показывает 1.0.316.0. Мы попытались добавить и удалить ссылку NuGet, а также добавить ее в новый проект, и мы всегда получаем несоответствие версий.

Любое понимание будет оценено. Благодарю.

Дополнительная информация:

Мы обновились до 1.0.371. У нас есть две службы, каждый из которых обращается к одному и тому же объекту кэша с разными интервалами: один для редактирования и периодического чтения, а другой - для чтения этого объекта несколько раз в секунду. Обе службы развернуты с одинаковым кеширующим кодом и версией библиотеки StackExchange.Redis. Я почти никогда не вижу тайм-ауты в сервисе, который редактирует объект, но я получаю тайм-ауты между 50 и 75% времени в сервисах, которые его читают. Тайм-ауты имеют тот же формат, что и указанный выше, и продолжают возникать после переноса вызова db.StringGet в блок повторных попыток Polly, который обрабатывает и RedisException, и System.TimeoutException и повторяет попытку через 500 мс.

Мы связались с Microsoft по этой проблеме, и они подтверждают, что ничего не видят в журналах Redis, указывающих на проблему со стороны службы Redis. Наш процент нехватки кэша на сервере Redis очень низок, но мы продолжаем получать эти таймауты, которые существенно ограничивают функциональность нашего приложения.

В ответ на комментарии, да, у нас всегда есть число в qs и никогда в qc. У нас всегда есть номер в первой части и никогда во второй.

Еще больше дополнительной информации:

Когда я запускаю сервис с меньшим количеством экземпляров на более высокой загрузке ЦП, я получаю значительно больше таких ошибок тайм-аута, чем когда экземпляры работают на более низких процессорах. Более конкретно, сегодня утром я вытащил некоторые цифры из наших служб. Когда они работали с процессором около 30%, я видел очень мало проблем с тайм-аутом - всего 42 за 30 минут. Когда я удалил половину экземпляров, и они начали работать на 60-65% ЦП, скорость возросла в 10 раз до 536 за 30 минут.