Java: Как использовать кучу за пределами 4 ГБ памяти в 32-битной JVM - PullRequest
Новая
       38

Java: Как использовать кучу за пределами 4 ГБ памяти в 32-битной JVM

5 голосов
/ 10 ноября 2011

У нас есть продукт, который в настоящее время работает на 32-разрядной версии 1.6 JRE.Мы используем Berkeley DB, который потребляет около 2,5 ГБ ОЗУ из 4 ГБ адресного пространства.Это оставляет нам около 750 МБ памяти для адресного пространства JVM.

В настоящее время мы сталкиваемся с проблемами OutOfMemory в текущей настройке.Было бы неплохо увеличить размер кучи JVM до 1,5 ГБ, сохранив при этом 2,5 ГБ для Berkeley DB.Есть ли способ получить доступ к более чем 4 ГБ ОЗУ / куче в 32-разрядной JVM?Я рассмотрел следующие решения
1) использовать JVM, которая делает лучше GC - это даст мне незначительные результаты - я мог бы получить около 50-100 МБ рабочей памяти
2) что-то вроде memcached или "out"of process ehcache "- это может дать мне столько, сколько позволяет аппаратное обеспечение с накладными расходами IPC / сериализации.

Существуют ли другие решения для увеличения адресуемой памяти приложения?

Решение должно работать на Solaris 10. Работает sparc.

* ОБНОВЛЕНИЕ: из-за использования собственных разделяемых библиотек, сейчас мы не можем перейти на 64-битную JVMхотя ОС 64-битная *

спасибо,

Ответы [ 3 ]

5 голосов
/ 10 ноября 2011

Существуют ли другие решения для увеличения адресуемой памяти приложения?

  1. Разделение одного приложения на несколько процессов с не разделяемой памятью (не потоками, а процессами).Первый процесс может запускать БД, а второй - другую часть проекта.Вы можете использовать RMI или разделяемую память или сокеты для связи между процессами.
  2. Меньше памяти, зарезервировано для ОС.Например, на x86-32 PAE позволяет ОС резервировать менее 1 ГБ виртуального адресного пространства объемом 4 ГБ.(например, «разделение 4 ГБ / 4 ГБ», поддерживается в Oracle Linux )
  3. Поместите некоторые данные на диск.Диск может быть RAM-диском для лучшей скорости;или это может быть реальный диск, и ОС будет ускорять доступ к файлам с помощью «кэша страниц».

Кроме того, каждый реальный SPARC (не древний SuperSparc или бедный LION) действительно 64-битный.Так что проще перейти на 64-битную версию ОС.Я не знаю о Solaris, но в Linux можно запускать 32-битные приложения поверх 64-битных ОС.А 64-битная ОС позволит вам запускать 64-битную JVM.

ОБНОВЛЕНИЕ: в Solaris есть диски ramdisk http://wikis.sun.com/display/BigAdmin/Talking+about+RAM+disks+in+the+Solaris+OS, и я думаю, что вы должны попробовать их для хранения базы данных (или временных файлов БД).Не будет дополнительной сериализации / IPC, как в случае (1);только дополнительное чтение / запись или mmap / munmap.Но Ramdisk работает на порядок быстрее, чем SSD, и на 3-4 порядка быстрее, чем HDD.

3 голосов
/ 10 ноября 2011

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

3 голосов
/ 10 ноября 2011

32-разрядные программы не способны обрабатывать более 4 ГБ адресов памяти.У них просто недостаточно битов, чтобы представить больше памяти.

2 ^ 32 = 4 294 967 296

Лучше всего было бы перейти на 64-бит JRE.

...