Как заставить JVM использовать максимальную (всю оставшуюся) память сервера

Question

Как заставить JVM использовать максимальную (всю оставшуюся) память сервера

2

У меня есть консольное приложение алгоритма DFS, которое работает быстрее, когда предоставляется больше памяти. Просто приложение алгоритма DFS, не использующее ни I/O, ни другие внешние ресурсы JVM. Он потребляет только процессор и память. Приложение может работать с 1 ГБ памяти, но работать гораздо быстрее с 2 ГБ памяти. Больше памяти, быстрее приложение может работать. Я не дотрагивался до предела скорости, так как 12 ГБ памяти. Поэтому я должен использовать всю память сервера, чтобы ускорить ее. И приложение не обязательно параллельно, один запрос только один раз.

И мне нужно установить приложение на другой сервер с разным объемом памяти.

Есть ли способ позволить JVM использовать всю оставшуюся память сервера?

-XX:MaxRAMFraction=1

MaxRAMFraction не КАЖДЫЙ сервер хорош, некоторый сервер приведет к сбою JVM в случае сбоя памяти местоположения, некоторые работают хорошо.

Используйте приложение-оболочку, чтобы система оставалась в памяти, и минус некоторое использование памяти, отличное от Xmx, а затем запускает реальное приложение с теми же Xms и Xms. Этот метод также приведет к ошибке распределения памяти JVM. Поскольку приведенный ниже код возвращает гораздо больше, чем память, которую мы можем использовать, а не только минус Xss256m или еще более неважной JVM-памяти.

com.sun.management.OperatingSystemMXBean mbean = (com.sun.management.OperatingSystemMXBean)
    ManagementFactory.getOperatingSystemMXBean();
long size = mbean.getFreePhysicalMemorySize();

Итак, есть ли хороший способ позволить JVM использовать всю оставшуюся память сервера?

rufushuang 13 сен. 2016, в 08:13

Источник

2

Напишите скрипт, который работает в вашей операционной системе, чтобы узнать оставшуюся память, затем запустите Java с -Xmx и объемом оставшейся памяти. Примечание: это может быть опасно, потому что потребность в памяти в точке X во времени может сильно отличаться от точки Y во времени. То, что вы хотите, делает его очень зависимым от того, когда вы запускаете виртуальную машину (во время ваших ночных пакетных заданий или нет?) - лучше исходить из того, какой объем памяти вам нужен, а не какой доступен.
Erwin Bolwidt 13 сен. 2016, в 05:32
0

@ErwinBolwidt - это не ночная пакетная работа, а просто приложение с алгоритмом DFS, без ввода-вывода и других ресурсов внешней JVM. Приложение может работать с 1 ГБ памяти, но намного быстрее с 2 ГБ памяти, чем больше памяти, тем быстрее может работать приложение. Так почему бы не использовать всю оставшуюся память сервера?
rufushuang 13 сен. 2016, в 05:39
0

Если вы никогда не запускаете что-либо еще на сервере, и использование памяти сервером всегда одинаково со временем, тогда, конечно, нет проблем. Но затем вы также можете определить это один раз вручную и выяснить, какой аргумент -Xmx вы хотите передать Java.
Erwin Bolwidt 13 сен. 2016, в 06:35
0

