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


У нас есть продукт, который работает в настоящее время на 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 или «из-за процесса ehcache» - это может получить меня столько, сколько позволяет аппаратное обеспечение с накладными расходами IPC / сериализации.

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

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

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

Спасибо,


5


источник


Ответы:


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

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


5



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

2 ^ 32 = 4 294 967 296

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


3



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


3