Утечка файловых дескрипторов

Добрый день!)

Есть некие основания предполагать, что начиная с 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 :frowning:
Могу предоставить всю необходимую информацию.

Заранее спасибо

Давайте начнем с вывода GET /_nodes/stats/indices,process

По лимиту не поместился Json в сыром виде здесь, залил: https://pastebin.com/nr8FbjXD

Сейчас у нас около 3700 шард.

Это на весь кластер? Включая праймари и копии?

Извиняюсь, это на каждую дата-ноду. Всего 1603 индекса, 99% из них без реплик. На каждый индекс 4 шарды. Merge практически не помогает снизить количество fd.

Ну арифметика тут такая:

    "segments": {
      "count": 15590,
...
    "open_file_descriptors": 89310,

89310/15590 = 5.7 файлов на сегмент - это вполне нормально
15590/3700=4.2 сегментов на шарду - это даже мало

Другими словами, для вашего количества шард, все выглядит вполне нормально. Другой вопрос в том, зачем вам такое огромное количество шард, если у вас всего 2 ноды?

Хороший вопрос) В ближайшие 2 месяца мы планируем резко увеличить количество нод до 7. Но самое интересное, что и в данной конфигурации нет проблем с производительностью. Разве что напрягает отсутствие реплик для всех индексов. Кстати, во график роста fd из Графаны:

image

У вас, судя по всему, очень маленькие индексы - не очень понятно зачем им нужны 4 шарды.

Размеры индексов, количество документов (Docs (Size) x Count):
https://pastebin.com/BL2zeY6M

Много индексов не то, что маленьких, а крохотных (килобайты или десятки мегабайт). При этом на каждый индекс создаётся экземпляр Lucene со всеми file halder-ами и прочими накладными расходами. Стоит пересмотреть подход к таким индексам в сторону их укрупнения, или вообще закрыть, если они не нужны.

Будем считать, что такое количество файловых дескрипторов это нормально для данного случая, особенно учитывая, что лимит поднят до довольно высокого значения. Но в мониторинг поставил

Ребята, есть новости: количество индексов не увеличивалось, а количество fd росло, что заставило меня заняться поиском причины. Отсортировал папки с индексами по количеству файлов. И ужас:

image

Оказалось, что 2 индекса содержат файлов на несколько порядков больше. Сами же индесы занимают по 5 Мб. Их пишет другой отдел и выяснилось, что они делают update очень часто во время миграции. То есть эта куча файлов есть translog и его нужно как-то смёржить.
Пробовал делать этим 2-м индексам forcemerge и synced flush - не помогает, хотя, согласено документации(https://www.elastic.co/guide/en/elasticsearch/guide/current/dynamic-indices.html) должно помочь

Есть какие-то идеи что делать?

Спасибо

Можно получить детали внутри папок с индексами т.е сколько fd к каждому файлу ? там две большие части - index и translog

Выставил для этих индексов:
"index.translog.retention.age": "1h"
Помогло. Кстати, как выставить 15 минут: "15m"?

да 15минут это 15m,

не нашёл лучшей документации

1 Like

Всем спасибо. Картина получилась сейчас такая

image

Я бы порекомендовал уменьшить количество шард и индексов, вместо того, чтобы менять параметры лога транзакций и merge policy что, как правило, ни к чему хорошему в долгосрочной перспективе не приводит.

1 Like

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