Java OutOfMemory проблема - дамп кучи 800 МБ меньше, чем настроена максимальная куча - PullRequest
2 голосов
/ 18 марта 2011

У меня есть веб-приложение, развернутое на сервере Oracle App Server 10.1.3, в oc4j, запущенном с начальной кучи 1 ГБ и максимальной кэш-памятью 2 ГБ, на RHEL на 32-битной, настроенной на просмотр 32 ГБ ОЗУ.В последнее время я сталкивался с ошибками OutOfMemory, поэтому я настроил приложение для создания дампов кучи в OutOfMem.Таким образом, у меня есть 4-5 дампов кучи, каждый размером не более 1,2 Гб (так что 800 Мб меньше максимального размера кучи).Кроме того, при бесплатной загрузке на компьютере в среднем часы показывают около 20 ГБ свободной памяти.

Означает ли это, что приложение пытается выделить 800 МБ за один раз?Или, если есть 2 или более потоков, которые пытаются выделить память одновременно, они оба перестают работать, даже если, скажем, есть память для каждого, но не для суммы обоих?Может ли быть pb с машиной Linux, может быть, он не может дать память для Java?Может ли быть фрагментирована память, может быть, конфигурация, которая позволяет 32-битной машине видеть 32 Гб оперативной памяти, имеет pb?

(я должен отметить, что приложение не изменилось в последнее время, но на этой машине новаяoc4j и новое приложение было развернуто laely, и это съедает 1-2 г оперативной памяти)

Ответы [ 2 ]

2 голосов
/ 18 марта 2011

На большинстве 32-битных машин (включая большинство разновидностей linux) максимальный объем памяти, который может выделить ваш процесс, составляет около 2G .Теперь, если вы скажете, что ваша куча принимает 1.2G , то в худшем случае я бы предположил, что ваш perm gen съедает остаток 800M . Попробуйте установить -XX: MaxPermSize = 200M и проверьте.

0 голосов
/ 18 марта 2011

Я думаю, что ваша проблема в том, что вы выделяете размер кучи 1G-2G для всего сервера приложений. Он потребляет некоторую память сам по себе, не уверен, сколько. Но если вы запустите сервер приложений с максимальной памятью 2 ГБ, для вашего веб-приложения определенно будет доступно менее 2 ГБ.

...