Устранение неполадок с задержками и истечением времени ожидания в Кэше Azure для Redis

  • Статья

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

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

Примечание.

Шаги по устранению проблем в этой статье также включают в себя указания по выполнению команд Redis и мониторингу различных метрик производительности. Дополнительные сведения и указания см. в разделе Дополнительные сведения.

Устранение неполадок на стороне клиента

Вот устранение неполадок на стороне клиента.

Резкий рост трафика и конфигурация пула потоков

Увеличение трафика в сочетании с недостаточными параметрами ThreadPool может привести к возникновению задержек обработки данных, отправленных сервером Redis, но еще не использованных на стороне клиента. Проверьте метрику «Ошибки» (тип: UnresponsiveClients), чтобы проверить, смогут ли ваши клиентские узлы справиться с внезапной пиковой нагрузкой трафика.

Наблюдайте за тем, как изменяется со временем статистика 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. Это значение означает, что 6421 байт были получены на уровне сокета ядра клиента, но не были прочитаны приложением. Как правило, это значит, что приложение (например, StackExchange.Redis) не успевает считывать весь объем данных, отправленных с сервера.

Настроив параметры ThreadPool соответствующим образом, можно обеспечить быстрое вертикальное увеличение масштаба пула потоков при всплесках трафика.

Большое значение ключа

Дополнительные сведения об использовании нескольких ключей и меньших значений см. в разделе Учет дополнительных ключей и меньших значений.

Для проверки больших ключей в кэше можно использовать команду redis-cli --bigkeys. Дополнительные сведения см. в разделе redis-cli, интерфейс командной строки Redis--Redis.

  • Увеличьте размер виртуальной машины, чтобы получить более высокие возможности пропускной способности
    • Больше пропускной способности на виртуальной машине клиента или сервера может снизить время передачи данных для более крупных ответов.
    • Сравните текущее использование сети в обеих виртуальных машинах с ограничениями, установленными для виртуальных машин этого размера. Больше пропускной способности только на сервере или только на клиенте может быть недостаточно.
  • Увеличить число объектов подключения, используемых приложением.
    • Используйте метод циклического перебора, чтобы запросы совершались через разные объекты подключения

Высокая загрузка ЦП на клиентских узлах

Высокая загрузка ЦП клиента указывает, что система не может следить за работой, назначенной ей. Несмотря на то, что кэш быстро отправил ответ, клиент может не обработать ответ своевременно. Наша рекомендация заключается в том, чтобы сохранить ЦП клиента менее 80 %. Проверьте метрику «Ошибки» (тип: UnresponsiveClients), чтобы определить, смогут ли узлы клиента своевременно обрабатывать ответы от сервера Redis.

Отслеживайте загрузку ЦП клиентской системы с помощью соответствующих метрик на портале Azure или счетчиков производительности на компьютере. Не путайте ее с загрузкой ЦП от процесса, так как она может быть низкой для одиночного процесса, но высокой в масштабе всей системы. Понаблюдайте за пиками загрузки ЦП, которые соответствуют времени ожидания. Высокая загрузка ЦП также может привести к высоким in: XXX значениям в сообщениях об ошибках, как описано в TimeoutException разделе [Всплеск трафика].

Примечание.

В StackExchange.Redis 1.1.603 и более поздней версии в сообщениях об ошибках TimeoutException содержится метрика local-cpu. Убедитесь, что вы используете последнюю версию пакета NuGet для StackExchange.Redis. Ошибки в коде регулярно исправляются в коде, чтобы сделать код более стабильным с учетом таймаутов. Важно установить последнюю версию.

Чтобы устранить повышенную загрузку ЦП на клиенте:

  • выясните, с чем связаны пики загрузки ЦП;
  • выделить для клиента виртуальную машину большего размера с бо́льшей производительностью ЦП.

Ограничение пропускной способности сети на клиентских узлах

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

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

Чтобы устранить эту проблему, уменьшите потребление пропускной способности сети или выделите для клиента виртуальную машину большего размера с бо́льшей пропускной способностью сети. Дополнительные сведения см. в разделе Большой размер запроса или отклика.

Параметры TCP для клиентских приложений на базе Linux

Из-за оптимистичных параметров TCP в Linux в клиентских приложениях, размещенных в Linux, могут возникать проблемы с подключением. Дополнительные сведения см. в разделе Параметры TCP для клиентских приложений, размещенных в Linux

Таймаут повторной попытки RedisSessionStateProvider

Если вы используете RedisSessionStateProvider, убедитесь, что время ожидания повтора задано правильно. Значение retryTimeoutInMilliseconds должно быть больше, чем значение operationTimeoutInMilliseconds. В противном случае повторные попытки не выполняются. В следующем примере для retryTimeoutInMilliseconds задано значение 3000. Дополнительные сведения см. в статьях Поставщик состояния сеанса ASP.NET для Redis и How to use the configuration parameters of Session State Provider and Output Cache Provider (Использование параметров конфигурации поставщика состояния сеанса и поставщика кэша вывода).

