Распределение памяти JVM в контейнере Docker (LXC)

Мы подключили приложение JVM (Scala), Java 1.7, и пытаемся решить, как распределить память. У нас есть одно приложение, работающее в контейнере докеров. Если контейнеру-докеру выделено 4 ГБ ОЗУ, мы должны выделить 4 ГБ (или, может быть, чуть меньше, чтобы быть в безопасности) для JVM?Распределение памяти JVM в контейнере Docker (LXC)

Как я понимаю, в контейнере докеров нет других процессов, кроме того, что вызывается из точки входа, поэтому нам не нужно беспокоиться об использовании памяти, отличной от JVM, - это правда, или более упрощение? Есть ли еще вопросы, которые мы должны задать?

EDIT Мы используем Mesos/Marathon развернуть докер изображение - Я считаю, что это установить ограничения на контрольную группу памяти (по крайней мере, это создает впечатление, что он делает), но я определенно могу быть неправильным.

источник

2014-12-24 patwhite

В целях вашего вопроса обработайте контейнер, как и процесс, выполняющийся на главной машине.

Это является процессом, запущенным на хост-машине, хотя и со своими пространствами имен для сети, процесса и т.д.

Вы даже не «выделить» память в контейнер; вы можете предел, если вам нравится через группы, но поскольку JVM имеет свой лимит, это не нужно.

Наконец, в этой ситуации вы контролируете использование виртуальной памяти, а не ОЗУ.

источник

2014-12-24 06:11:00 Bryan

Мы используем мезо/марафон, поэтому я считаю, что это ограничение памяти через группы (хотя я мог ошибаться). По крайней мере, у нас есть ожидания памяти для контейнеров докеров, так как многочисленные контейнеры будут развернуты бок о бок. Все добавьте некоторые пояснения, но я не уверен, что это действительно отвечает на мой вопрос - если он ограничен, мы должны максимизировать java-память до предела cgroup? – patwhite

У меня есть такой же сценарий, и я использую 90% зарезервированной памяти для виртуальной машины Java, и работают очень хорошо

источник

2015-05-10 05:05:56

Спасибо за ответ! Мы делаем что-то подобное, и оно работает, но мне действительно интересно узнать о внутренних компонентах - есть ли какие-либо накладные расходы из самого контейнера, которые повлияют на назначение памяти. – patwhite

. Оставляя 90% зарезервированной памяти для Java, очень рискованно. До сих пор я предлагаю проверить ваше приложение и посмотреть, сколько памяти занимает JVM. Имейте в виду, что это память, о которой сообщает ОС, поскольку она может быть значительно выше, чем память, которую вы назначили для кучи + perm perm + thread stack. Чтобы дать вам некоторую идею, мы назначили 75% памяти контейнера куче. Затем мы понизили его до 65% и, наконец, до 50%, потому что Docker убивал контейнер из-за ограничений памяти. С 50% мы были хорошими. Это означает, что если в Docker мы назначили 2G, куча JVM была 1G (это JDK 8). – dgaviola

Учитывайте, что в зависимости от приложения, которое вы используете, будут отличаться друг от друга. Например, у нас есть приложение, которому требуется только небольшая куча, около 64 м, однако, если мы создадим контейнер Docker с 128 м, он будет убит в какой-то момент из-за ограничений памяти. В этом случае нам пришлось назначить 256 м контейнеру, даже когда приложение использовало 64 м кучи. Как я уже отмечал в своем предыдущем комментарии, вероятно, вам нужно проверить ваши приложения. – dgaviola

Вы не можете дать -Xmx такое же значение, как контейнер памяти, потому что Java будет нужно больше места для постоянного генерация (permgen), кеш кода и т. д. Существует один инструмент для другой контейнерной среды, Warden. Инструмент here: Я думаю, что он также может использоваться внутри Docker. Необходимо протестировать.

источник

2015-12-15 19:37:13 Rafaeska

Распределение памяти JVM в контейнере Docker (LXC)

ответ

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