Настройка для скорости индексирования

Массовые запросы обеспечат гораздо лучшую производительность, чем запросы индексирования отдельных документов. Для определения оптимального размера массового запроса необходимо выполнить бенчмаркинг на одном узле с одним фрагментом. Сначала попробуйте проиндексировать 100 документов одновременно, затем 200, затем 400 и т.д., удваивая количество документов в каждом массовом запросе при каждом запуске бенчмарка. Когда скорость индексирования начнёт стабилизироваться, вы поймёте, что достигли оптимального размера массового запроса для ваших данных. В случае равенства результатов лучше ошибиться в сторону меньшего, а не большего количества документов. Следите за тем, чтобы слишком большие массовые запросы не создавали чрезмерной нагрузки на кластер в случае одновременной отправки многих из них, поэтому рекомендуется избегать запросов размером более нескольких десятков мегабайт, даже если более крупные запросы кажутся более эффективными.

Один поток, отправляющий массовые запросы, вряд ли сможет полностью использовать возможности индексирования кластера Elasticsearch. Для использования всех ресурсов кластера необходимо отправлять данные из нескольких потоков или процессов. Кроме повышения эффективности использования ресурсов кластера, это поможет снизить затраты на каждый fsync.

Следите за кодами ответов TOO_MANY_REQUESTS (429) (EsRejectedExecutionException с клиентом Java), которые Elasticsearch использует для сигнализации о том, что он не может справиться с текущей скоростью индексирования. В случае возникновения проблемы следует на некоторое время приостановить индексирование, а затем повторить попытку, желательно с рандомизированной экспоненциальной задержкой.

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

Операция, которая делает изменения видимыми для поиска (называемая обновлением обновления), затратная. Частое её вызов при активной индексации может ухудшить скорость индексирования.

По умолчанию Elasticsearch периодически обновляет индексы каждую секунду, но только для индексов, которые получили хотя бы один запрос поиска за последние 30 секунд.

Это оптимальная конфигурация, если у вас нет или очень мало поискового трафика (например, менее одного запроса поиска каждые 5 минут) и вы хотите оптимизировать скорость индексирования. Это поведение призвано автоматически оптимизировать массовую индексацию по умолчанию, когда поисковых запросов нет. Чтобы отказаться от этого поведения, явно установите интервал обновления.

С другой стороны, если ваш индекс регулярно получает поисковые запросы, по умолчанию Elasticsearch будет обновлять ваш индекс каждую секунду. Если вы можете позволить себе увеличить время между индексированием документа и его отображением, увеличение index.refresh_interval до большего значения, например, 30s, может улучшить скорость индексирования.

Если у вас большой объём данных, который вы хотите загрузить в Elasticsearch сразу, то может быть полезно установить index.number_of_replicas на 0 для ускорения индексирования. Отсутствие реплик означает, что потеря одного узла может привести к потере данных, поэтому важно, чтобы данные хранились где-то ещё, чтобы эту начальную загрузку можно было повторить в случае проблемы. После завершения начальной загрузки вы можете установить index.number_of_replicas обратно на исходное значение.

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

Вы должны убедиться, что операционная система не подкачивает процесс java, отключив подкачку.

Кэш файловой системы будет использоваться для буферизации операций ввода-вывода. Вы должны убедиться, что файловому кэшу предоставлено как минимум половина памяти машины, на которой работает Elasticsearch.

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

Если индексирование ограничено вводом-выводом, рассмотрите возможность увеличения размера кэша файловой системы (см. выше) или использования более быстрого хранилища. Elasticsearch обычно создаёт отдельные файлы с последовательными записями. Однако индексирование включает запись нескольких файлов одновременно, а также смесь случайного и последовательного чтения, поэтому SSD-накопители обычно работают лучше, чем жёсткие диски.

Разбейте ваш индекс по нескольким SSD-накопителям, настроив массив RAID 0. Помните, что это увеличит риск сбоя, так как выход из строя любого одного SSD-накопителя уничтожит индекс. Однако это обычно правильный компромисс: оптимизируйте отдельные фрагменты для максимальной производительности, а затем добавьте реплики на разных узлах для обеспечения резервирования в случае отказа любого узла. Вы также можете использовать создание и восстановление снимков для резервного копирования индекса для дополнительной страховки.

Прямое (локальное) хранилище обычно работает лучше, чем удалённое, так как его проще правильно настроить и оно избегает накладных расходов на межсетевое взаимодействие.

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

Если ваш узел выполняет только интенсивную индексацию, убедитесь, что indices.memory.index_buffer_size достаточно велик, чтобы обеспечить не более 512 МБ буфера индексирования на каждый фрагмент, выполняющий интенсивную индексацию (за пределами этого значения производительность индексирования обычно не улучшается). Elasticsearch использует это значение (процент от кучи Java или абсолютный размер в байтах) в качестве общего буфера для всех активных фрагментов. Очень активные фрагменты естественно будут использовать этот буфер больше, чем фрагменты, выполняющие лёгкую индексацию.

По умолчанию установлено значение 10%, которого часто достаточно: например, если вы предоставите JVM 10 ГБ памяти, она выделит 1 ГБ для буфера индекса, чего достаточно для размещения двух фрагментов, которые активно индексируются.

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

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

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