Как сбалансировать elasticsearch (java) на очень мощной машине?

Вариант 4: Запуск нескольких инсансов / узлов на одной машине.

Это похоже на варианты 2 и 3, за исключением того, что они проще, потому что нет виртуализации или контейнеризации. Все это изначально работает на хосте.

Вот список предостережений и рекомендаций при этом (из Вот).

• Максимальный размер кучи для каждого экземпляра узла должен быть <32 ГБ. Это связано с тем, что размер кучи выше 32 ГБ на самом деле будет контрпродуктивным, поскольку JVM перестанет сжимать указатели.
• Оставьте 50% памяти для кэша файловой системы для Lucene.
• Хотя у вас может быть достаточно оперативной памяти для запуска нескольких экземпляров на одном компьютере, проверьте, достаточно ли у вас ЦП / вычислительной мощности.
• Вы также захотите убедиться, что несколько экземпляров узлов не конкурируют за дисковое пространство или дисковый ввод-вывод. Наша рекомендация - дать всем узлам на машине raid0 с большим количеством дисков под ним или выделенный диск на узел.
• Нижняя процессоры настройка соответственно. Каждый узел ES определяет количество ядер, доступных на машине (не зная о других присутствующих узлах). Имея несколько узлов на одной машине, каждый узел может думать, что у него есть выделенный доступ ко всем ядрам на машине (это может быть проблематично, поскольку размеры пула потоков по умолчанию определяются из этого). Таким образом, вы захотите явно указать количество ядер, доступных через настройку процессоров, чтобы это не привело к чрезмерному выделению пулов потоков. Например, примерно # of cores / # of nodes может стать хорошим началом настройки для каждого узла.
• Имейте в виду, что наличие нескольких узлов также означает, что сетевые соединения, дескрипторы файлов ОС, ограничения файлов mmap также будут совместно использоваться между узлами, поэтому вы захотите убедиться, что пропускной способности достаточно, а ограничения установлены достаточно высокими для размещения узлов. .
• Чем больше узлов у вас на машине, тем больше узлов выйдет из строя сразу, если выйдет из строя один сервер. Кроме того, вы должны убедиться, что не все копии шарда находятся на одном компьютере. Вы можете предотвратить это settingcluster.routing.allocation.same_shard.host к истине. Видеть Вот для подробностей.

• Чтобы гарантировать стабильность кластера, каждый выделенный экземпляр главного узла должен быть на своем собственном компьютере (конечно, это может быть машина гораздо меньшего размера, например, 4 Гб ОЗУ для начала). Помните, что наличие нескольких узлов на машине означает дополнительную сложность в управлении ( например, отслеживание различных портов, файлов конфигурации и т. д.). Хороший способ управлять конфигурацией для нескольких экземпляров - создать отдельный файл elasticsearch.yml для каждого экземпляра, например. вы можете пройти в -Des.config параметр, чтобы указать файл yml для каждого экземпляра при запуске:

  $ bin/elasticsearch -Des.config=$ES_HOME/config/elasticsearch.1.yml
  $ bin/elasticsearch -Des.config=$ES_HOME/config/elasticsearch.2.yml
  

• Каждый yml будет указывать на одно и то же имя кластера.
• Будет полезно указать значимые имена узлов
• Используйте явные номера портов для каждого узла, чтобы они были предсказуемыми (например, http.port и transport.tcp.port).
• У каждого узла должен быть свой path.* каталоги (например, path.data, path.log, path.work, path.plugins), поэтому на узлах не будет конфликтующих местоположений папок для данных, плагинов, журналов и т. д.

Как упоминалось в другом ответе, вы не хотите использовать более 32 ГБ на экземпляр, а также не хотите использовать всю свою оперативную память для кучи Java. Скорее, лучше оставить не менее 50% ее для кэширования файловой системы ОС.

Есть действительно хорошее объяснение, почему это так в этот статья в блоге от Elastic.

2 и 3 - лучшие варианты, потому что в документации предлагается 32 ГБ максимальной выделенной памяти для каждого узла.