Устранение медленных запросов Elasticsearch: выявление и шаги по решению

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

Начните с самого запроса, если можете его получить. Расплывчатое сообщение о том, что "поиск медленный", трудно обработать. Скопированное тело запроса, целевой шаблон индекса, временной диапазон, задержка на стороне пользователя и временная метка позволяют сравнить медленный запрос с метриками кластера за тот же момент.

Понимание задержки запросов Elasticsearch

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

• Объем и сложность данных: Объем данных, количество полей и сложность документов могут напрямую влиять на время поиска.
• Сложность запроса: Простые запросы term выполняются быстро; сложные запросы bool с множеством условий, агрегаций или запросы script могут быть ресурсоемкими.
• Стратегия маппинга и индексации: То, как ваши данные индексируются (например, поля text vs. keyword, использование fielddata), существенно влияет на эффективность запросов.
• Состояние кластера и ресурсы: ЦП, память, дисковый ввод-вывод и сетевая задержка на узлах кластера имеют решающее значение. Нездоровый кластер или узлы с ограниченными ресурсами неизбежно приведут к медленной производительности.
• Шардирование и репликация: Количество и размер шардов, а также их распределение по узлам влияют на параллелизм и извлечение данных.

Первоначальные проверки медленных запросов

Прежде чем использовать продвинутые инструменты профилирования, всегда начинайте с этих фундаментальных проверок:

1. Мониторинг состояния кластера

Проверьте общее состояние вашего кластера Elasticsearch с помощью API _cluster/health. Статус red указывает на отсутствующие первичные шарды, а yellow означает, что некоторые реплики шардов не распределены. Оба состояния могут серьезно повлиять на производительность запросов.

GET /_cluster/health

Ищите status: green, но не останавливайтесь на этом. Зеленый кластер все еще может быть перегружен, плохо шардирован или выполнять неэффективные запросы.

2. Проверка ресурсов узла

Исследуйте использование ресурсов отдельных узлов. Высокая загрузка ЦП, низкий объем доступной памяти (особенно кучи) или насыщенный дисковый ввод-вывод являются сильными индикаторами узких мест.

GET /_cat/nodes?v
GET /_cat/thread_pool?v

Обратите внимание на cpu, load_1m, heap.percent и disk.used_percent. Большие размеры очередей пула потоков search также указывают на перегрузку.

3. Анализ медленных логов

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

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

PUT /my-index/_settings
{
  "index.search.slowlog.threshold.query.warn": "10s",
  "index.search.slowlog.threshold.fetch.warn": "1s"
}

Затем отслеживайте логи Elasticsearch на предмет записей типа [WARN][index.search.slowlog].

Глубокое погружение: выявление узких мест с помощью Profile API

Когда первоначальные проверки не выявляют проблему или вам нужно понять, почему конкретный запрос медленный, Profile API Elasticsearch является вашим самым мощным инструментом. Он предоставляет детальную разбивку того, как выполняется запрос на низком уровне, включая время, затраченное каждым компонентом.

Что такое Profile API?

Profile API возвращает полный план выполнения поискового запроса, детализируя время, затраченное на каждый компонент запроса (например, TermQuery, BooleanQuery, WildcardQuery) и фазу сбора. Это позволяет точно определить, какие части вашего запроса потребляют больше всего времени.

Как использовать Profile API

Просто добавьте "profile": true в тело вашего существующего поискового запроса:

GET /your_index/_search?profile=true
{
  "query": {
    "bool": {
      "must": [
        { "match": { "title": "elasticsearch" } }
      ],
      "filter": [
        { "range": { "date": { "gte": "now-1y/y" } } }
      ]
    }
  },
  "size": 0, 
  "aggs": {
    "daily_sales": {
      "date_histogram": {
        "field": "timestamp",
        "fixed_interval": "1d"
      }
    }
  }
}

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

Интерпретация вывода Profile API

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

• type: Тип выполняемого Lucene-запроса или коллектора (например, BooleanQuery, TermQuery, WildcardQuery, MinScoreCollector).
• description: Человекочитаемое описание компонента, часто включающее поле и значение, с которым он работает.
• time_in_nanos: Общее время (в наносекундах), затраченное этим компонентом и его дочерними элементами.
• breakdown: Детальная разбивка времени, затраченного на различные фазы (например, rewrite, build_scorer, next_doc, advance, score).

