LINUX.ORG.RU

Ограничить память процесса JVM

 


0

1

Такой вот вопрос организовался. Java при запуске всегда запускается с резервом памяти намного больше размера хипа вм. При этом этот резерв я так понимаю определяется общим размером озу машины на котором стартует вм. Пример: есть микросервис, запускается с Xmx32M, ему для работы этого всегда хватает. У меня на компе процесс вм скушает около гига памяти (16гб озу). На сервере 250мб (2гб озу), на оранжевом пи 64мб (256мб озу). Очевидно что для нормальной работы, ему явно не требуется > 64мб памяти, но по каким-то причинам, он жрет все что дают.

Вопрос - как ограничить память процесса java?


ему явно не требуется > 64мб памяти

Вопрос не в том, сколько памяти берётся, а в том, что взятая память не используется и не высвобождается. А зачем тогда она выделяется?

Deleted ()
Ответ на: комментарий от Deleted

Сискол ядру на выделение памяти дорогая операция, например в сях в тех местах где нужно избегать пауз не делают malloc, а jvm один раз запрашивает вагон памяти а дальше сама менеджет памятью, т.е. выделение памяти под новые объекты обходятся дешевле нативного malloc'а.

Aber ★★★★☆ ()
Последнее исправление: Aber (всего исправлений: 2)
Ответ на: комментарий от Aber

jvm один раз запрашивает вагон памяти а дальше сама менеджет памятью

Так какого рожна именно это «менеджет памятью» не происходит, память не пользуется, но при этом на её обслуживание тратится cpu.

Deleted ()
Ответ на: комментарий от vvn_black

-Xmx -Xms -Xss не имеют отношения к размеру процесса. Все значения зафиксированы на 32М. Вопрос идет о памяти именно процесса ОС, который раздут во много раз больше чем размер хипа.

Serbis ()
Ответ на: комментарий от Deleted

На её обслуживание cpu не тратится, т.к. как я понимаю jvm не занимается очисткой пока не достигнет некоторого лимита на занимаемую память.

Смотрел всякие конференции с рассказами про работу GC, где говори что jvm создает область для долгоживущих объектов и две области для короткоживущих, в первой области jvm может заняться например дефрагментацией (упреждая проблему фрагментации хипа), а вот области для короткоживущих объектов скорее всего создают «пилу» на графиках использования памяти. Если я не ошибаюсь новые объекты создаются в первой области короткоживущих объектов до тех пор пока не не будет достигнут лимит по выделенной памяти, затем происходит stop-the-world пауза (раньше так было) во время которой объекты на которых хоть кто-то ссыпается копируются из первой области во вторую область короткоживущих объектов, а исходная область уничтожается/отчищается. Т.е. чем меньше хип тем больше stop-the-world пауз, и все повторяется. Про stop-the-wrold так раньше было, сейчас кажется хитрее и пауз таких мало.

Aber ★★★★☆ ()
Последнее исправление: Aber (всего исправлений: 1)
Ответ на: комментарий от Deleted

Ну ... :) Призываю stevejobs

А вообще я хотел сказать, что пока память не кончилась, jvm ничего делать не будет, никакого копирования из одной области в другую и прочего, в этом смысл был мой фразы что cpu не используется, правда из моих слов выходит, что потом должна возникнуть долгая паза, потому надеюсь stevejobs сможет разъяснить по работе gc или хотяб ссылку дать.

Aber ★★★★☆ ()
Последнее исправление: Aber (всего исправлений: 1)
Ответ на: комментарий от Serbis

если все значения зафиксированы на 32M, то меньше 96 никак быть не может: Xmx + XX:MaxPermSize + 1*Xss и это только для случая 1 треда

anonymous ()

При этом этот резерв я так понимаю определяется общим размером озу машины на котором стартует вм.

Если упростить, то да.

Вопрос - как ограничить память процесса java?

-Xmx

Legioner ★★★★★ ()
Ответ на: комментарий от Aber

Да, старая жаба не отпускает память, которую потрогала.

Частично эта проблема решена только в свежих сборщиках. В том числе, в G1 - только начиная с Java 12

Попробуйте скачать сборку от Azul (в оракловой нет шенанды) и вначале пожить с G1, потом переключиться на шенанду ( -XX:+UseShenandoahGC).

Качать здесь: https://www.azul.com/downloads/zulu/

Детали о поведении свежего G1 здесь: https://habr.com/ru/company/jugru/blog/444434/

начиная со слов «Promptly Return Unused Committed Memory from G1» (искать ctrl+F, потому что мне лень размечать хтмл-якори)

обратите внимание на флаги, которыми настраивается G1, если используете его

stevejobs ★★★★☆ ()
Ответ на: комментарий от Aber

Ну и может быть, начать надо не с GC, а с того что начиная с OpenJDK 8 метаданные лежат не в пермгене, а в Метаспейсе, и метаспейс - это нативная память. По умолчанию она расширяется, но можно зафиксировать. Надо глянуть на ключики -XX:MetaspaceSize и -XX:MaxMetaspaceSize.

Я не уверен, где лежит в хотспоте code cache, но если тоже в оффхипе - проверьте что не делаете ничего *странного* в настройках JIT и тому подобного. То есть, если вы врубили Грааль, выключили tiered compilation и сказали собрать джитом всю программу, то наверное вы сами выпрыгнули без парашюта

stevejobs ★★★★☆ ()
Последнее исправление: stevejobs (всего исправлений: 3)

Я даже не знаю что сказать. В гугле забанили?

HIS ()
Ответ на: комментарий от stevejobs

Я рад тебя читать (хоть ты и странный). Кеш Джава машины лежит в среде самой Джава машины. Я вообще не понял, что ты хочешь донести.

HIS ()
Ответ на: комментарий от stevejobs

Я не уверен, где лежит в хотспоте code cache

А зачем ты тогда ходишь на всякие «посиделки» и рассказываешь что ты мега джавист? Если ты мега круто всё по Джаве - тогда и пиши.

HIS ()
-XX:+UseG1GC -XX:MaxHeapFreeRatio=30 -XX:MinHeapFreeRatio=10
anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.