Поделиться через

Устранение неполадок с задержками и истечением времени ожидания в Redis под управлением Azure (предварительной версии)

  • Статья

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

В этом разделе описывается устранение неполадок с задержкой и временем ожидания, возникающих при подключении к Управляемому Redis Azure (предварительная версия).

Примечание.

Шаги по устранению проблем в этой статье также включают в себя указания по выполнению команд 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. Значение 64 221 — это число байт, принятых на уровне сокета ядра клиента, но еще не считанных приложением. Как правило, это значит, что приложение (например, 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 под управлением Azure и Использование параметров конфигурации поставщика состояния сеанса и поставщика кэша вывода).

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

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

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

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

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

Высокая загрузка ЦП

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

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

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

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

Периоды пиковой загрузки ЦП

В кэшах B0, B1, B3 и B5 могут наблюдаться кратковременные резкие увеличения нагрузки на ЦП, не вызванные увеличением количества запросов. Такое случается пару раз в день, когда на ВМ выполняются внутренние операции сканирования с помощью средства защиты. На этих уровнях наблюдается повышенная задержка запросов при выполнении внутренних операций сканирования с помощью средства защиты. На этих уровнях у кэшей только два ядра для обеспечения многозадачности, чтобы отдельно обслуживать внутреннее сканирование с помощью средства защиты и запросы Redis.

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

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

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

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

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

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

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

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

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

# 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.

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