Segments count и Heap size

Всем привет!

Ребята, на данный момент мы бьем индексы по дням и у нас получилось около 2000-2500 индексов.
На машине 64 Гб ОЗУ, из них 31 Гб выделен под Heap. Данных у нас уже 13 Тб.
На версии 2.4.1 ElasticSearch уже начинал умирать и часто запускал GC.
После обновления до 5.0 он умирает уже после 15 минут запуска и судя по графику дело в количестве segments - их около 30 000.

Правильно ли я понимаю что, что чем больше segments, тем большее потребляется Heap и нам нужно произвести optimize или forcemerge для индексов?

Можно ли временно переместить папки с индексами чтобы отключить их?

Спасибо

Привет, папки с индексами можно не перемещать, достаточно закрыть "ненужные" индексы. Сегментов действительно много, но надо смотреть что показывает статистика по ноде:

и хороший коммент про минусы закрытия индексов:

Спасибо.

Сейчас хотим по очереди оптимизировать/мёржить индексы, какие значения
index.merge.scheduler.max_thread_count
index.merge.policy.segments_per_tier
мне выставить чтобы использовать, допустим, 24 потока?

Можно попробовать оптимизировать до 1 сегмента часть старых и посмотреть на что это повлияет, сделать можно через forcemerge API.

Другой вариант: делать меньше индексов и шардов (сколько их сейчас на индекс?), потому что, на индекс получается не так уж и много сегментов (30k/2,5k=12 сегментов) и, вообще, индексы небольшие (примерно по 5GB, их можно увеличить до 30-50GB, а если нет сети и в старые не пишется и еще больше, повлияет только на скорость восстановления после сбоя или некорректного перезапуска кластера).

Сейчас 1 шарда на индекс.

делать меньше индексов

Бить по месяцам?

У нас на каждый тип лога пишет свой индекс и все это еще и по дням. Таким образом размеры индексов не равномерны - есть тип лога индекс которого за день за последний месяц 50-95 Гб.
В старые индексы не пишется. Нода одна.

Как сейчас максимально можно увеличить скорость мёржинга?

Спасибо

Про merge врядли что-то подскажу, может кто-то из модераторов или разработчиков сможет сказать именно по 5-ке, они постепенно выпиливали все настройки и что осталось - непонятно.

Подброшу еще одну возможность выиграть по памяти: добавлять памяти на сервер и разворачивать еще одну дата-ноду (либо сделать на каждую дата-ноду по 24-26GB памяти (48-52 из 64) и пожертвовать памятью ОС и файл-кешем, при этом желательно не влезать в swap, vm.swappiness = 1) на этом же сервере, но с хранением данных в другой директории. Ограничение: позволяет ли сервер по диску и CPU это сделать или нет? У нас работает от 1 до 3 инстансов на каждом сервере кластера (но у нас машины это позволяют).

Я думаю, прежде чем принимать какие-то меры, надо разобраться в чем собственно проблема. 30000 сегментов на 2000 шард - это вполне нормально. С другой стороны, если у вас только одна нода в кластере, то 2000 шард - это перебор.

Вы не могли бы прислать выводы node stats и node info? Из них должно быть более ясно куда память уходит.

Добрый день, Игорь

Сейчас подключил половину индексов и все они открыты

node info: https://yadi.sk/i/OWE1IOxcyRTro
node stats: https://yadi.sk/i/4OwbyGZuyRTs6

Спасибо

Забыл упомянуть: на каждый тип лога у нас создан и обновляется алиас по маске: logtype*

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

  1. Увеличить количество памяти добавлением еще одной или двух нод. Это самый простой способ.

  2. Перейти на недельные или даже месячные индексы. Это уменьшить количество шард и таким образом количество сегментов.

  3. Используя force merge сократить количество сегментов в старых шардах до одного сегмента на шарду. Процесс можно автоматизировать с помощью программы curator, который добавить в cron и запускать каждую ночь на только что созданном индексе.

  4. Выкинуть из индекса ненужные поля (особенно поля с большим количеством уникальных значений)

Спасибо, Игорь

Видимо реализуем первые 3 пункта.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.