Максимальный размер кучи Java 32-разрядной виртуальной машины в 64-разрядной ОС

StackOverflow https://stackoverflow.com/questions/1434779

  •  07-07-2019
  •  | 
  •  

Вопрос

Вопрос не в максимальном размере кучи в 32-разрядной ОС, учитывая, что 32-разрядные операционные системы имеют максимальный размер адресуемой памяти 4 ГБ и что максимальный размер кучи JVM зависит от того, сколько непрерывной свободной памяти может быть зарезервировано.

Меня больше интересует знание максимального (как теоретического, так и практически достижимого) размера кучи для 32-разрядной JVM, работающей в 64-разрядной ОС.В принципе, я рассматриваю ответы, похожие на цифры в соответствующем вопросе по SO.

Что касается того, почему используется 32-разрядная JVM вместо 64-разрядной, причина не техническая, а скорее административная / бюрократическая - вероятно, уже слишком поздно устанавливать 64-разрядную JVM в производственную среду.

Это было полезно?

Решение

32-разрядные JVM, которые ожидают иметь один большой кусок памяти и используют необработанные указатели, не могут использовать более 4 ГБ (поскольку это 32-разрядное ограничение, которое также применяется к указателям). Это включает в себя Sun и, я уверен, также реализации IBM. Я не знаю, например, JRockit или другие имеют большой объем памяти в своих 32-битных реализациях.

Если вы ожидаете, что достигнете этого предела, вам настоятельно рекомендуется запустить параллельный трек для проверки 64-битной JVM для вашей производственной среды, чтобы вы были готовы к тому, что 32-битная среда выйдет из строя. В противном случае вам придется выполнять эту работу под давлением, что никогда не бывает приятно.

<Ч>

Изменить 2014-05-15: FAQ по Oracle:

Максимальный теоретический предел кучи для 32-разрядной JVM составляет 4G. Из-за различных дополнительных ограничений, таких как доступный обмен, использование адресного пространства ядра, фрагментация памяти и издержки на виртуальные машины, на практике этот предел может быть намного ниже. В большинстве современных 32-разрядных систем Windows максимальный размер кучи будет варьироваться от 1,4 ГГ до 1,6 ГБ. В 32-битных ядрах Solaris адресное пространство ограничено 2G. В 64-разрядных операционных системах, работающих под управлением 32-разрядной виртуальной машины, максимальный размер кучи может быть выше, приближаясь к 4G во многих системах Solaris.

