Есть некие основания предполагать, что начиная с 6.4.0 у ElasticSearch есть утечка файловых дескрипторов. Тех самых, лимит на которые установлен в скриптах запуска в 65536
И вот почему: у нас неправильно построенный кластер с кучей индексов на 2-х машинах и большим количеством RAM. И всё прекрасно работает и не тормозит. Периодически ручками удаляем старые индексы. Месяца 2 назад обновились с 6.3.0 на 6.4.0
Этот кластер живёт уже 2 года. Сейчас у нас около 3700 шард.
И вот, неделю назад на одном севере падает нода и в логах:
max file descriptors for elasticsearch process is too low...
К сожалению мы не мониторили этот параметр и мониториг в Кибане тоже и не могу сказать как быстро и после чего он стал расти.
После того как увеличил значение в скриптах systemd в 10 раз до 655360 всё запустилось, заодно обновил до 6.4.2
Начал мониторить этот параметр и, о ужас, я был удивлен, что после часа работы на каждой ноде процессом Эластика быо открыто около 80 000 файловых дескрипторов. Мониториг показывает, что их количество постепенно растёт, хотя количество индексов - нет. То есть ещё пару дней назад только подходило к лимиту в 65536 и тут сразу 80 000
Могу предоставить всю необходимую информацию.
Извиняюсь, это на каждую дата-ноду. Всего 1603 индекса, 99% из них без реплик. На каждый индекс 4 шарды. Merge практически не помогает снизить количество fd.
89310/15590 = 5.7 файлов на сегмент - это вполне нормально
15590/3700=4.2 сегментов на шарду - это даже мало
Другими словами, для вашего количества шард, все выглядит вполне нормально. Другой вопрос в том, зачем вам такое огромное количество шард, если у вас всего 2 ноды?
Хороший вопрос) В ближайшие 2 месяца мы планируем резко увеличить количество нод до 7. Но самое интересное, что и в данной конфигурации нет проблем с производительностью. Разве что напрягает отсутствие реплик для всех индексов. Кстати, во график роста fd из Графаны:
Много индексов не то, что маленьких, а крохотных (килобайты или десятки мегабайт). При этом на каждый индекс создаётся экземпляр Lucene со всеми file halder-ами и прочими накладными расходами. Стоит пересмотреть подход к таким индексам в сторону их укрупнения, или вообще закрыть, если они не нужны.
Будем считать, что такое количество файловых дескрипторов это нормально для данного случая, особенно учитывая, что лимит поднят до довольно высокого значения. Но в мониторинг поставил
Ребята, есть новости: количество индексов не увеличивалось, а количество fd росло, что заставило меня заняться поиском причины. Отсортировал папки с индексами по количеству файлов. И ужас:
Оказалось, что 2 индекса содержат файлов на несколько порядков больше. Сами же индесы занимают по 5 Мб. Их пишет другой отдел и выяснилось, что они делают update очень часто во время миграции. То есть эта куча файлов есть translog и его нужно как-то смёржить.
Пробовал делать этим 2-м индексам forcemerge и synced flush - не помогает, хотя, согласено документации(https://www.elastic.co/guide/en/elasticsearch/guide/current/dynamic-indices.html) должно помочь
Я бы порекомендовал уменьшить количество шард и индексов, вместо того, чтобы менять параметры лога транзакций и merge policy что, как правило, ни к чему хорошему в долгосрочной перспективе не приводит.
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.