@Erwin Эрвин один раз от руки :( Было бы ужасно, что мне нужно установить приложение на десятки разных серверов с разным объемом памяти. И я не очень уверен, изменится ли свободная память после некоторого обслуживания сервера / операционной системы.
rufushuang 13 сен. 2016, в 07:49
0

Как я и предлагал в своем первом комментарии, вы можете написать скрипт, который его определяет, прежде чем запускать Java. В любом случае вам нужно знать, прежде чем запускать Java, вы не можете изменить его после запуска виртуальной машины.
Erwin Bolwidt 13 сен. 2016, в 07:57
0

@ErwinBolwidt Как я уже упоминал в последней части темы. Я попытался обернуть программу, чтобы получить оставшуюся память, а затем запустить JVM с теми же Xms и Xmx (недостаточно только установки Xmx для приложения, требующего памяти). В результате я не могу найти четкую (или линейную) связь между оставшейся памятью и настройкой Xms / Xmx. Результат OperatingSystemMXBean часто возвращает что-то вроде 4.6G, но мы можем запустить JVM только с 3.1G или около того. И что еще хуже, этот разрыв указывается сервером. И это гораздо больший разрыв, чем я думаю, просто использование Xss и не куча.
rufushuang 13 сен. 2016, в 08:31

Показать ещё 4 комментария

Теги:

java

memory

memory-management

jvm

1 ответ

Ещё вопросы

Напишите скрипт, который работает в вашей операционной системе, чтобы узнать оставшуюся память, затем запустите Java с -Xmx и объемом оставшейся памяти. Примечание: это может быть опасно, потому что потребность в памяти в точке X во времени может сильно отличаться от точки Y во времени. То, что вы хотите, делает его очень зависимым от того, когда вы запускаете виртуальную машину (во время ваших ночных пакетных заданий или нет?) - лучше исходить из того, какой объем памяти вам нужен, а не какой доступен.
@ErwinBolwidt - это не ночная пакетная работа, а просто приложение с алгоритмом DFS, без ввода-вывода и других ресурсов внешней JVM. Приложение может работать с 1 ГБ памяти, но намного быстрее с 2 ГБ памяти, чем больше памяти, тем быстрее может работать приложение. Так почему бы не использовать всю оставшуюся память сервера?
Если вы никогда не запускаете что-либо еще на сервере, и использование памяти сервером всегда одинаково со временем, тогда, конечно, нет проблем. Но затем вы также можете определить это один раз вручную и выяснить, какой аргумент -Xmx вы хотите передать Java.
@Erwin Эрвин один раз от руки :( Было бы ужасно, что мне нужно установить приложение на десятки разных серверов с разным объемом памяти. И я не очень уверен, изменится ли свободная память после некоторого обслуживания сервера / операционной системы.
Как я и предлагал в своем первом комментарии, вы можете написать скрипт, который его определяет, прежде чем запускать Java. В любом случае вам нужно знать, прежде чем запускать Java, вы не можете изменить его после запуска виртуальной машины.
@ErwinBolwidt Как я уже упоминал в последней части темы. Я попытался обернуть программу, чтобы получить оставшуюся память, а затем запустить JVM с теми же Xms и Xmx (недостаточно только установки Xmx для приложения, требующего памяти). В результате я не могу найти четкую (или линейную) связь между оставшейся памятью и настройкой Xms / Xmx. Результат OperatingSystemMXBean часто возвращает что-то вроде 4.6G, но мы можем запустить JVM только с 3.1G или около того. И что еще хуже, этот разрыв указывается сервером. И это гораздо больший разрыв, чем я думаю, просто использование Xss и не куча.

Peter Lawrey · Answer 1 · 2016-09-13T05-11-00.000Z

Для больших областей памяти я использую от кучи, и это уменьшает накладные расходы на GC, одна из преимуществ - это может быть любой размер во время выполнения и даже больше, чем основная память, если вы делаете это тщательно. Вы можете использовать прямой ByteBuffer но я использую библиотеку, которую я написал, которая расширяет функциональность ByteBuffer (>> 2 ГБ и потокобезопасность). Хронические байты. Самый большой из всех использует это 100 МБ виртуальной памяти, сопоставленной с диском.

У нас есть две структуры данных в верхней части Chronicle Bytes, хранилище хроник -данных для хранения ключей и очередь хроники хроники. Это может облегчить хранение данных с кучи с помощью интерфейса более высокого уровня.

Как работает куча, он должен зарезервировать максимальный размер кучи при запуске в виде единого непрерывного блока виртуальной памяти. В частности, GC предполагает случайный доступ к этой памяти на очистке, что означает, что если вы немного переработали свою память, возможно, потому, что процесс начался после того, как ваш, а часть кучи поменяется, вы увидите резкое падение производительности для всей вашей машины. Windows, как правило, начинает заменять ваш графический интерфейс, что означает, что вы не можете вернуть управление без силового цикла. Linux не так плох, но вы захотите убить свой процесс на этом этапе. Это позволяет настроить его размер, чтобы использовать всю память очень сильно, если использование вашей машины меняется.

Используя виртуальную память по сравнению, GC не трогает ее, поэтому неиспользуемые части имеют мало влияния. Вы можете обладать виртуальной памятью во много раз основной памятью, но только ваш текущий рабочий набор имеет значение, и это размер полностью контролируется во время выполнения. Примечание. В Linux вы можете иметь размер виртуальной памяти на 1000x свободного места на диске, но используйте с осторожностью, если вы исчерпаете себя, нажав слишком много страниц, и ваша программа выйдет из строя.

Хорошее решение. Чтобы применить его, OP должен иметь контроль над исходным кодом и пропускной способностью для адаптации к вашей библиотеке, но в зависимости от его варианта использования, который может стоить усилий.
@ErwinBolwidt, если он не хочет использовать мою библиотеку, он может использовать несколько ByteBuffers, хотя, я подозреваю, это будет больше работы.
Да, использование без кучи - отличная и правильная идея. И я также рассматриваю возможность работы над этим (или просто переключаюсь на другой язык с лучшим управлением памятью? Lol). Но у старого приложения есть много типов объектов, которые должны остаться в памяти, будет очень трудно переписать его, чтобы использовать кучу только с байтами. Итак, можем ли мы просто сосредоточиться на некоторых методах, не слишком сильно изменяя код?
@rufushuang самое простое решение - добавить больше памяти, конечно. Я бы не рекомендовал использовать вне кучи, пока ваши данные / кучи уже около 32 ГБ. У моего 8-летнего компьютера есть старый компьютер, которым я не пользовался в течение 2 лет, и он имеет 24 ГБ, у моего телевизора - 16 ГБ. Если вам нужен 1+ ТБ, самостоятельно управляемая виртуальная память - ваш единственный ответ на любом языке.