Ребята, на данный момент мы бьем индексы по дням и у нас получилось около 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, а если нет сети и в старые не пишется и еще больше, повлияет только на скорость восстановления после сбоя или некорректного перезапуска кластера).
У нас на каждый тип лога пишет свой индекс и все это еще и по дням. Таким образом размеры индексов не равномерны - есть тип лога индекс которого за день за последний месяц 50-95 Гб.
В старые индексы не пишется. Нода одна.
Как сейчас максимально можно увеличить скорость мёржинга?
Про merge врядли что-то подскажу, может кто-то из модераторов или разработчиков сможет сказать именно по 5-ке, они постепенно выпиливали все настройки и что осталось - непонятно.
Подброшу еще одну возможность выиграть по памяти: добавлять памяти на сервер и разворачивать еще одну дата-ноду (либо сделать на каждую дата-ноду по 24-26GB памяти (48-52 из 64) и пожертвовать памятью ОС и файл-кешем, при этом желательно не влезать в swap, vm.swappiness = 1) на этом же сервере, но с хранением данных в другой директории. Ограничение: позволяет ли сервер по диску и CPU это сделать или нет? У нас работает от 1 до 3 инстансов на каждом сервере кластера (но у нас машины это позволяют).
Я думаю, прежде чем принимать какие-то меры, надо разобраться в чем собственно проблема. 30000 сегментов на 2000 шард - это вполне нормально. С другой стороны, если у вас только одна нода в кластере, то 2000 шард - это перебор.
Вы не могли бы прислать выводы node stats и node info? Из них должно быть более ясно куда память уходит.
Посмотрели на статистику. Картина, похоже, такая получается: ежедневные индексы приводят к большому количеству шард, что в свою очередь приводит к большому количеству сегментов, и поскольку каждый сегмент это маленький инвертированный индекс для каждого поля, все это ведет к большому расходу памяти. Отсюда возможные решения:
Увеличить количество памяти добавлением еще одной или двух нод. Это самый простой способ.
Перейти на недельные или даже месячные индексы. Это уменьшить количество шард и таким образом количество сегментов.
Используя force merge сократить количество сегментов в старых шардах до одного сегмента на шарду. Процесс можно автоматизировать с помощью программы curator, который добавить в cron и запускать каждую ночь на только что созданном индексе.
Выкинуть из индекса ненужные поля (особенно поля с большим количеством уникальных значений)
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.