Оптимизация использования памяти Elasticsearch для максимальной производительности

Проблемы с памятью в Elasticsearch обычно проявляются в виде медленного поиска, длительных пауз сборки мусора, ошибок автоматических выключателей или узлов, покидающих кластер. Оптимизация использования памяти Elasticsearch означает балансировку кучи JVM, кэша файловой системы, количества шардов, поведения запросов и нагрузки индексации, а не просто увеличение -Xmx.

Цель проста: предоставить Elasticsearch достаточно кучи для работы кластера и запросов, оставив при этом достаточно оперативной памяти для кэширования файлов сегментов Lucene операционной системой.

Понимание компонентов памяти Elasticsearch

Elasticsearch использует память в двух основных областях:

Куча JVM: Содержит метаданные кластера, буферы индексации, структуры запросов, fielddata (если включено), кэши и другие объекты Java. Слишком маленькая куча вызывает давление и срабатывание автоматических выключателей. Слишком большая куча может увеличить время сборки мусора и лишить кэш файловой системы ресурсов.
Кэш файловой системы и нативная память: Операционная система кэширует файлы индексов Lucene вне кучи JVM. Elasticsearch также использует нативную память для сетевого взаимодействия, стеков потоков и файлов с отображением в память.

Настройка размера кучи JVM

Размер кучи — это первый параметр, который стоит проверить. Elasticsearch использует файлы jvm.options или специфичные для окружения параметры JVM в зависимости от способа установки.

Установите `Xms` и `Xmx` одинаковыми

Установите -Xms и -Xmx одинаковыми, чтобы JVM не изменяла размер кучи во время работы узла.

Как правило, держите кучу на уровне или ниже половины физической оперативной памяти и избегайте превышения порога сжатых указателей на обычные объекты. На практике многие производственные узлы остаются ниже примерно 30 ГБ кучи, но вам следует проверить точный порог и рекомендации для вашей версии Elasticsearch и JVM.

Например:

-Xms4g
-Xmx4g

Это устанавливает начальный и максимальный размер кучи равным 4 ГБ.

Мониторинг использования кучи

Используйте мониторинг стека Kibana, экспортеры Prometheus или API статистики узлов:

curl -X GET "localhost:9200/_nodes/stats/jvm?pretty"

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

Снижение нагрузки на память от шардов и запросов

Структура индекса и форма запроса напрямую влияют на память.

Размер и количество шардов

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

Например, если ежедневный индекс логов создает 30 первичных шардов для 20 ГБ данных, вы платите накладные расходы за множество маленьких шардов. Один или два первичных шарда могут быть проще в управлении, в зависимости от политики хранения и шаблонов запросов.

Слияние сегментов

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

Оптимизация поиска и агрегаций

Используйте поля keyword для агрегаций: Агрегируйте и сортируйте по полям keyword, числовым, датам или другим полям с поддержкой doc-values. Избегайте включения fielddata для больших текстовых полей, если вы не понимаете стоимость в куче.
Ограничивайте дорогие запросы: Ведущие подстановочные знаки и широкие запросы с регулярными выражениями могут быть затратными. Предпочитайте структурированные поля, префиксы, n-граммы или сопоставления "search-as-you-type", когда вариант использования требует частичного совпадения.
Профилируйте медленные поиски: Используйте API профилирования в тестовой среде, чтобы найти пункты запроса, создающие наибольшую нагрузку.

Используйте кэши осознанно

Elasticsearch имеет несколько кэшей. Они помогают при повторной работе, но также потребляют память.

Кэш запросов шарда: Кэширует результаты поиска на уровне шарда для подходящих запросов, часто полезен для повторяющихся запросов с агрегациями по почти неизмененным данным. Его размер контролируется с помощью:
```
indices.requests.cache.size: 5%
```
Этот пример устанавливает размер кэша запросов шарда равным 5% кучи.
Кэш запросов узла: Кэширует результаты контекста фильтра. Его размер контролируется отдельно:
```
indices.queries.cache.size: 10%
```
Кэш fielddata: Потребляет кучу и может быстро расти, если включить fielddata для текстовых полей. Предпочитайте правильное сопоставление полей вместо использования большего кэша fielddata.

Предотвращение ошибок OutOfMemory

Ошибки OutOfMemory обычно являются конечным результатом устойчивого давления. Исправление редко заключается в "увеличении всех лимитов".

Относитесь к сборке мусора как к симптому

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

Ключевые индикаторы проблем с GC включают:

Высокое время GC.
Длинные паузы "stop-the-world".
Использование кучи, которое после каждой сборки снова приближается к лимиту.
Ошибки OOM при больших поисках, массовой индексации или агрегациях.

Уважайте автоматические выключатели

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

Выключатель fielddata: Ограничивает кучу, используемую для fielddata.
Выключатель запросов: Ограничивает память, используемую для структур данных запроса.
Родительский выключатель: Отслеживает суммарные оценки выключателей.

Просмотрите статистику выключателей с помощью:

curl -X GET "localhost:9200/_nodes/stats/breaker?pretty"

Вы можете изменить некоторые настройки выключателей через настройки кластера, но делайте это только после того, как поймете, почему выключатель срабатывает. Сработавший выключатель часто защищает узел от OOM.

Мониторинг и оповещения

Оповещайте о:

Использовании кучи JVM после сборки мусора.
Времени сборки мусора и длинных паузах.
Срабатываниях автоматических выключателей.
Нагрузке индексации и отклоненных задачах в пулах потоков.
Давлении на память ОС и использовании подкачки.
Количестве шардов на узел и необычно больших агрегациях.

Вывод

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