Пример интерпретации: Если вы видите WildcardQuery или RegexpQuery с высоким time_in_nanos и значительной частью времени, затраченной на rewrite, это указывает на то, что переписывание запроса (расширение шаблона с подстановочными знаками) очень дорого, особенно для полей с высокой кардинальностью или больших индексов.

...
"profile": {
  "shards": [
    {
      "id": "_na_",
      "searches": [
        {
          "query": [
            {
              "type": "BooleanQuery",
              "description": "title:elasticsearch +date:[1577836800000 TO 1609459200000}",
              "time_in_nanos": 12345678,
              "breakdown": { ... },
              "children": [
                {
                  "type": "TermQuery",
                  "description": "title:elasticsearch",
                  "time_in_nanos": 123456,
                  "breakdown": { ... }
                },
                {
                  "type": "PointRangeQuery",
                  "description": "date:[1577836800000 TO 1609459200000}",
                  "time_in_nanos": 789012,
                  "breakdown": { ... }
                }
              ]
            }
          ],
          "aggregations": [
            {
              "type": "DateHistogramAggregator",
              "description": "date_histogram(field=timestamp,interval=1d)",
              "time_in_nanos": 9876543,
              "breakdown": { ... }
            }
          ]
        }
      ]
    }
  ]
}
...

В этом упрощенном примере, если DateHistogramAggregator показывает непропорционально высокий time_in_nanos, ваша агрегация является узким местом.

Распространенные причины медленных запросов и стратегии их решения

Основываясь на ваших выводах Profile API и общем состоянии кластера, вот распространенные проблемы и их решения:

1. Неэффективный дизайн запроса

Проблема: Некоторые типы запросов по своей сути ресурсоемки, особенно на больших наборах данных.

• Запросы wildcard, prefix, regexp: Они могут быть очень медленными, так как требуют итерации по многим термам.
• Запросы script: Выполнение скриптов для каждого документа для фильтрации или оценки чрезвычайно дорого.
• Глубокая пагинация: Использование from и size с очень большими смещениями.
• Слишком много условий should: Булевы запросы с сотнями или тысячами условий should могут стать очень медленными.

Шаги по решению:

• Избегайте широких запросов wildcard / prefix / regexp для больших полей:
  • Для поиска по мере ввода используйте completion suggesters или n-grams во время индексации.
  • Для точных префиксов рассмотрите специально созданные поля префиксов, index_prefixes или стратегию keyword, соответствующую вашим данным.
• Минимизируйте запросы script: Пересмотрите, можно ли перенести логику на этап индексации (например, добавив выделенное поле) или обработать стандартными запросами/агрегациями.
• Оптимизируйте пагинацию: Для глубокой пагинации на стороне пользователя используйте search_after со стабильной сортировкой. Используйте Scroll API для пакетного извлечения данных, а не для интерактивных страниц поиска.
• Рефакторинг запросов should: Объедините похожие условия или рассмотрите фильтрацию на стороне клиента, если это уместно.

2. Отсутствующие или неэффективные маппинги

Проблема: Неправильные маппинги полей могут заставить Elasticsearch выполнять дорогостоящие операции.

• Текстовые поля, используемые для точного сопоставления/сортировки/агрегации: Поля text анализируются и токенизируются, что делает точное сопоставление неэффективным. Сортировка или агрегация по ним требует fielddata, что интенсивно использует кучу.
• Избыточная индексация: Индексация полей, которые никогда не ищутся или не анализируются без необходимости.

Шаги по решению:

• Используйте keyword для точного сопоставления, сортировки и агрегаций: Для полей, требующих точного сопоставления, фильтрации, сортировки или агрегации, используйте тип поля keyword.
• Используйте multi-fields: Индексируйте одни и те же данные разными способами (например, title.text для полнотекстового поиска и title.keyword для точного сопоставления и агрегаций).
• Отключите index для неиспользуемых поисковых полей: Если поле только отображается и никогда не ищется, рассмотрите "index": false. Будьте осторожны с отключением _source; это влияет на обновления, переиндексацию, отладку и рабочие процессы восстановления.

3. Проблемы с шардами

