Максимальний розмір купи Java 32-розрядного JVM в 64-бітній ОС

Питання полягає не в максимальному розмірі купи в 32-розрядовій ОС, враховуючи, що 32-бітні ОС мають максимальний розмір адресної пам’яті 4 ГБ, і що максимальний розмір купі JVM залежить від того, наскільки може бути зарезервовано безперервна вільна пам'ять.

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

Щодо того, чому 32-розрядний JVM використовується замість 64-розрядного, причина не технічна, а швидше адміністративна / бюрократична - це, мабуть, занадто пізно, щоб встановити 64-розрядний JVM у виробничих умовах.

32-розрядні JVM, які очікують, що матимуть один великий фрагмент пам'яті та використовують необроблені покажчики, не можуть використовувати більше 4 Гбіт (оскільки це 32-бітний ліміт, який також стосується покажчиків). Сюди входить Sun і - я майже впевнений - також реалізації IBM. Я не знаю, чи є, наприклад, JRockit або інші великі опції пам'яті з їх 32-бітними реалізаціями.

Якщо ви очікуєте досягнення цієї межі, вам слід настійно розглянути можливість запуску паралельної доріжки, що підтверджує 64-розрядний JVM для вашого виробничого середовища, щоб ви були готові до того, коли 32-бітове середовище вийде з ладу. Інакше вам доведеться виконувати цю роботу під тиском, що ніколи не буває приємним.

Редагувати 2014-05-15: поширені запитання Oracle:

Максимальний теоретичний межа купи для 32-розрядного JVM становить 4G. Через різні додаткові обмеження, такі як доступний своп, використання простору адреси ядра, фрагментація пам'яті та накладні витрати на VM, на практиці ліміт може бути значно нижчим. У більшості сучасних 32-бітних систем Windows максимальний розмір купи буде варіюватися від 1,4 до 1,6 г. Для 32-розрядних ядер Solaris адресний простір обмежений 2G. У 64-бітних операційних системах, що працюють з 32-розрядним VM, максимальний розмір купи може бути більшим, наближаючись до 4G у багатьох системах Solaris.

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

Ви можете запитати Java Runtime:

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(на HotSpot ). Я виявив, що, працюючи на 64-розрядному Windows 7 Enterprise, мій 32-розрядний HotSpot JVM може виділити до 1577MiB:

[C: подряпин]> java -Xmx1600M MaxMemory
Під час ініціалізації VM сталася помилка
Не вдалося зарезервувати достатньо місця для купи об’єктів
Не вдалося створити віртуальну машину Java.
[C: подряпин]> java -Xmx1590M MaxMemory
Загальна пам’ять: 2031616 (1.9375 МіБ)
Максимальна пам'ять: 1654456320 (1577,8125 МіБ)
Вільна пам'ять: 1840872 (1.75559234619 МіБ)
[С: подряпина]>

Якщо з 64-бітним JVM на одній ОС, звичайно, він набагато вище (приблизно 3TiB)

[C: подряпин]> java -Xmx3560G MaxMemory
Під час ініціалізації VM сталася помилка
Не вдалося зарезервувати достатньо місця для купи об’єктів
[C: подряпин]> java -Xmx3550G MaxMemory
Загальна пам'ять: 94240768 (89,875 МіБ)
Максимальна пам'ять: 3388252028928 (3184151.84297 МіБ)
Вільна пам'ять: 93747752 (89.4048233032 МіБ)
[С: подряпина]>

Як вже згадували інші, це залежить від ОС.

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

Для 64-розрядної хост-ОС, якщо JVM є 32-розрядною, вона все ще буде залежати, швидше за все, як і вище, як показано.

- ОНОВЛЕННЯ 20110905 : Я просто хотів зазначити деякі інші спостереження / деталі:

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

Ви не вказуєте, яка ОС.

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

Ми перенесли додаток в Linux, і ми працюємо на 32-бітовому JVM на 64-бітному апаратному забезпеченні, і 2,2 Гб VM працює легко.

Найбільшою проблемою у вас може бути GC залежно від того, для чого ви використовуєте пам'ять.

