Несколько JVMs против сервера одного приложения

Я имею дело с системой, которая запускает приложение Java для каждого клиента в своей собственной JVM. У нас есть около полутора десятков выделенных серверов, которые теперь работают почти на 100 JVM, и наборы пользовательских сценариев для управления этими JVM. Эта настройка действительно показывает свой возраст на данный момент: управление тем, что многие JVM становятся кошмаром для мониторинга/управления, и мы постоянно занимаемся проблемами кучи. Мы хотели бы перейти к более современному подходу и просто запустить множество приложений на одном сервере приложений на физическую машину. Однако сохранение отдельных приложений имеет определенные преимущества с точки зрения изоляции (например, из-за ошибок памяти влияет только на одного клиента). Каждый стек программного обеспечения каждого пользователя имеет требования к памяти, которые сильно различаются.Несколько JVMs против сервера одного приложения

Мой вопрос: есть ли способ иметь лучшее из обоих миров здесь и запускать несколько приложений на одном JVM (сервере приложений) и поддерживать некоторый уровень изоляции? Или это просто современный жизненный факт, который вам нужно для управления требованиями к памяти набора приложений в наши дни? Существуют ли другие решения помимо сервера приложений или контейнера Java EE (например, Wildfly или Spring), которые я здесь отсутствует? Кажется, что эта система - это прорыв от другой эры!

источник

2014-10-01 Noky

Современный подход все чаще использует JVM для каждого приложения на виртуализированных хостах. Для масштаба, который вам нужен, я настоятельно рекомендую взглянуть на Cloud Foundry, чтобы отвлечь большую часть управления, о котором вы говорите. – chrylis

Как и комментарий chrylis, современный подход НЕ использовать серверы приложений. Многопользовательская аренда также мертва, потому что из-за этого возникает проблема, когда вы можете использовать виртуальные машины или контейнеры, такие как Docker, чтобы дать вам реальное разделение? – SteveD

Я думаю, что вы фокусируетесь на неправильной проблеме: почему у вас постоянно возникают проблемы с размером кучи? Являются ли ваши приложения утечкой памяти? У вас есть неограниченное потребление памяти? Не подходит ли ваше приложение к постоянному использованию памяти для данной рабочей нагрузки? – SteveD

Оформить заказ «мульти-арендатор» JVM.

JRE IBM имеет его уже: http://www.ibm.com/developerworks/library/j-multitenant-java/

Waratek реализовал его на верхней части Oracle JRE, и они создали ElastiCat, вилку Tomcat, который изолирует различные приложения в одном контейнере: http://www.elasticat.com/faq/

Мультикадр По слухам, арендатор появляется в официальной JVM Oracle Java 9.

================================================================================================================================================ =========

Обновление: Java 9 отсутствует, но нет слова Oracle о многопользовательской аренде. Кажется, они предпочитают иметь несколько JVM в эти дни, даже несколько контейнеров (например, докер).

источник

2014-10-01 21:41:17 greyfairer

Там плюсы и минусы обоих подходов:

Shared JVM

Нижних накладные расходы - объем памяти виртуальной машины Java (основные библиотеки и т.д.) необходимо только для загрузки сразу.
Лучшее использование памяти. Процессы Java будут потреблять память ОС для кучи, которая в настоящее время не используется.

Отдельные виртуальной машины Java

изоляции от 'жадных' или 'вытекающей' приложений.
Лучшая защита от вредоносного кода.
Простые обновления, обновляющие одно приложение, не снижая другого.

В целом, я бы не стал устанавливать политику одеяла. Ищите небольшие/микро-сервисы или другие приложения с низким уровнем использования, которые могут быть хорошими кандидатами для совместного использования и расширения оттуда.

источник

2014-10-01 16:10:24 Mikaveli

Спасибо Mikaveli. Я хорошо знаю компромиссы здесь. Я имею дело с ~ 100 экземплярами одного и того же приложения, каждый из которых работает в своей собственной JVM (один экземпляр для каждого клиента). Это дает нам большую гибкость (может запускать различную версию приложения в зависимости от клиента) и изолировать (крах приложения не влияет на других клиентов). Тем не менее, это просто кажется старым и неуклюжим, болью для управления/мониторинга, и все труднее масштабировать. Должен быть более современный способ борьбы с этими развертываниями приложений ... – Noky

Я бы предложил переместить что-нибудь подходящее для современного сервера приложений (JBoss или Glassfish), в зависимости от того, являются ли они главным образом веб-приложениями или если они нужна некоторая доработка. Сервер приложений сильно страдает от управления и мониторинга, поэтому это может стоить боли перехода. – Mikaveli

Glassfish мертв - я бы не рекомендовал никому двигаться к нему. – SteveD

Посмотрите Spring Boot или Fabric8 для современной взять на себя работает Java в управляемом пути

источник

2014-10-02 08:25:27 SteveD

Эти оба предназначены для создания отдельных виртуальных машин. Вы решаете проблемы мониторинга/управления, но вам все равно нужно вручную управлять памятью. – greyfairer

Я подозреваю, что основной проблемой является не управление приложениями и их памятью, но почему приложение настолько неустойчиво, что ему требуется постоянное считывание памяти? – SteveD

Хорошая точка SteveD. Проблема не в том, что приложение нестабильно. Это не веб-приложение, а довольно большое приложение со множеством различных настраиваемых опций и надстроек, которые различаются в зависимости от потребностей и размера клиента. Таким образом, нет никакого набора «один размер подходит всем» для распределения памяти для приложения. Хотя приложение, как правило, довольно стабильно, это факт жизни, что иногда возникают проблемы; с изолированными приложениями была огромная победа, когда что-то пошло не так. Таким образом, возможность посвятить куски памяти каждому клиенту - это и благословение, и проклятие. – Noky

Еще одна важная причина, чтобы иметь несколько JVM вместо одного, когда сталкиваются NUMA группы. Вы не можете распространять свои потоки в пределах одной JVM, соответствующей группам numa, как вы можете с несколькими процессами jvm. По крайней мере, я никогда не нашел способ сделать это.

У нас есть машины с двумя процессорами, каждый из которых имеет 18 ядер. Это дает две группы numa, и мы не можем задействовать 34 потока, которые должны быть распределены на обоих процессорах, если используется только одна JVM. Это очевидно из-за того, что предполагается, что все потоки одного и того же процесса JVM должны иметь быстрый доступ к одной и той же памяти, что не так.

Имея 34 Процесса, система предполагает, что у них нет необходимости в общей памяти и, таким образом, распределяет их по двум процессорам.

Если кто-то знает лучший способ сделать это, я был бы очень рад его услышать.

источник

2017-06-06 16:19:33

Несколько JVMs против сервера одного приложения

ответ

Смежные вопросы