Производительность
Тема дорожной карты · Elasticsearch
Оптимизация производительности Elasticsearch охватывает набор практик в области индексирования, поиска и настройки оборудования, которые в совокупности обеспечивают быстрые ответы на запросы и высокую пропускную способность приёма данных в масштабе. На стороне индексирования наибольший эффект дают: группировка записей через Bulk API по адресу POST /_bulk, увеличение index.refresh_interval для сокращения частоты создания сегментов и правильный подбор размера кучи JVM в jvm.options. Для производительности поиска использование контекста filter в bool-запросах вместо must позволяет Elasticsearch кешировать результаты и пропускать вычисление релевантности; кроме того, отказ от паттернов с ведущими подстановочными знаками и ограничение возвращаемых полей _source снижают нагрузку на кучу в момент выполнения запроса. Решения по дизайну индекса — подбор правильного числа шардов, маппинг числовых полей как keyword, если они используются только для фильтрации, и применение doc_values для сортировки — оказывают долгосрочное влияние на производительность Elasticsearch, которое сложно исправить после заполнения индекса данными. Мониторинг счётчиков отклонённых запросов с помощью GET /_nodes/stats/thread_pool необходим для диагностики узких мест: отклонения в пулах bulk или search указывают на недостаточную ёмкость кластера относительно входящей нагрузки.
Как это работает
Производительность: 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.
Типичные ошибки
Ловушки Производительность: heap = 100% RAM (нет OS file cache — медленные queries); heap > 32GB (теряет compressed oops); выключают refresh + забывают включить обратно; force-merge hot-индексов (locks + I/O storm).