<add 
    name="AFRedisCacheSessionStateProvider"
    type="Microsoft.Web.Redis.RedisSessionStateProvider"
    host="enbwcache.redis.cache.windows.net"
    port="6380"
    accessKey="..."
    ssl="true"
    databaseId="0"
    applicationName="AFRedisCacheSessionState"
    connectionTimeoutInMilliseconds = "5000"
    operationTimeoutInMilliseconds = "1000"
    retryTimeoutInMilliseconds="3000"
>

Устранение проблем на стороне сервера

Вот устранение неполадок на стороне сервера.

обслуживание сервера;

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

Дополнительные сведения см. проверка в следующих разделах:

Чтобы проверить, не выполнялась ли отработка отказа в кэше Azure для Redis во время таймаутов, проверьте метрику Ошибки. В меню ресурсов на портале Azure выберите Метрики. Затем создайте диаграмму, которая измеряет метрику Errors с разбивкой по ErrorType. После создания этой диаграммы отображается количество отработок отказа.

Дополнительные сведения об отработке отказа см. в разделе Отработка отказа и исправление кэша Azure для Redis.

Высокая нагрузка на сервер

Высокая нагрузка на сервер означает, что сервер Redis не может справиться с запросами, что приведет к истечению времени ожидания. Сервер медленно реагирует и не может обеспечивать нужную частоту запросов.

Отслеживайте метрики, такие как загрузка сервера. Понаблюдайте за пиками загрузки Server Load, которые соответствуют времени ожидания. Создайте оповещения для таких метрик, как загрузка сервера, чтобы заранее получать уведомления о возможных влияниях.

Существует несколько изменений, которые позволяют снизить высокую нагрузку на сервер:

  • Изучите то, что вызывает высокую нагрузку сервера, например длительные команды, указанные в этой статье, из-за высокого давления памяти.
  • Увеличьте масштаб горизонтально с созданием дополнительных сегментов для распределения нагрузки на несколько процессов Redis или вертикально для увеличения размера кэша с дополнительными ядрами ЦП. Дополнительные сведения см. в статье с вопросами и ответами по планированию Кэша Azure для Redis.
  • Если рабочая нагрузка рабочей нагрузки в кэше C1 негативно влияет на дополнительную задержку от сканирования вирусов, вы можете уменьшить влияние, заплатите более высокий уровень предложения с несколькими ядрами ЦП, например C2.

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

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

Использование большого объема памяти

Этот раздел перемещен. Дополнительные сведения см. в разделе Использование большого объема памяти.

Длительно выполняющиеся команды

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

Изучите команды, которые отдаете серверу Redis, чтобы понять, как они влияют на производительность. Например, команду KEYS часто используют, не зная, что это операция с линейной сложностью (O(N)). Вместо KEYS можно использовать SCAN, чтобы уменьшить пики загрузки ЦП.

Команда SLOWLOG GET позволяет измерять показатели ресурсоемких команд, выполняемых на сервере.

Клиенты могут использовать консоль для выполнения этих команд Redis для изучения длительных и дорогостоящих команд.

  • Команда SLOWLOG используется для чтения и сброса журнала запросов с задержкой Redis. Ее можно использовать для изучения длительных команд на стороне клиента. Журнал операций с задержкой Redis — это система для записи в журнал запросов, время выполнения которых превышает заявленное. Время выполнения не включает операции ввода-вывода, такие как беседа с клиентом, отправка ответа и т. д., но только время, необходимое для фактического выполнения команды. Клиенты могут измерять и записывать дорогостоящие команды, выполняемые на сервере Redis с помощью SLOWLOG команды.
  • MONITOR — это команда отладки, которая осуществляет обратную потоковую передачу каждой команды, обрабатываемой сервером Redis. Она позволяет понять, что происходит с базой данных. Эта команда довольно ресурсоемкая и может негативно сказаться на производительности. Она может привести к снижению производительности.
  • INFO — команда возвращает сведения и статистические данные о сервере в формате, который доступен для анализа компьютером и чтения человеком. В этом случае можно ознакомиться с разделом «ЦП», чтобы изучить использование ЦП. Нагрузка сервера с 100 (максимальным значением) означает, что сервер Redis был занят все время и никогда не был бездействующим при обработке запросов.

Пример выходной привязки:

# CPU
used_cpu_sys:530.70
used_cpu_user:445.09
used_cpu_avg_ms_per_sec:0
server_load:0.01
event_wait:1
event_no_wait:1
event_wait_count:10
event_no_wait_count:1
  • CLIENT LIST — эта команда возвращает информацию и статистику о сервере клиентских подключений в человекочитаемом формате.

Ограничение пропускной способности сети

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

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

Чтобы устранить ситуации, когда пропускная способность сети используется практически по максимуму:

Исключения времени ожидания StackExchange.Redis

Более подробные сведения о действиях по истечении таймаута при использовании StackExchange.Redis см. в разделе Изучение исключений таймаута в StackExchange.Redis.

Связанный контент