#elasticsearch
#эластичный поиск
Вопрос:
У меня есть кластер эластичного поиска с 2 узлами, работающий на 2-ядерном процессоре с 8 ГБ оперативной памяти. Каждому узлу передан аргумент «ES_JAVA_OPTS=-Xms3g -Xmx3g». У меня есть 4 индекса, каждый из которых имеет 2 фрагмента и 1 реплику. Через 2 месяца он отключился. Проверил мониторинг экземпляра, не увидев никакого скачка процессора или памяти. На диске достаточно свободного места. Проверил журнал es. Единственное, что я вижу, это
[gc][2845340] overhead, spent [339ms] collecting in the last [1s]
Есть идеи, почему?
Ответ №1:
Когда сборщик мусора начинает сообщать, что он тратит ~ 30% времени на сбор, это обычно означает, что кучи больше недостаточно.
Вы должны немного увеличить кучу, пока GC не перестанет сообщать. Вы можете увеличить кучу до половины доступной памяти, но не более 30 ГБ
С этой целью измените настройку ниже и убедитесь, что она Xms всегда равна Xmx и никогда не превышает 30.
ES_JAVA_OPTS=-Xms4g -Xmx4g
Комментарии:
1. Спасибо за ответ. В экземпляре всего 8 ГБ оперативной памяти. Если я перейду на 4 ГБ для каждого узла, и у меня будет 2 узла. Закончится ли память, учитывая, что ОС зарезервирует некоторую память?
2. Хорошо, тогда проблема в том, что если у вас есть 8 ГБ оперативной памяти на экземпляре и два узла на этом экземпляре, тогда вы должны выделить только 2 ГБ на узел. Скорее всего, это причина, по которой вы наблюдаете увеличение сбора мусора, т. Е. Потому, что у вас мало кучи. При этом, как правило, запускать два узла в одном экземпляре — плохая идея, и они всегда будут конкурировать за ресурсы.