( http://www.oracle.com/technetwork/java /hotspotfaq-138619.html#gc_heap_32bit )

Другие советы

Вы можете обратиться к среде выполнения Java:

public class MaxMemory {
    public static void main(String[] args) {
        Runtime rt = Runtime.getRuntime();
        long totalMem = rt.totalMemory();
        long maxMem = rt.maxMemory();
        long freeMem = rt.freeMemory();
        double megs = 1048576.0;

        System.out.println ("Total Memory: " + totalMem + " (" + (totalMem/megs) + " MiB)");
        System.out.println ("Max Memory:   " + maxMem + " (" + (maxMem/megs) + " MiB)");
        System.out.println ("Free Memory:  " + freeMem + " (" + (freeMem/megs) + " MiB)");
    }
}

Это приведет к сообщению о "Максимальной памяти", основанной на распределении кучи по умолчанию.Таким образом, вам все равно нужно было бы поиграть с -Xmx (вкл. Горячая точка).Я обнаружил, что, работая в 64-разрядной версии Windows 7 Enterprise, мой 32-разрядный JVM HotSpot может выделять до 1577 мбайт:

[C:scratch]> java -Xmx1600M MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
[C:scratch]> java -Xmx1590M MaxMemory
Total Memory: 2031616 (1.9375 MiB)
Max Memory:   1654456320 (1577.8125 MiB)
Free Memory:  1840872 (1.75559234619 MiB)
[C:scratch]>

Принимая во внимание, что с 64-разрядный JVM на той же ОС, конечно, она намного выше (около 3TiB)

[C:scratch]> java -Xmx3560G MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
[C:scratch]> java -Xmx3550G MaxMemory
Total Memory: 94240768 (89.875 MiB)
Max Memory:   3388252028928 (3184151.84297 MiB)
Free Memory:  93747752 (89.4048233032 MiB)
[C:scratch]>

Как уже упоминали другие, это зависит от операционной системы.

  • Для 32-разрядной Windows:это будет <2 ГБ (Книга о внутренностях Windows говорит, что 2 ГБ для пользовательских процессов)
  • Для 32-разрядной версии BSD / Linux:<3 ГБ (из книги о дьяволе)
  • Для 32-разрядной macOS X:<4 ГБ (от Внутренние компоненты Mac OS X книга)
  • Не уверены насчет 32-разрядной Solaris, попробуйте приведенный выше код и дайте нам знать.

Для 64-разрядной операционной системы хоста, если JVM 32-разрядная, это все равно будет зависеть, скорее всего, как показано выше.

-- ОБНОВЛЕНИЕ 20110905:Я просто хотел указать на некоторые другие наблюдения / детали:

  • Оборудование, на котором я запустил это, было 64-разрядным с установленным 6 ГБ оперативной памяти.Операционной системой была 64-разрядная Windows 7 Enterprise
  • Фактическое количество Runtime.MaxMemory то, что может быть выделено, также зависит от операционной системы. рабочий набор.Однажды я запустил это, когда у меня также был запущен VirtualBox, и обнаружил, что могу нет успешно запустите JVM HotSpot с помощью -Xmx1590M и пришлось пойти на меньший шаг.Это также подразумевает, что вы можете получить более 1590M в зависимости от размера вашего рабочего набора на данный момент (хотя я по-прежнему утверждаю, что он будет меньше 2GiB для 32-разрядной версии из-за дизайна Windows)

Вы не указываете , какую ОС.

В Windows (для моего приложения - долго работающего приложения для управления рисками) мы заметили, что на Windows 32bit мы можем пойти не более 1280 МБ. Я сомневаюсь, что 32-битная JVM под 64-битной версией будет иметь какое-то значение

Мы портировали приложение на Linux, и мы запускаем 32-битную JVM на 64-битном оборудовании, а виртуальная машина на 2,2 ГБ работала довольно легко.

Самая большая проблема, с которой вы можете столкнуться, - это сборщик мусора в зависимости от того, для чего вы используете память.

Из 4.1.2 Размер кучи :

  

" для 32-битной модели процесса максимальный размер виртуального адреса   процесс обычно составляет 4 ГБ, хотя некоторые операционные системы ограничивают это   2 ГБ или 3 ГБ. Максимальный размер кучи обычно составляет -Xmx3800m (1600m) для   2 ГБ), хотя фактическое ограничение зависит от приложения.   Для 64-битных моделей процессов максимум практически не ограничен. & Quot;

Нашел довольно хороший ответ здесь: Максимальный объем памяти Java в Windows XP .

Недавно у нас был некоторый опыт с этим. Мы недавно портировали с Solaris (x86-64 Version 5.10) на Linux (RedHat x86-64) и поняли, что у нас меньше памяти для 32-битного процесса JVM в Linux, чем Solaris.

Для Solaris это почти до 4 ГБ (http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit).

Мы запустили наше приложение с -Xms2560m -Xmx2560m -XX: MaxPermSize = 512m -XX: PermSize = 512m , без проблем в Solaris в течение последних нескольких лет. Попытка переместить его в Linux, и у нас были проблемы со случайными ошибками нехватки памяти при запуске. Мы могли только запустить его на -Xms2300 -Xmx2300 . Тогда нам сообщили об этом из поддержки.

  

32-битный процесс в Linux имеет   максимальное адресуемое адресное пространство   3gb (3072mb), тогда как на Solaris это   полный 4 ГБ (4096 МБ).

Ограничения 32-разрядной JVM в 64-разрядной ОС будут точно такими же, как ограничения 32-разрядной JVM в 32-разрядной ОС. В конце концов, 32-разрядная JVM будет работать на 32-разрядной виртуальной машине (в смысле виртуализации), поэтому она не будет знать, что она работает на 64-разрядной ОС / машине.

Одним из преимуществ использования 32-разрядной JVM в 64-разрядной ОС по сравнению с 32-разрядной ОС является то, что вы можете иметь больше физической памяти и, следовательно, реже встречаться с подкачкой / подкачкой. Однако это преимущество полностью реализуется только при наличии нескольких процессов.

Что касается того, почему используется 32-разрядная JVM вместо 64-разрядной, то причина не техническая, а скорее административная / бюрократическая...

Когда я работал в BEA, мы обнаружили, что среднестатистическое приложение на самом деле побежал медленнее в 64-разрядной JVM это происходило при запуске в 32-разрядной JVM.В некоторых случаях снижение производительности достигало 25%.Итак, если вашему приложению действительно не нужна вся эта дополнительная память, вам было бы лучше настроить больше 32-разрядных серверов.

Насколько я помню, тремя наиболее распространенными техническими обоснованиями использования 64-разрядной версии, с которыми сталкивался персонал BEA professional services, были:

  1. Приложение манипулировало несколькими массивными изображениями,
  2. Приложение выполняло массовую обработку чисел,
  3. В приложении произошла утечка памяти, заказчик был главным по правительственному контракту, и они не хотели тратить время и расходы на отслеживание утечки памяти.(Использование массивной памяти heap увеличило бы наработку на отказ, а prime все равно получил бы оплату)

.

JVM JROCKIT, в настоящее время принадлежащая Oracle, поддерживает несмежное использование кучи, что позволяет 32-битной JVM получить доступ к более чем 3,8 ГБ памяти, когда JVM работает в 64-битной ОС Windows. (2,8 ГБ при работе в 32-разрядной ОС).

http://blogs.oracle.com/jrockit/entry/how_to_get_almost_3_gb_heap_ / р>

JVM можно бесплатно загрузить (требуется регистрация) на

http://www.oracle.com/technetwork/middleware/ JRockit / загрузки / index.html

Вот несколько тестов под Solaris и Linux 64-bit

Solaris 10 - SPARC - компьютер T5220 с 32 ГБ оперативной памяти (и около 9 ГБ свободной) 

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3750m MaxMemory
Error occurred during initialization of VM
Could not reserve space for ObjectStartArray
$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3700m MaxMemory
Total Memory: 518520832 (494.5 MiB)
Max Memory:   3451912192 (3292.0 MiB)
Free Memory:  515815488 (491.91998291015625 MiB)
Current PID is: 28274
Waiting for user to press Enter to finish ...

$ java -version
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Server VM (build 20.5-b03, mixed mode)

$ which java
/usr/bin/java
$ file /usr/bin/java
/usr/bin/java: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped, no debugging information available

$ prstat -p 28274
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
28274 user1     670M   32M sleep   59    0   0:00:00 0.0% java/35

Кстати: очевидно, Java не выделяет много фактической памяти при запуске. Похоже, что на каждый запущенный экземпляр уходит только около 100 МБ (я начал 10)

Solaris 10 - x86 - ВМ VMWare с 8 ГБ ОЗУ (около 3 ГБ свободно *)

3 ГБ свободной оперативной памяти не совсем соответствуют действительности. Кэш-память ZFS использует большой объем оперативной памяти, но у меня нет доступа с правами суперпользователя, чтобы точно определить, сколько 

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3650m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3600m MaxMemory
Total Memory: 516423680 (492.5 MiB)
Max Memory:   3355443200 (3200.0 MiB)
Free Memory:  513718336 (489.91998291015625 MiB)
Current PID is: 26841
Waiting for user to press Enter to finish ...

$ java -version
java version "1.6.0_41"
Java(TM) SE Runtime Environment (build 1.6.0_41-b02)
Java HotSpot(TM) Server VM (build 20.14-b01, mixed mode)

$ which java
/usr/bin/java

$ file /usr/bin/java
/usr/bin/java:  ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available

$ prstat -p 26841
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
26841 user1     665M   22M sleep   59    0   0:00:00 0.0% java/12

RedHat 5.5 - x86 - VMWare VM с 4 ГБ ОЗУ (используется около 3,8 ГБ - 200 МБ в буферах и 3,1 ГБ в кэшах, поэтому около 3 ГБ свободно) 

$ alias java='$HOME/jre/jre1.6.0_34/bin/java'

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3500m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3450m MaxMemory
Total Memory: 514523136 (490.6875 MiB)
Max Memory:   3215654912 (3066.6875 MiB)
Free Memory:  511838768 (488.1274871826172 MiB)
Current PID is: 21879
Waiting for user to press Enter to finish ...

$ java -version
java version "1.6.0_34"
Java(TM) SE Runtime Environment (build 1.6.0_34-b04)
Java HotSpot(TM) Server VM (build 20.9-b04, mixed mode)

$ file $HOME/jre/jre1.6.0_34/bin/java
/home/user1/jre/jre1.6.0_34/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped

$ cat /proc/21879/status | grep ^Vm
VmPeak:  3882796 kB
VmSize:  3882796 kB
VmLck:         0 kB
VmHWM:     12520 kB
VmRSS:     12520 kB
VmData:  3867424 kB
VmStk:        88 kB
VmExe:        40 kB
VmLib:     14804 kB
VmPTE:        96 kB

Та же машина, использующая JRE 7 

$ alias java='$HOME/jre/jre1.7.0_21/bin/java'

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3500m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3450m MaxMemory
Total Memory: 514523136 (490.6875 MiB)
Max Memory:   3215654912 (3066.6875 MiB)
Free Memory:  511838672 (488.1273956298828 MiB)
Current PID is: 23026
Waiting for user to press Enter to finish ...

$ java -version
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) Server VM (build 23.21-b01, mixed mode)