З 4.1.2 Розміри купи :

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

Тут ми знайшли досить гарну відповідь: максимальна пам'ять Java в Windows XP .

Нещодавно ми мали з цим певний досвід. Нещодавно ми перенесли з Solaris (x86-64 версія 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 = 512м без проблем на Solaris протягом останніх кількох років. Спробували перенести його на Linux, і у нас виникли проблеми із випадковими помилками пам'яті при запуску. Ми могли отримати його лише для послідовного запуску на -Xms2300 -Xmx2300 . Тоді нам про це повідомили підтримку.

32-бітний процес в Linux має максимальний адресний простір 3gb (3072mb), тоді як для Solaris - повний 4gb (4096mb).

Обмеження 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:

1. Додаток маніпулював кількома масивними зображеннями,
2. Додаток робив величезне скорочення кількості,
3. У програмі було витоку пам’яті, замовник був головним урядовим контрактом, і вони не хотіли витрачати час і витрати на відстеження витоку пам’яті. (Використання масивної маси пам’яті призведе до збільшення MTBF, а прем'єр-міністр все одно буде платити)

.

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

http://blogs.oracle.com/jrockit/entry/how_to_get_almost_3_gb_heap_on_windows

JVM можна безкоштовно завантажити (необхідна реєстрація) за адресою

http://www.oracle.com/technetwork/middleware/jrockit/downloads/index.html

Ось декілька тестувань на 64-розрядні версії Solaris та Linux

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

BTW: Мабуть, Java не виділяє багато фактичної пам'яті при запуску. Здавалося, що зайнято лише близько 100 Мбайт за екземпляр (я почав 10)

Solaris 10 - x86 - VMWare VM з 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-бітовій, так що загальне поліпшення приблизно в 2 рази .

Для Solaris ліміт становить приблизно 3,5 Гб з моменту Solaris 2.5. (близько 10 років тому)

У мене були ті ж проблеми з JVM, який використовує App Inventor для редактора блоків Android. Він встановлює купу в максимум 925 м. Цього недостатньо, але я не міг встановити його більше ніж на 1200 м, залежно від різних випадкових факторів на моїй машині.

Я завантажив бета-версію 64-розрядного браузера з Firefox, а також 64-бітну версію JAVA 7.

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

Я працюю Win 7 64-бітний Ultimate на машині з 24 Гб оперативної пам’яті.

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

Це важка настройка, але ви можете отримати 3gb купу.

http://www.microsofttranslator.com/bv.aspx?from=&to=en&a=http://forall.ru-board.com/egor23/online/FAQ/Virtual_Memory/Limits_Virtual_Memory.html

ще один момент для точки доступу 32-розрядного JVM: - ємність накопичувача купи = 4 Gig - Java Heap - PermGen;

Це може бути особливо складним для 32-розрядного JVM, оскільки Java Heap та нативні Heap перегони. Чим більша ваша Java Heap, тим менша рідна купа. Спроба встановити велику купу для 32-бітного VM, наприклад .2,5 ГБ + збільшує ризик виникнення вродженого OutOfMemoryError залежно від вашої програми (додатків), кількості потоків тощо.

Обмеження також випливає з того, що для 32 bitVM heapсам повинен починатися з нульової адреси, якщо ви хочете, щоб усі ці4GB .

Подумайте, якщо ви хочете щось посилатись через:

0000....0001

тобто: посилання, яке має саме це бітове представлення, означає, що ви намагаєтеся отримати доступ до першої пам'яті з купи. Щоб це було можливо, купа повинна починатися з нульової адреси. Але цього ніколи не відбувається, воно починається з деякого зміщення від нуля:

    | ....               .... {heap_start .... heap_end} ... |
 --> (this can't be referenced) <--

Оскільки купа ніколи не починається з нульової адреси в an OS, існує досить багато бітів, які ніколи не використовуються з 32посилання на біти, і як така купа, на яку можна посилатися, є нижчою.

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

Win 2k8 64, 32-бітний сервер застосунків IBM Websphere 8.5.5

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 32bit

[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.