Взрывы ошибок Redis

Question

Недавно мы создали новый Standard 1 GB Azure кэш Redis специально для распределенной блокировки - отдельно от нашего основного кэша Redis. Это было сделано для улучшения стабильности нашего основного кэша Redis, что является очень долгосрочным вопросом, с которым, по-видимому, это действие значительно помогло.

В нашем новом кэше мы наблюдаем выбросы ~ 100 ошибок в тех же самых немногих секунд каждые 1 - 3 дня. Возможны следующие ошибки:

No connection is available to service this operation (ошибка StackExchange.Redis)

Или:

Could not acquire distributed lock: Conflicted (ошибка RedLock. net)

Поскольку они являются ошибками из разных пакетов, я подозреваю, что проблема заключается в самом кэше Redis. Ни одна из статистических данных за это время не выходит за рамки обычного, и рабочая нагрузка должна соответствовать удобному размеру в стандартном размере 1 ГБ. скорее всего причина?

Answer 1

У Роба есть несколько отличных предложений, но он хотел добавить информацию об устранении неполадок traffi c burst и плохих настройках ThreadPool. См. Устранение неполадок Azure Кэш для проблем на стороне клиента Redis

Пакеты трафика c в сочетании с плохими настройками ThreadPool могут привести к задержкам в обработке данных, уже отправленных сервер Redis, но еще не использованный на стороне клиента.

Отслеживайте, как меняется статистика ThreadPool с течением времени, используя пример ThreadPoolLogger . Вы можете использовать сообщения TimeoutException от StackExchange.Redis, как показано ниже, для дальнейшего изучения:

System.TimeoutException: Timeout performing EVAL, inst: 8, mgr: Inactive, queue: 0, qu: 0, qs: 0, qc: 0, wr: 0, wq: 0, in: 64221, ar: 0,
IOCP: (Busy=6,Free=999,Min=2,Max=1000), WORKER: (Busy=7,Free=8184,Min=2,Max=8191)

• Обратите внимание, что в разделах IOCP и WORKER у вас есть Значение Busy больше значения Min. Эта разница означает, что ваши ThreadPool настройки нуждаются в корректировке.
• Вы также можете увидеть in: 64221. Это значение указывает, что 64 211 байт было получено на уровне сокета ядра клиента, но не было прочитано приложением. Это различие обычно означает, что ваше приложение (например, StackExchange.Redis) не читает данные из сети так быстро, как сервер отправляет их вам.

Вы можете настроить Настройки ThreadPool , чтобы обеспечить быстрое увеличение пула потоков в режиме пакетной обработки ios.

Надеюсь, вы найдете эту дополнительную информацию полезной.

Answer 2

Ваша теория звучит правдоподобно.

Проверка недостаточной пропускной способности сети

Вот удобная таблица , показывающая максимальную наблюдаемую пропускную способность для различных уровней ценообразования. Посмотрите на наблюдаемую максимальную пропускную способность для вашего SKU, затем перейдите на свой блейд Redis на портале Azure и выберите Metrics. Установите агрегацию на Max и посмотрите на сумму чтения и записи в кэш. Это ваша общая пропускная способность. Наложите сумму этих двух значений на период времени, в течение которого вы обнаружите ошибки, и посмотрите, не связана ли проблема с пропускной способностью сети. Если это так, увеличьте масштаб.

Проверка загрузки сервера

Также на вкладке Metrics вы можете посмотреть нагрузку на сервер. Это процент того, что Redis занят и не может обрабатывать запросы. Если вы наберете 100%, Redis не сможет отвечать на новые запросы, и у вас возникнут проблемы с таймаутом. Если это так, увеличьте масштаб.

Повторное использование ConnectionMultiplexer

Вы также можете исчерпать соединения с сервером Redis, если вы раскручиваете новый экземпляр StackExchange.Redis.ConnectionMultiplexer для каждого запроса. Пределы обслуживания для количества доступных соединений на основе вашего SKU составляют здесь на странице цен. Вы можете увидеть, превышаете ли вы максимально допустимые соединения для вашего SKU на вкладке Metrics, выберите max aggregation и выберите Connected Clients в качестве показателя c.

Исчерпание темы

Это не похоже на вашу ошибку, но я добавлю ее для полноты в выпуски этой галереи Redis Rogue, и она вступит в игру с Azure Веб-приложениями. По умолчанию пул потоков будет начинаться с 4 потоков, которые можно сразу выделить для работы. Когда вам нужно более четырех потоков, они раздаются со скоростью один поток на 500 мс. Таким образом, если вы сбросите тонну запросов в веб-приложении за короткий промежуток времени, вы можете закончить работу с очередями и в конечном итоге отбросить запросы еще до того, как они попадут в Redis. Чтобы проверить, является ли это проблемой, go выберите Метрики для вашего веб-приложения, выберите Потоки и установите агрегацию на макс. Если за короткий промежуток времени вы видите огромный всплеск, который соответствует вашей проблеме, вы нашли виновника. Решения включают в себя правильное использование async / await. И когда это не даст вам больше пользы, используйте ThreadPool.SetMinThreads с более высоким значением, предпочтительно таким, которое близко или превышает максимальное использование потока, которое вы видите в своих пакетах.