Я думаю, что есть веская причина, но я не понимаю, почему иногда мы помещаем, например, 5 экземпляров с теми же веб-приложениями на одном физическом сервере.
Это как-то связано с оптимизацией для многопроцессорной архитектуры? Максимальный допустимый предел для JVM или что-то еще?
Хммм... Через долгое время я снова вижу этот вопрос:)
Ну, несколько экземпляров JVM на одной машине решают много проблем. Прежде всего, давайте посмотрим правде в глаза: несмотря на то, что JDK 1.7 вступает в картину, многие старые приложения были разработаны с использованием JDK 1.3 или 1.4 или 1.5. И все же основной кусок JDK разделен между ними.
Теперь на ваш вопрос:
Исторически существует три основных вопроса, которые системные архитекторы рассмотрели путем развертывания нескольких JVM в одном окне:
Garbage collection inefficiencies: По мере роста размеров кучи, циклы сбора мусора, особенно для крупных коллекций, как правило, создают значительные задержки в обработке благодаря однопоточному GC. Несколько JVM сражаются с этим, разрешая меньшие размеры кучи вообще и позволяя некоторую меру concurrency во время циклов GC (например, с четырьмя узлами, когда один идет в GC, у вас все еще есть три других, активно обрабатывающих).
Resource utilization: Старые JVM не смогли эффективно масштабировать четыре процессора или около того. Ответ? Запустите отдельную JVM для каждых 2 ЦП в поле (пробег может варьироваться в зависимости от приложения, конечно).
64-bit issues: Старые JVM не смогли выделить размеры кучи за 32-битным максимумом. Опять же, несколько JVM позволяют максимизировать использование ресурсов.
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
Надеюсь, это поможет вам.
Я предполагаю, что вы имеете в виду кластеризацию приложений.
AFAIK, JVM, созданный с действительно большим размером кучи, имеет проблемы, когда дело доходит до сборки мусора, хотя я уверен, что играет с алгоритмом GC и параметрами вы можете свести повреждение к минимуму. Кроме того, кластеризованные приложения не имеют единой точки отказа. Если один node опускается, остальные узлы могут обслуживать клиентов. Это одна из причин, почему "архитектуры на основе сообщений" хорошо подходят для масштабируемости. Каждый запрос сопоставляется с сообщением, которое затем может быть собрано любым node в кластере.
Другим моментом было бы одновременное обслуживание нескольких запросов, если ваше приложение, к сожалению, использует синхронизированное ключевое слово разумно. В настоящее время у нас есть устаревшее приложение, которое имеет много общего состояния (к сожалению), и, следовательно, одновременная обработка запросов выполняется путем создания около 20 процессов JVM с центральной диспетчерской единицей, которая выполняет всю диспетчерскую работу.; -)
Я предлагаю вам использовать не менее JVM в каждом регионе NUMA. Если в одном JVM используется более одного региона NUMA (часто один процессор), производительность может значительно ухудшиться из-за значительного увеличения стоимости доступа к основной памяти другого процессора.
Кроме того, использование нескольких серверов позволяет вам
EDIT: Это может быть историческое. Возможно, в прошлом было несколько причин иметь отдельные JVM, но, поскольку вы не знаете, кем они были, вы не знаете, продолжают ли они применяться, и может быть проще оставить вещи такими, какие они есть.
Дополнительной причиной использования экземпляра mutliple является работоспособность.
Например, если у вас несколько разных приложений для нескольких клиентов, а затем отдельные экземпляры приложений для каждого приложения могут немного облегчить жизнь, когда вам придется перезагружать сервер приложений во время выпуска.
Предположим, у вас есть средний хост конфигурации и установлен один экземпляр сервера веб-приложений. Теперь ваше приложение становится более популярным, а количество обращений увеличивается в 2 раза. Что вы теперь делаете?
Добавьте еще один физический сервер с одинаковой конфигурацией и установите приложение и загрузите баланс этих двух хостов.
Это не конец жизни для вашего приложения. Ваше приложение будет продолжать становиться все более популярным и, следовательно, необходимостью его масштабировать. Какова будет ваша стратегия?
Какой вариант вы пойдете далеко?
Вы проведете анализ затрат, который будет включать в себя такие факторы, как фактическая стоимость оборудования, стоимость управления этими серверами (стоимость электроэнергии, занимаемая площадь в центре обработки данных) и т.д.
По-видимому, дело в том, что решение не так просто. И в большинстве случаев более экономичным является наличие более мощной машины.