Как улучшить производительность перколятора в ElasticSearch?
Резюме
Нам нужно увеличить производительность перколятора (пропускную способность).
Наиболее вероятный подход - масштабирование до нескольких серверов.
Вопросы
Как правильно сделать масштабирование?
1) Позволит ли увеличение количества сегментов в базовом индексе параллельно выполнять больше запросов на фильтрацию?
2) Сколько памяти требуется серверу ElasticSearch, если он выполняет только фильтрацию?
Лучше иметь 2 сервера с 4 ГБ ОЗУ или один сервер с 16 ГБ ОЗУ?
3) Имеет ли SSD значительную поддержку производительности перколятора, или лучше увеличить ОЗУ и / или количество узлов?
Наша текущая ситуация
У нас есть 200000 запросов (оповещений о поиске работы) в нашем индексе работы. Мы можем запустить 4 параллельные очереди, которые вызывают percolator. Каждый запрос может предоставить пакет из 50 заданий за 35 секунд, поэтому мы можем предоставить следующие сведения:
4 очереди * 50 заданий в пакете / 35 секунд * 60 секунд в минуту = 343 задания в минуту
Нам нужно больше.
В нашем индексе вакансий есть 4 сегмента, и мы используем.percolator, сидящий поверх этого индекса вакансий.
Аппаратное обеспечение: сервер с 2 процессорами, всего 32 ядра. 32 ГБ ОЗУ. Мы выделили 8 ГБ оперативной памяти для ElasticSearch.
Когда перколятор работает, 4 очереди перколяции, о которых я упоминал выше, потребляют около 50% процессорного времени.
Когда мы попытались увеличить число параллельных перколяционных очередей с 4 до 6, загрузка ЦП подскочила до 75%+. Что еще хуже, перколятор начал давать сбой с NoShardAvailableActionException:
[2015-03-04 09:46: 22,221] [DEBUG] [action.percolate] [Cletus Kasady] [jobs] [3] Ошибка Shard multi percolate org.elasticsearch.action.NoShardAvailableActionException: [jobs][3] null
Эта ошибка говорит о том, что мы должны увеличить количество сегментов и в конечном итоге добавить выделенный сервер ElasticSearch (+ позднее увеличить количество узлов).
Похожие страницы: Как оптимизировать индекс эластичного поиска для перколятора
1 ответ
ответы
Как правильно сделать масштабирование?
Вопрос: 1) Позволит ли увеличение количества сегментов в базовом индексе параллельно выполнять больше запросов на фильтрацию?
A: Нет. Sharding действительно полезен только при создании кластера. Дополнительные осколки в одном экземпляре могут фактически ухудшить производительность. В общем случае количество сегментов должно равняться количеству узлов для оптимальной производительности.
Q: 2) Сколько памяти нужно серверу ElasticSearch, если он выполняет только фильтрацию?
Лучше иметь 2 сервера с 4 ГБ ОЗУ или один сервер с 16 ГБ ОЗУ?
A: Индексы перколятора полностью хранятся в памяти, поэтому ответ - МНОГО. Это полностью зависит от размера вашего индекса. По моему опыту, для 200 000 поисковых запросов потребуется индекс в 50 МБ. В памяти этот индекс будет занимать около 500 МБ динамической памяти. Поэтому 4 ГБ ОЗУ должно быть достаточно, если это все, что вы используете. Я бы предложил больше узлов в вашем случае. Однако по мере роста размера вашего индекса вам необходимо будет добавить ОЗУ.
В: 3) Будет ли использование SSD значимо помочь производительности перколятора, или лучше увеличить ОЗУ и / или количество узлов?
A: Я сомневаюсь в этом. Как я уже говорил, перколяторы находятся в памяти, поэтому производительность диска не является узким местом.
РЕДАКТИРОВАТЬ: Не верьте моим словам об этих оценках памяти. Проверьте плагины сайта на главном сайте ES. Я обнаружил, что Big Desk особенно полезен для просмотра счетчиков производительности в целях масштабирования и планирования. Это должно дать вам более ценную информацию по оценке ваших конкретных требований.
РЕДАКТИРОВАТЬ в ответ на комментарий от @DennisGorelik ниже:
Я получил эти цифры исключительно из наблюдения, но после размышлений они имеют смысл.
- 200K запросов к 50 МБ на диске: это соотношение означает, что средний запрос занимает 250 байт при сериализации на диск.
- От 50 МБ до 500 МБ в куче: вместо сериализованных объектов на диске, с которыми мы имеем дело в памяти Java-объектов. Подумайте о десериализации XML (или любого другого формата данных на самом деле), вы обычно получаете в 10 раз больше объектов в памяти.