Сколько RAM нужно для Elasticsearch

MAATRIX

Elasticsearch — тот случай, когда «просто добавить памяти» не работает так линейно, как хотелось бы: половину RAM он отдаёт под JVM-кучу, вторую половину принципиально требует оставить свободной для файлового кеша Lucene, и если нарушить этот баланс, кластер начинает тормозить или падать по OOM даже с виду на мощном сервере. Разберём, откуда берётся аппетит Elasticsearch к памяти, как посчитать нужный объём под свою нагрузку и какие настройки реально спасают от типичных провалов в проде.

Почему Elasticsearch делит память на две неравные части

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

Отсюда классическое правило Elastic (его подтверждает и официальная документация, и практика эксплуатации): отдавайте под heap не больше 50% физической RAM сервера, а оставшуюся половину — операционной системе под файловый кеш. Это не рекомендация «на всякий случай» — если отдать под heap 80-90% памяти, Lucene останется без кеша, каждый запрос будет читать сегменты с диска, и производительность поиска просядет в разы даже при формально «мощном» heap.

Второй важный нюанс — потолок heap около 30-31 ГБ, независимо от того, сколько RAM физически стоит в сервере. Это связано с механизмом compressed oops в JVM: пока heap меньше порога (номинально 32 ГБ, но безопасная граница из-за выравнивания объектов ближе к 30-31 ГБ), JVM использует 32-битные сжатые указатели на объекты. Как только heap переваливает за эту границу, JVM переключается на полные 64-битные указатели, и эффективная плотность объектов в heap парадоксально падает, а не растёт вместе с размером кучи. Поэтому на серверах со 128 ГБ и больше RAM не имеет смысла давать Elasticsearch heap 60-64 ГБ — эффективнее держать heap на 30-31 ГБ и добавлять узлы, а не раздувать один процесс.

Сколько RAM нужно на heap для реальной работы

Формулы «RAM = N × размер индекса» не существует — heap Elasticsearch расходуется не столько на сами данные (они лежат в основном в off-heap структурах Lucene и файловом кеше), сколько на служебные операции:

• Метаданные шардов и сегментов — каждый открытый шард держит в heap структуры для быстрого доступа к своим сегментам; чем больше шардов на узле, тем больше базовый оверхед, даже если сами шарды маленькие.
• Кеш запросов и агрегаций — bucket-агрегации (terms, date_histogram, вложенные агрегации) строят промежуточные структуры прямо в heap, и на больших кардинальностях полей это может стать основным потребителем памяти в кластере.
• Индексирующий буфер (indices.memory.index_buffer_size, по умолчанию 10% heap) — буферизует новые документы перед flush на диск; при высокой скорости записи это заметная доля heap.
• Кеш полей для сортировки и скриптов — если поле не типизировано как doc_value (а по умолчанию для большинства типов doc_values и так off-heap), fielddata может съедать heap непредсказуемо; это одна из классических причин OOM на старых версиях ES.

Практический ориентир, которым реально пользуются при сайзинге: на каждый 1 ГБ heap — не больше 20 активных шардов (более старая рекомендация Elastic была строже, но общий принцип не изменился: чем больше heap, тем больше шардов можно держать открытыми без деградации). Если у вас 50 индексов по 5 шардов каждый на узле с 4 ГБ heap — это уже 250 шардов на 4 ГБ, то есть больше 60 шардов на гигабайт, и кластер будет постоянно давить на heap просто на служебных операциях, ещё до реальной нагрузки поиском.

Таблица: ориентиры по сценариям

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

Важно: колонка «RAM сервера» всегда примерно вдвое больше heap — это не round-число для красоты, а прямое следствие правила 50/50 из первого раздела. Если видите рекомендацию поставить heap в 24 ГБ на сервер с 32 ГБ RAM — это уже нарушение баланса, и на таком сервере Lucene будет голодать по файловому кешу. Если считаете сайзинг под задачу с нуля и нужен более широкий контекст по подбору конфигурации сервера под аналитическую нагрузку, у нас есть отдельный разбор выделенного сервера для аналитики больших данных.

Роли узлов: где RAM критична, а где можно экономить

В кластере Elasticsearch узлы редко равнозначны по требованиям к памяти — и раздача RAM «поровну на всех» часто просто неэффективна:

