Elasticsearch: Высокая загрузка процессора

Высокая загрузка процессора часто является симптомом других проблем, и поэтому существует ряд возможных причин ее возникновения.

Table of Contents

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

Как решить эту проблему

Чтобы минимизировать влияние проблемных узлов на поисковые запросы, убедитесь, что в кластере (версии 6.1 и выше) установлены следующие настройки:

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.use_adaptive_replica_selection": true
  }
}

PUT /_cluster/settings

{

"transient": {

"cluster.routing.use_adaptive_replica_selection": true

}

Проверка сборки мусора JVM

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

В здоровой JVM сборка мусора в идеале должна удовлетворять следующим условиям:

Young GC выполняется быстро (в течение 50 мс).
Young GC выполняется нечасто (около 10 секунд).
Старый GC обрабатывается быстро (в течение 1 секунды).
Старый GC выполняется нечасто (раз в 10 минут или чаще).

Увеличение использования кучи памяти может происходить по разным причинам:

Переоценка
Большие размеры агрегации
Чрезмерный размер массового индекса
Проблемы с отображением
Неправильная установка кучи
Неправильно задано новое соотношение JVM

Проверка нагрузки на узлы данных

Если нагрузка на процессор высока только на определенных узлах данных (на одних больше, чем на других), то, возможно, возникла проблема с балансировкой нагрузки или шардингом.

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

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

Проверьте свопинг памяти на диск

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

Производительность Elasticsearch может сильно пострадать, если узлу разрешена подкачка памяти на диск. Elasticsearch можно настроить на автоматическое предотвращение подкачки памяти на хост-машине, добавив в elasticsearch.yml параметр bootstrap memory_lock true. Если проверки при загрузке включены, Elasticsearch не запустится, если свопинг памяти не отключен.

Проверка количества шардов на предмет перераспределения

Если на кластере имеется большое количество шардов, то, возможно, возникла проблема с избыточным шардингом.

Oversharding - это состояние, указывающее на то, что у вас слишком много шардов, и поэтому они слишком малы. Хотя минимального предела для размера шарда Elastic не существует, наличие большего числа шардов на кластере Elasticsearch требует дополнительных ресурсов, поскольку кластеру необходимо поддерживать метаданные о состоянии всех шардов в кластере.

Если размер хранилища слишком мал, то у вас есть три варианта:

Устранить пустые индексы
Удалить или закрыть индексы со старыми или ненужными данными
Переиндексировать в более крупные индексы

Проверка эффективности индексирования

Если индексирование выполняется неэффективно, это может повлиять на работу процессора.

Оптимизация медленных и дорогих поисковых запросов

Если поисковые запросы выполняются медленно, это может негативно сказаться на работе процессора.