Высокая загрузка процессора часто является симптомом других проблем, и поэтому существует ряд возможных причин ее возникновения.
Причины высокой загрузки процессора должны быть исследованы и устранены, поскольку неисправный узел в лучшем случае замедлит время отклика на запросы, что приведет к тайм-ауту клиентов, а в худшем - приведет к отключению узла и его полной потере из кластера.
Как решить эту проблему
Чтобы минимизировать влияние проблемных узлов на поисковые запросы, убедитесь, что в кластере установлены следующие настройки:
| 1 2 3 4 5 6 | PUT /_cluster/settings { "transient": { "cluster.routing.use_adaptive_replica_selection": true } } |
Проверка сборки мусора JVM
Высокая загрузка процессора обычно является следствием сборки мусора в JVM, которая, в свою очередь, вызвана проблемами конфигурации или запросов.
В здоровой JVM сборка мусора в идеале должна удовлетворять следующим условиям:
- Young GC выполняется быстро (в течение 50 мс).
- Young GC выполняется нечасто (около 10 секунд).
- Старый GC обрабатывается быстро (в течение 1 секунды).
- Старый GC выполняется нечасто (раз в 10 минут или чаще).
Увеличение использования кучи памяти может происходить по разным причинам:
- Большое количество шардов (Oversharding)
- Большие размеры агрегации
- Чрезмерный размер массового индекса
- Проблемы с маппингом
- Неправильная установка кучи
- Неправильно задано новое соотношение JVM
Проверка нагрузки на узлах данных
Если нагрузка на процессор высока только на определенных узлах данных (на одних больше, чем на других), то, возможно, имеет место проблема с балансировкой нагрузки или шардингом.
Иногда это может быть вызвано приложениями, которые неправильно распределяют нагрузку между узлами данных и выполняют все HTTP-вызовы только на одном или нескольких узлах. Это следует исправить в вашем приложении.
Однако чаще всего "горячие" индексы располагаются на небольшом количестве узлов. Типичным примером может служить приложение для ведения журналов, создающее ежедневные индексы с одним шардом на индекс. В этом случае, хотя у вас может быть много индексов, распределенных по всем шардам, вы можете обнаружить, что вся индексация выполняется только на одном шарде на одном узле, который содержит сегодняшний индекс логирования.
Проверьте свопинг памяти на диск
Процессор также может быть симптомом свопинга памяти на диск, если он не был отключен на узле должным образом.
Производительность OpenSearch может сильно пострадать, если на узле разрешена подкачка памяти на диск. OpenSearch можно настроить на автоматическое предотвращение подкачки памяти на хост-машине, добавив в elasticsearch.yml параметр bootstrap memory_lock true. Если проверки при загрузке включены, OpenSearch не запустится, если свопинг памяти не отключен.
Проверка количества шардов на избыточность
Если в кластере имеется большое количество шардов, то, возможно, возникла проблема с избыточным количеством шардов.
Oversharding - это состояние, указывающее на то, что у вас слишком много шардов, и поэтому они слишком малы. Хотя минимального ограничения на размер шарда OpenSearch не существует, наличие большего числа шардов на кластере OpenSearch требует дополнительных ресурсов, поскольку кластеру необходимо поддерживать метаданные о состоянии всех шардов в кластере.
Если размер ваших шардов слишком мал, то у вас есть три варианта:
- Устранить пустые индексы
- Удалить или закрыть индексы со старыми или ненужными данными
- Переиндексировать в более крупные индексы
Проверка эффективности индексирования
Если индексирование неэффективно, это может повлиять на работу процессора.
Оптимизация медленных и дорогих поисковых запросов
Если поисковые запросы выполняются медленно, это может повлиять на работу процессора.