Проблема: Неправильное количество или размер шардов может привести к неравномерному распределению нагрузки или чрезмерным накладным расходам.

• Слишком много маленьких шардов: Каждый шард имеет накладные расходы. Слишком много маленьких шардов может нагрузить мастер-узел, увеличить использование кучи и замедлить поиск за счет увеличения количества запросов.
• Слишком мало больших шардов: Ограничивает параллелизм во время поиска и может создавать "горячие точки" на узлах.

Шаги по решению:

• Оптимальный размер шардов: Стремитесь к размеру шардов от 10 ГБ до 50 ГБ. Используйте индексы на основе времени (например, logs-YYYY.MM.DD) и индексы с перекатыванием для управления ростом шардов.
• Переиндексация и сжатие/разделение: Используйте API _reindex, _split или _shrink для консолидации или изменения размера шардов в существующих индексах.
• Мониторинг распределения шардов: Убедитесь, что шарды равномерно распределены по узлам данных.

4. Настройки кучи и JVM

Проблема: Недостаточный объем памяти кучи JVM или неоптимальная сборка мусора могут вызывать частые паузы и низкую производительность.

Шаги по решению:

• Выделите достаточный объем кучи: Установите Xms и Xmx на одно и то же значение. Распространенная отправная точка — не более половины физической ОЗУ, оставаясь ниже порога сжатых обычных указателей объектов, который часто составляет около 30 ГБ.
• Мониторинг сборки мусора JVM: Используйте GET _nodes/stats/jvm?pretty или специальные инструменты мониторинга для проверки времени GC. Частые или длительные паузы GC указывают на давление на кучу.

5. Дисковый ввод-вывод и сетевая задержка

Проблема: Медленное хранилище или сетевые узкие места могут быть фундаментальной причиной задержки запросов.

Шаги по решению:

• Используйте быстрое хранилище: SSD настоятельно рекомендуются для узлов данных Elasticsearch. NVMe SSD еще лучше для высокопроизводительных сценариев использования.
• Обеспечьте достаточную пропускную способность сети: Для больших кластеров или сред с интенсивной индексацией/запросами пропускная способность сети имеет решающее значение.

6. Использование Fielddata

Проблема: Использование fielddata для полей text для сортировки или агрегаций может потреблять огромные объемы кучи и приводить к исключениям OutOfMemoryError.

Шаги по решению:

• Избегайте fielddata: true для полей text: Эта настройка отключена по умолчанию для полей text не просто так. Вместо этого используйте multi-fields для создания подполя keyword для сортировки/агрегаций.

Лучшие практики оптимизации запросов

Чтобы предотвратить медленные запросы на упреждение:

• Предпочитайте контекст filter для условий без оценки релевантности: Если вам не нужна оценка релевантности для условий range, term или exists, поместите их в предложение filter запроса bool. Фильтры пропускают оценку и часто легче оптимизируются Elasticsearch.
• Используйте запрос constant_score для фильтрации: Это полезно, когда у вас есть query (не filter), который вы хотите выполнить в контексте фильтра для получения преимуществ кэширования.
• Проектируйте для повторного использования кэша, где это уместно: Elasticsearch автоматически решает, что кэшировать. Повторяющиеся фильтры по стабильным данным выигрывают больше, чем уникальные одноразовые фильтры с постоянно меняющимися значениями.
• Настройте indices.query.bool.max_clause_count: Если вы достигли лимита по умолчанию (1024) с множеством условий should, рассмотрите возможность перепроектирования запроса или увеличения этого параметра (с осторожностью).
• Регулярный мониторинг: Постоянно отслеживайте состояние кластера, ресурсы узлов, медленные логи и производительность запросов, чтобы выявлять проблемы на ранней стадии.
• Тестируйте, тестируйте, тестируйте: Всегда тестируйте производительность запросов на реалистичных объемах данных и нагрузках в среде staging перед развертыванием в продакшене.

Лучшее исправление запроса обычно видно в доказательствах. Медленные логи показывают форму запроса. Profile API показывает, какая часть запроса тратит время. Статистика узлов показывает, было ли у кластера достаточно ЦП, кучи и дискового ввода-вывода во время выполнения запроса. Соберите это вместе, прежде чем менять настройки, и вы избежите настройки симптома, в то время как реальная проблема продолжает работать.