Тюнинг JVM
Тема дорожной карты · Elasticsearch
Настройка JVM — критически важный аспект производительности Elasticsearch, поскольку поисковый движок работает внутри Java Virtual Machine и во многом зависит от эффективного управления памятью. Важнейшая настройка JVM для Elasticsearch — размер кучи, задаваемый в jvm.options путём установки -Xms и -Xmx в одно значение — как правило, половину доступной оперативной памяти, но не более 26 ГБ: превышение этого порога отключает сжатие обычных указателей на объекты (OOP) и увеличивает накладные расходы на память. Elasticsearch использует файловый кэш операционной системы для хранения файлов индексов Lucene за пределами кучи, поэтому крайне важно оставлять как минимум половину общей оперативной памяти нераспределённой для кучи JVM — это непосредственно влияет на производительность поиска. Выбор сборщика мусора также имеет значение: Elasticsearch рекомендует G1GC для JDK 14 и выше, принудительно задаваемый через -XX:+UseG1GC в jvm.options; частые или длительные паузы GC, видимые в GET /_nodes/stats, сигнализируют о давлении на кучу. Настройку JVM для Elasticsearch всегда следует проверять под реальной нагрузкой на тестовом кластере перед применением в продуктивной среде, поскольку подбор размера кучи нетривиально взаимодействует с количеством шардов, размерами документов и сложностью запросов.
Как это работает
Тюнинг JVM: JVM тюнинг — heap = 50% RAM, max 31GB (граница compressed oops), G1GC на современных JDK. Bulk indexing — отключите refresh во время bulk (-1), увеличьте translog flush threshold, batch 5-15MB. Search optimisation — filter context (cacheable), ограничивайте specific индексами через aliases, избегайте wildcards на big-индексах, profile API для slow queries. Мониторинг через Stack Monitoring app (или Prometheus exporter — prometheus-es-exporter).
Когда применять
Меряйте до тюнинга — profile API + slow log для идентификации проблем. Для ingest bottleneck: больше bulk batches + больше клиентов + refresh off. Для search bottleneck: cache (filter context), trim полей через _source filtering, force-merge cold-индексов. Для cluster stability: dedicate роли, тюньте thread_pool sizes, мониторьте circuit_breakers.
Типичные ошибки
Ловушки Тюнинг JVM: heap = 100% RAM (нет OS file cache — медленные queries); heap > 32GB (теряет compressed oops); выключают refresh + забывают включить обратно; force-merge hot-индексов (locks + I/O storm).