Исключение из-за множественного подключения Redis (нет доступного подключения к службе) во время слотов подкачки службы приложения

Question

У меня есть веб-приложение в работе (.Net Core), я развернул его в Azure как службу приложений, которая находится в 4-х экземплярах премиум-уровня p2v2. Я также использую кэш Azure Redis (Premium Tier), который мое приложение использует в качестве кэша. У меня есть две службы приложений (основная и дополнительная), настроенные для балансировки нагрузки.

Каждый раз, когда я пытаюсь развернуть свое приложение в рабочей среде с помощью функции подкачки, время отклика службы приложения увеличивается до 20 секунд, ион отключается примерно на 1 минуту, а загрузка процессора приближается к 90%. И я вижу несколько исключений от клиента Redis (Например: нет соединения, доступного для обслуживания этой операции: EVAL; Не удалось подключиться к серверу (ам) Redis. Чтобы создать отключенный мультиплексор, отключите AbortOnConnectFail. ConnectTimeout; IOCP: (Занято = 0, Свободно = 1000, Мин = 8, Макс = 1000), РАБОЧИЙ: (Занято = 452, Свободно = 32315, Мин = 8, Макс = 32767), Локальный процессор: н / д) и мой HttpQueueдлина превышает 10

Из приведенного выше изображения я могу сделать вывод, что рабочий поток был перегружен, не знаю, почему это происходит

Я использую .Net StackExchange Redis client версии 2.0.601, недавносделал обновление с версии 1.2.4

Примечание: я не использовал настройку приложения для определенного слота. Это происходит для каждого слота подкачки во время развертывания. Я не нашел перезапуска службы приложений в журналах.

Я хочу знать, кто-нибудь из вас, ребята, сталкивался с этой проблемой, если да, пожалуйста, подскажите мне, в чем проблемаили как отлаживать, и было бы лучше, если бы вы могли поделиться чем-то, что вы пытались.

Я пытался найти какие-либо журналы ошибок на сервере кэширования Redis AZure, но не смог их найти.

Я пытаюсь выяснить, что является причиной этой проблемы, как отладить такого рода проблемы с помощью Azure, и сталкивался ли кто-нибудь с таким же и реализовал ли какое-либо решение для того же самого?

Пожалуйстадайте мне знать, если вам понадобятся какие-либо дополнительные сведения.

Answer 1

Вот кое-что, что стоит попробовать:

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

Каждая метрика включает две версии. Одна метрика измеряет производительность для всего кэша, а для кешей, использующих кластеризацию, вторая версия метрики, которая включает в себя (Shard 0-9) в имени, измеряет производительность для одного сегмента в кэше. Например, если в кеше 4 сегмента, число попаданий в кэш - это общее количество попаданий для всего кэша, а количество попаданий в кэш (фрагмент 3) - это просто попадания в этот фрагмент кеша.

Попробуйте найтиМетрика ошибки при мониторинге.

https://docs.microsoft.com/en-us/azure/azure-cache-for-redis/cache-how-to-monitor#available-metrics-and-reporting-intervals

Кроме того, нам нужно повторить попытку для TimeoutException, RedisConnectionException или SocketException, которые гарантируют, чтоон попытается подключиться в случае каких-либо исключений, вы можете прочитать о всех лучших практиках использования Redis Cache ниже в документе:

https://docs.microsoft.com/en-us/azure/azure-cache-for-redis/cache-best-practices

https://docs.microsoft.com/en-us/azure/azure-cache-for-redis/cache-best-practices#when-is-it-safe-to-retry

Надеюсь, это поможет.