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


(Denis Lamanov) #1

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

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

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


(Igor Motov) #2

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


(Denis Lamanov) #3

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


(Igor Motov) #4

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

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


(Denis Lamanov) #5

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


(Igor Motov) #6

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

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

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

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


(Denis Lamanov) #7

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

image


(Igor Motov) #8

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


(Denis Lamanov) #9

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


(Vladimir Dolzhenko) #10

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


(Denis Lamanov) #11

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


(Denis Lamanov) #12

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

image

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

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

Спасибо


(Vladimir Dolzhenko) #13

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


(Denis Lamanov) #14

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


(Vladimir Dolzhenko) #15

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

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


(Denis Lamanov) #16

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

image


(Igor Motov) #17

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


(system) #18

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