Как улучшить производительность перколятора в ElasticSearch?

Question

Резюме

Нам необходимо увеличить производительность перколятора (пропускную способность).

Скорее всего, подход масштабируется на несколько серверов.

Вопросы

Как сделать масштабирование верно?

1) Увеличилось бы количество осколков в базовом индексе, позволяя параллельно запускать запросы на перколяцию?

2) Сколько памяти требуется ElasticSearch серверу, если он выполняет перколяцию?

Лучше иметь 2 сервера с 4 ГБ оперативной памяти или один сервер с 16 ГБ оперативной памяти?

3) Имеет ли SSD значительную помощь в производительности перколятора, или лучше увеличить ОЗУ и/или количество узлов?

Наша текущая ситуация

У нас есть 200000 запросов (поиск работы предупреждений) в индексе работы. Мы можем запускать 4 параллельные очереди, которые вызывают перколятор. Каждый запрос может просачиваться партию 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] [Клетус Kasady] [Новости] [3] осколок мульти отказ перколит org.elasticsearch.action.NoShardAvailableActionException: [работа] [3] нуля

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

Похожие: How to Optimize elasticsearch percolator index Memory Performance

Answer 1

Ответы

Как сделать масштабирование правильно?

Q: 1) Увеличилось бы количество осколков в базовом индексе, позволяя параллельно запускать запросы на перколяцию?

A: No. Sharding действительно полезно при создании кластера. Дополнительные осколки в одном экземпляре могут фактически ухудшить производительность. В общем случае количество осколков должно быть равно количеству узлов для оптимальной производительности.

Вопрос: 2) Сколько памяти требуется ElasticSearch серверу, только если он выполняет перколяцию?

Лучше иметь 2 сервера с 4 ГБ оперативной памяти или один сервер с 16 ГБ оперативной памяти?

A: Показатели перколятора полностью находятся в памяти, поэтому ответ является МНОГО. Он полностью зависит от размера вашего индекса. По моему опыту 200 000 поисков потребовали бы 50 МБ индекса. В памяти этот индекс будет занимать около 500 МБ памяти кучи. Поэтому 4 ГБ ОЗУ должно быть достаточно, если это все, что вы используете. Я бы предложил больше узлов в вашем случае. Однако по мере роста размера вашего индекса вам нужно будет добавить оперативную память.

Q: 3) Имеет ли SSD значительную помощь в производительности перколятора, или лучше увеличить ОЗУ и/или количество узлов?

A: Я сомневаюсь. Как я уже говорил, перколяторы хранятся в памяти, поэтому производительность диска не является узким местом.

РЕДАКТИРОВАТЬ: Не верьте моему слову на эти оценки памяти. Проверьте site plugins на основном сайте ES. Я нашел Big Desk особенно полезным для просмотра счетчиков производительности для масштабирования и планирования. Это должно дать вам более ценную информацию об оценке ваших конкретных требований.

EDIT в ответ на комментарий от @DennisGorelik ниже:

Я получил эти цифры чисто из наблюдений, но при отражении они имеют смысл.

1. 200K запросов к 50MB на диске: Это соотношение означает, что средний запрос занимает 250 байт при сериализованная на диск.
2. 50MB индекс до 500 МБ в куче: Вместо сериализованных объектов на диске мы имеем дело с памятью в Java-объектах. Подумайте о десериализации XML (или любого формата данных на самом деле), вы обычно получаете 10-кратные объекты в памяти.