$ file $HOME/jre/jre1.7.0_21/bin/java
/home/user1/jre/jre1.7.0_21/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

$ cat /proc/23026/status | grep ^Vm
VmPeak:  4040288 kB
VmSize:  4040288 kB
VmLck:         0 kB
VmHWM:     13468 kB
VmRSS:     13468 kB
VmData:  4024800 kB
VmStk:        88 kB
VmExe:         4 kB
VmLib:     10044 kB
VmPTE:       112 kB

Должно быть намного лучше

Для 32-разрядной JVM, работающей на 64-разрядном хостинге, я полагаю, что для кучи останется все нефрагментированное виртуальное пространство, доступное после загрузки JVM, ее собственные библиотеки DLL и любые материалы, совместимые с 32-разрядной ОС.Как дикое предположение, я бы подумал, что 3 ГБ должно быть возможно, но насколько это лучше, зависит от того, насколько хорошо вы работаете на 32-разрядной хостинговой платформе.

Кроме того, даже если вы могли бы создать гигантскую кучу объемом 3 ГБ, возможно, вы не захотите этого делать, так как это приведет к тому, что паузы GC станут потенциально проблематичными.Некоторые люди просто запускают больше JVM, чтобы использовать дополнительную память, а не одну гигантскую.Я предполагаю, что прямо сейчас они настраивают JVM, чтобы лучше работать с гигантскими кучами.

