Руководство по устранению неисправностей медленных запросов в Elasticsearch
Причиной медленных запросов часто являются
- Плохо написанными или дорогими поисковыми запросами.
- Плохо настроенные кластеры или индексы Elasticsearch.
- Перегруженные ресурсы процессора, памяти, дисков и сети на кластере.
- Периодические фоновые процессы, такие как моментальные снимки или объединение сегментов, которые потребляют ресурсы кластера (процессор, память, диск), что приводит к медленному выполнению других поисковых запросов, поскольку ресурсы для основных поисковых запросов доступны не полностью.
- Объединение сегментов используется для уменьшения количества сегментов, что улучшает задержку поиска, однако объединение может быть дорогостоящим процессом, особенно в средах с низким уровнем ввода-вывода.
Как уже говорилось выше, существует несколько потенциальных причин медленных запросов, но в системах с интенсивным поиском основными причинами обычно являются дорогие поисковые запросы или плохо настроенный кластер или индекс Elasticsearch. Эффективное использование медленных поисковых запросов может значительно сократить время на отладку/поиск неисправностей.
Руководство по устранению неполадок, как эффективно использовать медленные журналы
- Всегда определяйте соответствующий порог регистрации для поиска медленных запросов в вашем приложении. Определите различные уровни журнала для ускорения отладки. Например, более 20 мс подходит для ведения журнала TRACE, а более 250 мс следует регистрировать как WARN. Эти пороговые значения предназначены для систем реального времени, таких как поиск в электронной коммерции, и должны быть настроены на основе SLA приложения.
- Существует две фазы поиска: фаза запроса и фаза получения. Более подробную информацию можно найти здесь, на сайте Elasticsearch search explained. Важно понимать, как работают эти фазы, и установить правильный порог для каждой из них.
- Медленные журналы всегда специфичны для шарда, и именно здесь большинство людей ошибаются, когда смотрят на журнал медленных запросов, не понимая всей картины. Более подробную информацию о том, как шарды ES играют важную роль в ее производительности, можно найти в руководстве по устранению неполадок с задержкой поиска.
- Журнал медленных запросов включает фазу, к которой он относится, и по умолчанию это запрос, затем выборка, но это может быть и DFS-запрос, затем выборка, что обеспечивает лучший результат поиска за счет снижения производительности. Поэтому важно искать именно такие запросы.
- Сложение времени отклика всех медленных запросов с участием всех соответствующих шардов не дает общего времени поиска и не включает время сбора результатов со всех шардов и выборки лучших результатов (фаза выборки).
- Чтобы решить проблему, упомянутую в #4, всегда имейте в своем приложении журнал трассировки, который отслеживает параметр "took" ответа Elasticsearch. По сути, это общее время, затраченное на выполнение одного запроса Elasticsearch на всех соответствующих шардах и получение верхних результатов со всех шардов. Параметр "Took" ответа Elasticsearch - это корректный показатель общего времени, затраченного на выполнение запроса (включая время, потраченное на отправку запросов на все релевантные шарды, сбор и объединение результатов со всех шардов).
- Если вы имеете дело с многопользовательским кластером ES, на котором размещено несколько индексов, то простой проверки медленных журналов одного проблемного индекса будет недостаточно, поскольку иногда медленные журналы в проблемном индексе вызваны тяжелыми поисками в других индексах. Поэтому при возникновении проблем всегда лучше проверить медленные поисковые запросы во всем кластере (или хотя бы в больших индексах).
- Примерами тяжелых поисковых запросов являются регексовые запросы, префиксные запросы, тяжелые агрегаты, match_all, огромное значение параметра size и запросы с глубокой пагинацией. Отфильтруйте медленные журналы поиска по этим запросам и посмотрите, как работают эти запросы.