Java-Xmx, максимальная память в системе
мое приложение Java запускает другое приложение Java, запустив процесс "java-jar j.jar". J.jar известно, что используется много памяти в зависимости от набора данных, и часто получает кучу OutOfMemoryError. Поэтому я хочу использовать -Xmx на нем, чтобы я мог выделить как можно больше памяти (или близко). Я думал о том, чтобы получить общую память в системе, а затем указать 80-90% этого в-Xmx.
есть ли решение моей проблемы? И, как мое решение звук?
Edit: я не могу уменьшить потребление памяти, поскольку используемая память-это встроенное сжатие Java pack200, которое я использую для упаковки некоторых файлов JAR.
7 ответов
в зависимости от вашей ОС это может сработать для получения свободного и доступного размера памяти:
java.lang.management.OperatingSystemMXBean mxbean = java.lang.management.ManagementFactory.getOperatingSystemMXBean();
com.sun.management.OperatingSystemMXBean sunmxbean = (com.sun.management.OperatingSystemMXBean) mxbean;
long freeMemory = sunmxbean.getFreePhysicalMemorySize();
long availableMemory = sunmxbean.getTotalPhysicalMemorySize();
оттуда вы можете выяснить 80-90% и запустить банку с максимальным размером памяти, который вы хотите.
Я не знаю, что это работает со всеми ОС (т. е. Windows), но он работал, когда я тестировал его с OSX и Linux.
предел для-XmX - Xmx1500m на 32-битных окнах. Общие библиотеки мешают большей куче. Для этого вам понадобится около 2Gb ОЗУ.
на ОС не-windows вы можете пойти больше, и 64Bit JVM способны намного больше.
Windows XP не позволит вам иметь более 3 ГБ оперативной памяти ( неважно, есть ли у вас 4 ГБ физической, начиная с XP SP3) Vista может отличаться от YMMV.
Я пробовал-Xmx4000M на 64-битном JVM на 64-битном Linux, и это было штраф. учитывая, что у меня было 6Gb физической ОЗУ, это был не большой запрос.
ваша идея 80% интересна, но мои тестовые системы работают с более высокими процентами, чем это без плохого эффекта. (До тех пор, пока вы не попытаетесь сделать что-нибудь еще.)
и другой комментатор прав, разбиение на страницы вашего образа JVM в памяти происходит не быстро. Позже JVM лучше делают это менее беспорядочно (но у них также есть лучшие сборщики мусора)
Если вы не можете уменьшить вашу память потребление-и я знаю, как это трудно – тогда есть много физической ОЗУ и выделять большую часть его.
ну, одна вещь, которую я могу вам сказать, это не позволяйте вашему приложению приблизиться к заполнению ОЗУ. Java-приложения вообще не меняются местами. Я думаю, что из-за сбора мусора java постоянно вытягивает свою память из swap.
Я попал в тупик, где я думаю, что система запрашивала java для памяти, которая вызовет GC и вытащит материал из файла подкачки-в этот момент система будет просто вращаться, пока я не сброшу ее.
Это было с большим количеством ОЗУ и большим пространством подкачки (для время) и более старая Java VM, поэтому ваш пробег может отличаться.
кроме того, в зависимости от того, как вы запускаете это другое приложение, вам может потребоваться указать-Xms для вашего приложения вместо другого. Если вы даете ему полную команду, дайте ему-Xms, но если вы просто вызываете основной класс в jar, то вашему приложению нужен-Xms. (О, вы указали, да, вам нужно передать его в команду "Java", которую вы вызываете. )
есть причина, по которой вы используете ОС для выполнения программы в банке? Если вам не нужно, чтобы он выполнялся в отдельном процессе от вашего приложения, вы можете просто вызвать основной метод непосредственно из своего кода и запустить приложение с любым-Xmx, который вы хотите.
Если вы еще этого не сделали, вам нужно запустить программу через профилировщик памяти. Вы можете обнаружить, что определенные структуры данных не удаляются, даже если они больше не используются.
JProfiler довольно изящный, но вы можете получить ту же информацию, используя HPROF, который был представлен в Java 5:http://java.sun.com/developer/technicalArticles/Programming/HPROF.html
имейте в виду также, что разные платформы имеют разные максимальные размеры кучи, основанные на архитектуре (32-бит против 64-бит), ОС и даже JVM.
Если у вас есть много значений, которые могут быть повторно использованы (например, строки, которые Вы читаете из XML-файла), вы можете получить огромное снижение требований к памяти путем объединения объектов.
существует полное сообщение в блоге о том, как устранить неполадки java-приложений с помощью jconsole и других инструментов в следующем блог. Имейте в виду, что отсутствие контроля над использованием памяти, скорее всего, является утечкой памяти, но это может быть связано и с другими причинами. Взгляните на сообщение, попробуйте реплицировать этот сценарий и посмотрите, решило ли это вашу проблему.
http://www.kiragiannis.com/cloud-computing/debug-a-java-application-in-the-cloud/