Немного сложно точно сказать, насколько лучше вы можете это сделать.Я предполагаю, что вашу 32-битную ситуацию можно легко определить экспериментальным путем.Это, конечно, трудно предсказать абстрактно, поскольку на это влияет множество факторов, особенно потому, что виртуальное пространство, доступное на 32-разрядных хостах, довольно ограничено..Куча действительно должна существовать в непрерывной виртуальной памяти, поэтому фрагментация адресного пространства для dll и внутреннее использование адресного пространства ядром операционной системы будут определять диапазон возможных распределений.

Операционная система будет использовать часть адресного пространства для отображения устройств HW и своего собственного динамического распределения.Хотя эта память не отображается в адресное пространство процесса Java, ядро операционной системы не может получить доступ к ней и вашему адресному пространству одновременно, поэтому это ограничит размер виртуального пространства любой программы.

Загрузка DLL-файлов зависит от реализации и выпуска JVM.Загрузка ядра ОС зависит от огромного количества вещей, выпуска, HW, сколько всего было отображено с момента последней перезагрузки, кто знает...

Подводя итог

Бьюсь об заклад, вы получаете 1-2 ГБ в 32-разрядной версии и около 3 в 64-разрядной, так что общее улучшение примерно 2x.

На Solaris ограничение было около 3,5 ГБ с момента выпуска Solaris 2.5. (около 10 лет назад)

