Почему мы используем несколько экземпляров сервера приложений на одном сервере - PullRequest
Новая
       21

Почему мы используем несколько экземпляров сервера приложений на одном сервере

14 голосов
/ 31 декабря 2010

Я думаю, что есть веская причина, но я не понимаю, почему иногда мы помещаем, например, 5 экземпляров, имеющих одинаковые веб-приложения, на одном физическом сервере.

Это как-то связано с оптимизацией длямногопроцессорная архитектура?Максимально допустимый предел памяти для JVM или что-то еще?

Ответы [ 5 ]

17 голосов
/ 31 декабря 2010

Хммм ... Через долгое время я снова вижу этот вопрос:)

Ну, несколько экземпляров JVM на одной машине решают множество проблем. Прежде всего, давайте посмотрим правде в глаза: хотя JDK 1.7 входит в картину, многие устаревшие приложения были разработаны с использованием JDK 1.3 или 1.4 или 1.5. И все же большая часть JDK поделена между ними.

Теперь к вашему вопросу:

Исторически сложилось, что есть три основные проблемы, которые системные архитекторы решали путем развертывания нескольких JVM в одной коробке:

  1. Garbage collection inefficiencies: По мере увеличения размеров кучи циклы сбора мусора - особенно для крупных сборок - имели тенденцию приводить к значительным задержкам в обработке благодаря однопоточному ГХ. Множество JVM борются с этим, разрешая в целом меньшие размеры кучи и обеспечивая некоторую степень параллелизма во время циклов GC (например, с четырьмя узлами, когда один входит в GC, у вас все еще есть три других, активно обрабатывающих).

  2. Resource utilization: Старые JVM не могли эффективно масштабироваться после четырех процессоров или около того. Ответ? Запустите отдельную JVM для каждых 2 процессоров в коробке (пробег, конечно, может варьироваться в зависимости от приложения).

  3. 64-bit issues: Старые JVM не могли выделить размеры кучи сверх 32-битного максимума. Опять же, несколько JVM позволяют максимизировать использование ресурсов.

  4. Availability: Одна из последних причин, по которой люди иногда запускают несколько JVM на одном компьютере, - это доступность. Хотя верно, что эта практика не устраняет сбои оборудования, она устраняет сбои в одном экземпляре сервера приложений.

Взято из (http://www.theserverside.com/discussions/thread.tss?thread_id=20044)

В основном я видел weblogic. Вот ссылка для дальнейшего чтения:

http://download.oracle.com/docs/cd/E13222_01/wls/docs92/perform/WLSTuning.html#wp1104298

Надеюсь, это поможет вам.

6 голосов
/ 31 декабря 2010

Полагаю, вы имеете в виду кластеризацию приложений.

AFAIK, у JVM, порожденного действительно большим размером кучи, есть проблемы, когда дело доходит до сбора мусора, хотя я уверен, что играя с алгоритмом GC и параметрами , вы можете снизить ущерб до минимума. Кроме того, кластерные приложения не имеют единой точки отказа. Если один узел выходит из строя, остальные узлы могут продолжать обслуживать клиентов. Это одна из причин, по которой «архитектуры на основе сообщений» хорошо подходят для масштабируемости. Каждый запрос сопоставляется с сообщением, которое затем может быть получено любым узлом в кластере.

Еще один момент - одновременное обслуживание нескольких запросов, если, к сожалению, ваше приложение использует разумно синхронизированное ключевое слово. В настоящее время у нас есть унаследованное приложение, которое имеет много общего состояния (к сожалению), и, следовательно, параллельная обработка запросов выполняется путем запуска около 20 процессов JVM с центральным диспетчерским модулем, который выполняет всю диспетчерскую работу. ; -)

2 голосов
/ 31 декабря 2010

Я бы посоветовал вам использовать как минимум JVM на регион NUMA. Если одна JVM использует более одного региона NUMA (часто один процессор), производительность может значительно снизиться из-за значительного увеличения стоимости доступа к основной памяти другого процессора.

Кроме того, использование нескольких серверов может позволить вам

  • используйте разные версии java или сервер приложений.
  • изолировать различные приложения, которые могут мешать (они не должны, но могут)
  • ограничение времени приостановки GC между службами.

РЕДАКТИРОВАТЬ: Это может быть историческим. Возможно, в прошлом было несколько причин иметь отдельные JVM, но поскольку вы не знаете, какими они были, вы не знаете, применяются ли они до сих пор, и может быть проще оставить все как есть.

1 голос
/ 31 декабря 2010

Дополнительной причиной для использования экземпляра mutliple является удобство обслуживания.

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

0 голосов
/ 08 марта 2015

Предположим, у вас средний хост конфигурации и установлен один экземпляр сервера веб / приложений. Теперь ваше приложение становится все популярнее, а количество просмотров увеличивается в 2 раза. Что ты сейчас делаешь?

Добавьте еще один физический сервер такой же конфигурации, установите приложение и распределите нагрузку на эти два хоста.

Это не конец жизни для вашего приложения. Ваше приложение будет становиться все более популярным, и, следовательно, его необходимо расширять. Какой будет ваша стратегия?

  • продолжайте добавлять больше хостов той же конфигурации
  • купите более мощный компьютер, на котором вы сможете создавать больше логических серверов приложений

Какой вариант вы пойдете далеко?

Вы проведете анализ затрат, который будет включать такие факторы, как фактическая стоимость оборудования, стоимость управления этими серверами (стоимость электроэнергии, занимаемое пространство в центре обработки данных) и т. Д.

Судя по всему, решение не очень простое. И в большинстве случаев выгоднее иметь более мощную машину.

...