Не удается заставить Mule 3.4.0 использовать более 4 ГБ памяти.

В настоящее время я работаю над проектом, который требует большого объема памяти, и я не могу заставить Mule 3.4.0 использовать более 4 ГБ ОЗУ (работает на RHEL 6.2). Я использую 64-битный сервер Java HotSpot JVM 1.7.0_45-b18 и версию Mule для сообщества.

Я редактировал файл wrapper.conf и пробовал множество настроек, но безрезультатно.

Я вижу, что в Mule JIRA указана ошибка: https://www.mulesoft.org/jira/browse/MULE-7018, который закрыт для версии 3.4.0, но как неполный.

Мои последние попытки заключались в том, чтобы явно попытаться заставить его сразу же занять 8 ГБ пространства в куче, последняя попытка была следующей:

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=8192

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=8192

Я попытался установить параметры initmemory и maxmemory равными нулю в соответствии с этим старым сообщением об оболочке: http://java-service-wrapper.996253.n3.nabble.com/4096MB-heap-limit-td1483.html — однако это приводит к тому, что мул не начать правильно.

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

wrapper.java.additional.6=-Xmx8192
wrapper.java.additional.7=-Xms8192

При этом я вижу, что обе настройки памяти отправляются в JVM (т.е. -Xmx8192 -Xms8192 сначала в строке процесса, а затем -Xms4096m -Xmx4096m). Однако моя команда top дает не более 4,2 ГБ резидентной памяти, занимаемой процессом JVM. Я понимаю, что верхний столбец RES не является 100% точным способом определения использования памяти JVM, но у меня сложилось впечатление, что если я пытаюсь выделить 8 ГБ из коробки, он определенно должен превышать 4 ГБ. Машина имеет 60 ГБ физической памяти.

Кто-нибудь нашел способ получить более 4 ГБ места в куче для Mule 3.4.0?


java memory-management mule java-service-wrapper
person JeremyL    schedule 03.02.2014    source источник
comment
Вы используете 32-битную JVM?   -  person SLaks    schedule 03.02.2014
comment
Хороший вопрос и спасибо за вопрос, да, я на 64-битной JVM. Я добавил дополнительные разъяснения к исходному вопросу.   -  person JeremyL    schedule 04.02.2014

Ответы (3)


arrow_upward
6
arrow_downward

Я считаю, что ответ Антона будет работать нормально, однако я не мог четко понять, когда лицензия Java Service Wrapper изменилась на GPL, и не хотел рисковать какими-либо негативными последствиями этого изменения для моего варианта использования.

Я нашел способ заставить это работать, используя текущую версию Java Service Wrapper, включенную в Mule 3.4.0, и, таким образом, не иметь никаких дополнительных лицензионных последствий с переходом JSW на GPL.

Если вы измените файл wrapper.conf, чтобы явно установить минимальные и максимальные параметры памяти на 0:

wrapper.java.initmemory=0
wrapper.java.maxmemory=0

Затем вы можете передать параметры памяти напрямую через дополнительные свойства, также в файле wrapper.conf:

wrapper.java.additional.6=-Xmx8192m
wrapper.java.additional.7=-Xms4096m

Когда initmemory и maxmemory явно установлены равными нулю, оболочка больше не будет сначала передавать свои собственные параметры памяти в JVM и, таким образом, позволит вам указать свои собственные. Обратите внимание, что это не работает для maxPermGen - по какой-то причине JSW все еще указывает для этого свое собственное значение.

person JeremyL    schedule 13.03.2014

arrow_upward
0
arrow_downward

Как говорится в комментариях к заявке Jira, вы можете загрузить более позднюю версию оболочки Tanuki (и заменить файлы оболочки, включенные в автономный Mule, в разделе lib/boot), чтобы обойти это ограничение. Итак, скачайте Tanuki 3.3.0, удалите все файлы с "оберткой" в названии в отдельной папке lib/boot и подпапках Mule и замените их файлами, включенными в папки lib и bin в оболочке Tanuki. Исполняемый файл Tanuki (bin/wrapper) находится в папке lib/boot/exec, а файлы .so и .jar — в папке lib/boot. Mule должен запуститься нормально, но, к сожалению, я не могу проверить настройку 4G+, так как сейчас у меня нет подходящей машины.

person Anton Kupias    schedule 03.02.2014
comment
Я думаю, что это решит эту проблему - спасибо, это хорошая мысль - меня беспокоит то, что в какой-то момент лицензия была изменена на GPL для Java Service Wrapper, и я не думаю, что последствия этого подходят для моего варианта использования. Мне было трудно выяснить, когда конкретно была изменена лицензия. Я собираюсь добавить ответ, который я получил для работы с существующей версией JSW в mule 3.4.0. - person JeremyL; 13.03.2014

arrow_upward
0
arrow_downward

Попытка увеличить CompressedClassSpaceSize для экземпляра Mule, работающего как служба Windows, безрезультатна. Значение не будет получено, пока я, наконец, не выясню, почему.

Я внес изменения в файл wrapper.conf, добавив эту строку wrapper.java.additional.4=-XX:CompressedClassSpaceSize=2G (кстати, 1G по умолчанию)

но не удалось проверить файл wrapper-additional.conf, где ключ .4 уже был взят, переопределяя мою настройку. Я переместил свое изменение и изменил значение ключа на следующий последовательный номер и вуаля: wrapper.java.additional.6=-XX:CompressedClassSpaceSize=2G

Несколько полезных команд: c:> tasklist | findstr java ... обратите внимание на PID... c:> jmap -heap

p.s. если вы когда-либо хотели установить это значение, запуская Mule в автономном режиме в строке cmd (в отличие от службы), тогда это будет c:> mule -start -M-XX:CompressedClassSpaceSize=2G

Удачного кодирования!

person Striker    schedule 04.03.2016