У меня были те же проблемы с JVM, что и в App Inventor для Android Blocks Editor. Он устанавливает кучу на 925 м макс. Этого недостаточно, но я не мог установить его более чем на 1200 м, в зависимости от различных случайных факторов на моей машине.

Я скачал Nightly, бета-64-битный браузер от Firefox, а также 64-битную версию JAVA 7.

Я еще не нашел свой новый предел кучи, но я только что открыл JVM с размером кучи 5900 м . Нет проблем!

Я использую 64-разрядную версию Win 7 на компьютере с 24 ГБ ОЗУ.

Я попытался установить размер кучи до 2200M на 32-битной машине Linux, и JVM работала нормально. JVM не запускалась, когда я установил его на 2300M.

Еще один момент для горячей точки 32-битной JVM: - собственная емкость кучи = 4 гигабайта & # 8211; Java Heap - PermGen;

Это может быть особенно сложно для 32-битной JVM, поскольку Java Heap и native Heap находятся в гонке. чем больше ваша куча Java, тем меньше собственная куча. Попытка настроить большую кучу для 32-битной виртуальной машины например, 2,5 ГБ + увеличивает риск нативной ошибки OutOfMemoryError в зависимости от области применения вашего приложения, количество потоков и т. д.

Теоретические 4 ГБ, но на практике (для IBM JVM):

Win 2k8 64, IBM Websphere Application Server 8.5.5 32-битный

C:\IBM\WebSphere\AppServer\bin>managesdk.bat -listAvailable -verbose CWSDK1003I: Доступные SDK: CWSDK1005I: Имя SDK: 1.6_32 - com.ibm.websphere.sdk.version.1.6_32=1.6 - com.ibm.websphere.sdk.bits.1.6_32=32 - com.ibm.websphere.sdk.location.1.6_32=${WAS_INSTALL_ROOT}/java - com.ibm.websphere.sdk.platform.1.6_32=windows - com.ibm.websphere.sdk.architecture.1.6_32=x86_32 - com.ibm.websphere.sdk.nativeLibPath.1.6_32=${WAS_INSTALL_ROOT}/lib/native/win /x86_32/ CWSDK1001I: Задача managesdk выполнена успешно. C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2036 MaxMemory JVMJ9GC017E -Xmx слишком мала, должна быть не меньше 1 M байт JVMJ9VM015W Ошибка инициализации для библиотеки j9gc26(2): Не удалось инициализи ровать Could not create the Java virtual machine. C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2047M MaxMemory Total Memory: 4194304 (4.0 MiB) Max Memory: 2146435072 (2047.0 MiB) Free Memory: 3064536 (2.9225692749023438 MiB) C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2048M MaxMemory JVMJ9VM015W Ошибка инициализации для библиотеки j9gc26(2): Не удалось создать эк земпляр кучи; запрошено 2G Could not create the Java virtual machine.

RHEL 6.4 64, IBM Websphere Application Server 8.5.5 32-битный

[bin]./java -Xmx3791M MaxMemory Total Memory: 4194304 (4.0 MiB) Max Memory: 3975151616 (3791.0 MiB) Free Memory: 3232992 (3.083221435546875 MiB) [root@nagios1p bin]# ./java -Xmx3793M MaxMemory Total Memory: 4194304 (4.0 MiB) Max Memory: 3977248768 (3793.0 MiB) Free Memory: 3232992 (3.083221435546875 MiB) [bin]# /opt/IBM/WebSphere/AppServer/bin/managesdk.sh -listAvailable -verbose CWSDK1003I: Available SDKs : CWSDK1005I: SDK name: 1.6_32 - com.ibm.websphere.sdk.version.1.6_32=1.6 - com.ibm.websphere.sdk.bits.1.6_32=32 - com.ibm.websphere.sdk.location.1.6_32=${WAS_INSTALL_ROOT}/java - com.ibm.websphere.sdk.platform.1.6_32=linux - com.ibm.websphere.sdk.architecture.1.6_32=x86_32 -com.ibm.websphere.sdk.nativeLibPath.1.6_32=${WAS_INSTALL_ROOT}/lib/native/linux/x86_32/ CWSDK1001I: Successfully performed the requested managesdk task.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top