Elasticsearch 2.2.0 Высокая загрузка ЦП и высокие IOPS на StressTest

Недавно я обновил свой ES с версии 1.5.2 до версии 2.2.0 и добавил к нему Shield. Я пытаюсь выполнить стресс-тест, используя Locust, который загружает кластер данными (приложением nodejs). Я получил странные результаты по сравнению с предыдущим стресс-тестом (на 1.5.2):

        1.5.2 ver             2.2.0 ver

cpu     50% avg, 90% peak     87% avg, 96% peak

IOPS    30 avg, 300 peak      800 avg, 1122 peak

Почему ES так усердно работает?

Еще одна странная вещь, которую я не могу понять, и я думаю, что она связана с вышеизложенным, это вывод в заголовке плагина. Ранее (1.5.2) я видел, как индексы хранят данные как:

имя_индекса

размер: 10,3 ГБ (20,6 ГБ)

документы: 17 073 010 (17 073 010)

Но теперь (2.2.0) это так:

имя_индекса

размер: 13,7 ГБ (29,3 ГБ)

документы: 10 217 220 (20 434 440)

Как видите, в ES 2.2.0 данные удваиваются, почему это происходит? Что-то не так с моей конфигурацией v2.2.0 ES?


elasticsearch elasticsearch-plugin
person Reshef    schedule 02.03.2016    source источник
comment
Возможно, в нем лучше распределены задачи. Высокие показатели не всегда плохо. Попробуйте протестировать его с помощью другого фреймворка, такого как Tsung, для сравнения. >dstoolbox.blogspot.de/2015/09/)   -  person eliasah    schedule 02.03.2016
comment
@eliasah- да, но почему заголовок плагина возвращает такие странные показатели?   -  person Reshef    schedule 02.03.2016
comment
Вы отключили подкачку для примера? постарайтесь убедиться, что у вас есть точная конфигурация для обоих.   -  person eliasah    schedule 02.03.2016
comment
В Lucene может быть утечка памяти, которая может быть причиной этого   -  person eliasah    schedule 02.03.2016
comment
Конфигурации в обеих средах одинаковы. Как я могу указать на утечку памяти?   -  person Reshef    schedule 02.03.2016
comment
выявление утечек памяти — довольно сложный и долгий процесс, если вы никогда раньше этого не делали. Вы можете начать с просмотра JVM с Profile и все начинается оттуда. Будет много документации для чтения и т.д.   -  person eliasah    schedule 02.03.2016

Ответы (1)


arrow_upward
4
arrow_downward

Я получил ответ на форуме сообщества Elasticsearch.

Ответ Закари Тонга:

Соглашаясь с замечаниями, поднятыми @rusty: значения Doc по умолчанию добавляют некоторые накладные расходы на ЦП / ввод-вывод и немного больше места на диске, теперь транслог сбрасывается при каждом действии (вместо каждых 5 секунд) и проблема с репликой.

Кроме того, произошли изменения на уровне Lucene. Входящий блок текста, но tl;dr заключается в том, что Lucene идентифицирует простаивающие ресурсы и использует их, заставляя использование ресурсов выглядеть выше, когда на самом деле он просто выполняет работу быстрее.

Итак, в Elasticsearch 1.x мы принудительно затормозили процесс слияния сегментов Lucene, чтобы он не перенасыщал ваши узлы/кластер.

Проблема в том, что строгий порог почти никогда не бывает правильным ответом. Если вы интенсивно индексируете, вам часто нужно увеличить порог, чтобы позволить Lucene использовать весь ваш ЦП и дисковый ввод-вывод. Если вы мало индексируете, вы, вероятно, захотите снизить порог. Но вы также хотите, чтобы он мог превысить лимит одноразовых слияний, когда ваш кластер относительно простаивает.

В Lucene 5.x (используется в ES 2.0+) они добавили новый стиль регулирования слияния, который отслеживает, насколько активен индекс, и автоматически регулирует пороговое значение регулирования (см. https://issues.apache.org/jira/browse/LUCENE-6119, https://github.com/elastic/elasticsearch/pull/9243 и https://github.com/elastic/elasticsearch/pull/9145).

На практике это означает, что индексирование в ES 2.0+ происходит быстрее, потому что сегменты могут объединяться так быстро, как только может обработать ваш кластер, без перенасыщения вашего кластера. Но это также означает, что ваш кластер будет с удовольствием использовать любые простаивающие ресурсы, поэтому вы видите большее использование ресурсов.

По сути, Lucene определила, что эти ресурсы не используются... поэтому заставила их работать, чтобы быстрее завершить задачу.

person Reshef    schedule 02.03.2016
comment
Интересно, может быть, вы можете перечислить некоторые основные моменты этой темы здесь, на всякий случай. - person Val; 02.03.2016