JVM Crash для увеличения размера ОЗУ в приложении

Question

У меня есть одно приложение, которое работает нормально в обычной системе с 4   ГБ оперативной памяти, но когда я устанавливаю свою оперативную память на 12   ГБ, система выходит из строя, и мне нужно перезапустить заявление.

Должен ли я устанавливать параметры ядра вручную для изменений в ОЗУ?

Детали операционной системы и дампе приводится ниже

OS

Linux manage 2.6.39.4-1smp #19 SMP Tue Nov 27 18:47:20 IST 2012 i686 unknown 

Сбой в/вар/Журнал/сообщения

Mar 06 16:43:39 1425640419 kernel: Pid: 29750, comm: java Tainted: G  W 2.6.39.4-1smp #19 
Mar 06 16:43:39 1425640419 kernel: Call Trace: 
Mar 06 16:43:39 1425640419 kernel: [<c105e36f>] bad_page+0xb4/0xcd 
Mar 06 16:43:39 1425640419 kernel: [<c105f6e8>] get_page_from_freelist+0x303/0x488 
Mar 06 16:43:39 1425640419 kernel: [<c105f9e2>] __alloc_pages_nodemask+0xe2/0x525 
Mar 06 16:43:39 1425640419 kernel: [<c106195d>] ? ____pagevec_lru_add_fn+0xa0/0xa6 
Mar 06 16:43:39 1425640419 kernel: [<c107d0c0>] alloc_pages_vma+0x15b/0x164 
Mar 06 16:43:39 1425640419 kernel: [<c106d477>] do_wp_page+0x402/0x686 
Mar 06 16:43:39 1425640419 kernel: [<c106df1e>] handle_pte_fault+0x823/0x879 
Mar 06 16:43:39 1425640419 kernel: [<c106ee53>] handle_mm_fault+0x159/0x16b 
Mar 06 16:43:39 1425640419 kernel: [<c101a868>] ? mm_fault_error+0xc9/0xc9 
Mar 06 16:43:39 1425640419 kernel: [<c101ab80>] do_page_fault+0x318/0x330 
Mar 06 16:43:39 1425640419 kernel: [<c101a868>] ? mm_fault_error+0xc9/0xc9 
Mar 06 16:43:39 1425640419 kernel: [<c1228f72>] error_code+0x5a/0x60 
Mar 06 16:43:39 1425640419 kernel: [<c101a868>] ? mm_fault_error+0xc9/0xc9 
Mar 06 16:43:39 1425640419 kernel: Disabling lock debugging due to kernel taint 
Mar 06 16:43:39 1425640419 kernel: BUG: Bad page state in process java pfn:bf081 
Mar 06 16:43:39 1425640419 kernel: page:f25e3020 count:0 mapcount:0 mapping:00b40000 index:0x0 
Mar 06 16:43:39 1425640419 kernel: page flags: 0x10a30000(swapcache|mappedtodisk|mlocked) 
search hit BOTTOM, continuing at TOP 

Answer 1

Ну, Я думаю, что может быть несколько вопросов, возможно, не r приподнятый на Java. Я поставил их в порядок самых простых и самых сложных, а не в наименее вероятных.

1)

Если у вас есть ровно 12   ГБ оперативной памяти, уменьшить выделение виртуальной машины Java. Может быть, какая-то передышка поможет.

2)

Во-первых, убедитесь, что это не/проблема ограничения безопасности. Проверка:

/etc/security/limits.conf 

Конкретно искать предел memlock. Memlock резервирует ОЗУ для акций, которые могут быть или не быть применимыми к вашей системе. Если Memlock установлен слишком высоко, возможно, существует какой-то странный конфликт. Следуйте правилу:

Свободной память (распределяемой) = установленное ОЗУ - 2 Гб - Memlock

3)

Если вы используете программное обеспечение для виртуализации (VirtualBox и несколько других), this модуля который, как известно, испортил ядро. Если он присутствует, удалите его и проверьте, исправлена ​​ли проблема.

4)

Это может быть вызвано аппаратными проблемами. Серверы могут работать в течение нескольких дней даже недель, пока авария не произойдет из-за (незначительной) аппаратной проблемы. Запустите memtest и удалите все плохие палочки RAM. Я помню, как читал статью о сервере, который разбивался бы каждые 30 дней с JavaEE. Через несколько месяцев парень проверил memtest и обнаружил плохую RAM-палку. Он был заменен, и аварии прекратились.

5)

Пробег:

lsmod 

И искать что-нибудь из обычных, особенно проприетарных драйверов. Обычно они являются виновниками ядовитых красок. Удалите их, если это возможно.

6)

Если вы получили сюда, я боюсь, вам придется сделать некоторые дополнительные рыть, чтобы найти причину заразы. Почти всегда ошибка вызвана не совместимым с GPL модулем ядра. Это должно быть вне области JVM (если у вас нет плагина). Проверьте this статью для поиска и разрешения проблем с ядром.

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