• Data-узлы — самые прожорливые: тут крутится и индексация, и обслуживание поисковых запросов, и агрегации. Основная точка приложения RAM в кластере.
• Master-узлы (выделенные, node.roles: [master]) — держат только состояние кластера (метаданные индексов, маппинги, распределение шардов), данных не индексируют и не ищут. Для кластера среднего размера достаточно 4-8 ГБ RAM с heap 2-4 ГБ — раздувать его смысла нет.
• Ingest-узлы — pipeline-обработка документов перед индексацией (парсинг, grok, enrich). RAM нужна под буферы обработки, но заметно меньше, чем data-узлу с тем же трафиком.
• Coordinating-узлы (без ролей data/master/ingest) — принимают запросы, разбивают по data-узлам, собирают и мёржат результат. При тяжёлых агрегациях по многим шардам именно coordinating-узел может упереться в heap при мёрже — это стоит учитывать на кластерах с десятками data-узлов.

На небольших инсталляциях (до нескольких десятков ГБ данных) все роли обычно совмещают на одних и тех же узлах — разделение ролей начинает окупаться, когда кластер растёт за пределы 3-5 узлов и нагрузка на master-состояние (частые изменения маппингов, много индексов с ILM) начинает мешать обслуживанию запросов.

Настройка: heap, ОС и типичные грабли конфигурации

Heap задаётся через jvm.options (или переменную ES_JAVA_OPTS в Docker) — и Xms/Xmx всегда должны быть равны, иначе JVM будет тратить циклы на изменение размера кучи во время работы:

# docker-compose.yml
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.15.0
    environment:
      - ES_JAVA_OPTS=-Xms16g -Xmx16g
      - bootstrap.memory_lock=true
    ulimits:
      memlock:
        soft: -1
        hard: -1
    deploy:
      resources:
        limits:
          memory: 32g

Обратите внимание на bootstrap.memory_lock: true — эта настройка запрещает ядру выгружать heap Elasticsearch в swap. Своп для JVM-кучи — почти всегда плохая идея: если страницы heap попадут в swap, garbage collector будет тормозить непредсказуемо долго, а задержки поиска станут скачкообразными без явной причины в логах приложения. На сервере с Elasticsearch правильнее вообще снизить vm.swappiness до минимума и держать своп только как аварийную подушку, а не как рабочий механизм — логика подбора размера свопа под такие сценарии разобрана в статье про правильный размер swap для VPS.

Ещё пара параметров ОС, без которых Elasticsearch либо не стартует, либо нестабилен под нагрузкой:

# /etc/sysctl.conf — лимит memory-mapped областей для Lucene + подкачка
vm.max_map_count=262144
vm.swappiness=1

# применить без перезагрузки
sysctl -w vm.max_map_count=262144

# /etc/security/limits.conf — снять ограничения на дескрипторы и память
elasticsearch soft nofile 65536
elasticsearch hard nofile 65536
elasticsearch soft memlock unlimited
elasticsearch hard memlock unlimited

Начиная с Elasticsearch 7.x по умолчанию используется G1GC вместо CMS — для heap от 8 ГБ и выше это, как правило, разумный выбор из коробки, и вручную менять сборщик мусора нужно редко, разве что у вас уже есть конкретные метрики долгих GC-пауз из мониторинга.

Как понять, что памяти не хватает

Три источника, по которым Elasticsearch честно сигнализирует о проблемах с heap, — это API кластера, логи и системные логи ядра:

# Текущее давление на heap по узлам
curl -s "http://localhost:9200/_cat/nodes?v&h=name,heap.percent,ram.percent,cpu"

# Детальная статистика по JVM конкретного узла
curl -s "http://localhost:9200/_nodes/stats/jvm?pretty"

# Сработавшие circuit breaker'ы — ES сам обрывает операции, чтобы не упасть в OOM
curl -s "http://localhost:9200/_nodes/stats/breaker?pretty"

# Был ли OOM killer на уровне ядра
dmesg -T | grep -i "killed process"

Если heap.percent в _cat/nodes стабильно держится выше 85% вне пиков (а не только после тяжёлых агрегаций) — это ранний сигнал: либо шардов на узле слишком много относительно heap, либо агрегации идут по полям с высокой кардинальностью без разумных лимитов (size, terms_enum), либо пора добавлять RAM или узлы. Circuit breaker с ошибкой [parent] Data too large — это ES защитился сам, не дав себе упасть в OOM; частое появление такой ошибки означает, что heap систематически мал для нагрузки, а не разовую случайность.

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

Частые вопросы