Управление нагрузкой на сервер для кэша Azure для Redis
Размеры значений
Структура клиентского приложения определяет, следует ли хранить большое количество небольших значений или меньшее число больших значений. С точки зрения сервера Redis чем меньше значения, тем выше производительность. Рекомендуется сохранять размер значения меньше 100 КБ.
Если для вашей структуры требуется хранить большие значения в кэше Azure для Redis, нагрузка на сервер будет выше. В этом случае может потребоваться использовать более высокий уровень кэша, чтобы гарантировать, что загрузка ЦП не будет ограничивать пропускную способность.
Даже если кэш имеет достаточно ресурсов ЦП, большие значения увеличивают задержку, поэтому следуйте указаниям в статье Настройка надлежащего времени ожидания.
Большие значения также увеличивают вероятность фрагментации памяти, поэтому обязательно следуйте указаниям в статье Настройка параметра maxmemory-reserved.
Предотвращение пиковых количеств подключений клиента
Создание и закрытие подключений является ресурсоемкой операцией для сервера Redis. Если клиентское приложение создает или закрывает слишком много подключений в течение небольшого промежутка времени, это может избыточно нагрузить сервер Redis.
Если вы создаете много экземпляров клиента для одновременного подключения к Redis, рассмотрите возможность разнести во времени создание новых соединений, чтобы избежать резкого увеличения числа подключенных клиентов.
Нехватка памяти
Высокий уровень использования памяти на сервере повышает вероятность того, что системе необходима передача данных на диск, что приводит к ошибкам страниц, которые могут значительно замедлить работу системы.
Предотвращение длительного выполнения команд
Сервер Redis — это однопотоковая система. Длительно выполняющиеся команды могут приводить к задержке или истечению времени ожидания на стороне клиента, так как сервер не может отвечать на какие-либо другие запросы, пока он занят выполнением длительно выполняющейся команды. Дополнительные сведения см. в статье Устранение неполадок с кэшем Azure для Redis на стороне сервера.
Мониторинг нагрузки на сервер
Добавьте мониторинг нагрузки на сервер, чтобы обеспечить получение уведомлений при возникновении высокой нагрузки на сервер. Мониторинг может помочь понять ограничения приложений. Кроме того, вы сможете заблаговременно предотвратить проблемы. Мы рекомендуем пытаться сохранять нагрузку на сервер ниже 80 %, чтобы избежать негативного влияния на производительность. Устойчивая нагрузка сервера на 80% может привести к отмене плановая отработка отказа. В настоящее время кэш Azure для Redis предоставляет две метрики в Аналитике в разделе Наблюдение меню ресурсов в левой части портала: ЦП и Нагрузка на сервер. Понимание того, что измеряется каждой метрикой, важно при наблюдении за нагрузкой на сервер.
Метрика ЦП указывает на использование ЦП для узла, на котором размещен кэш. Метрика ЦП также включает процессы, которые не являются строго процессами сервера Redis. ЦП включает фоновые процессы для защиты от вредоносных программ и других. В результате метрика ЦП может иногда возрастать и не быть идеальным индикатором использования ЦП для сервера Redis.
Метрика Нагрузка на сервер представляет нагрузку только на сервер Redis. Мы рекомендуем мониторить метрику Нагрузка на сервер вместо ЦП.
При мониторинге нагрузки сервера также рекомендуется проверить максимальные пики нагрузки сервера, а не среднее, так как даже краткие пики могут активировать отработку отказа и время ожидания команд.
Планирование обслуживания сервера
Убедитесь в доступности достаточной производительности серверов для обработки пиковой нагрузки во время обслуживания серверов кэша. Протестируйте систему путем перезагрузки узлов при пиковой нагрузке. Дополнительные сведения об имитации развертывания исправления см. в разделе Перезагрузка.
Проверка на наличие повышенной нагрузки на сервер после отработки отказа
Для SKU уровня "Стандартный" и "Премиум" каждый кэш размещается на двух узлах. Балансировщик нагрузки распределяет клиентские соединения между двумя узлами. Когда запланированное или незапланированное обслуживание выполняется на основном узле, тот закрывает все клиентские подключения. В таких ситуациях все клиентские соединения могут полагаться на один узел, что приводит к увеличению нагрузки на оставшийся узел. Рекомендуется протестировать этот сценарий, перезагрузив основной узел и убедившись, что один узел может обслуживать все клиентские подключения без слишком высокой нагрузки на сервер.