Ошибки JVM после обновления до Java 6 Update 14

Я получаю некоторые странные ошибки (возможно, один раз в день) после обновления нескольких серверов для запуска на Java 6 с обновлением 14.

Ошибки похожи на

#
# A fatal error has been detected by the Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 1759920 bytes for Chunk::new. Out of swap space?
#
#  Internal Error (allocation.cpp:215), pid=26706, tid=317545360
#  Error: Chunk::new
#
# JRE version: 6.0_14-b08
# Java VM: Java HotSpot(TM) Server VM (14.0-b16 mixed mode linux-x86 )
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

Как ни странно, текущий поток является компилятором

  0x088a0800 JavaThread "CompilerThread1" daemon [_thread_blocked, id=26716, stack(0x12c7f000,0x12d00000)]
=>0x0889e400 JavaThread "CompilerThread0" daemon [_thread_in_native, id=26715, stack(0x12e55000,0x12ed6000)]

и памяти более чем достаточно:

отвал

 PSYoungGen      total 256064K, used 93533K [0xa2cd0000, 0xb4290000, 0xb4290000)
  eden space 228352K, 31% used [0xa2cd0000,0xa72d6308,0xb0bd0000)
  from space 27712K, 78% used [0xb2780000,0xb3cd1150,0xb4290000)
  to   space 28032K, 0% used [0xb0bd0000,0xb0bd0000,0xb2730000)
 PSOldGen        total 2275584K, used 885858K [0x17e90000, 0xa2cd0000, 0xa2cd0000)
  object space 2275584K, 38% used [0x17e90000,0x4dfa8bf8,0xa2cd0000)
 PSPermGen       total 32128K, used 27819K [0x13e90000, 0x15df0000, 0x17e90000)
  object space 32128K, 86% used [0x13e90000,0x159bac50,0x15df0000)

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

 akarnokd09 июл. 2009 г., 10:47
Решение состоит в том, чтобы вернуться к предыдущей версии Java. Отправьте это сообщение об ошибке в Sun.
 Robert Munteanu09 июл. 2009 г., 11:14
Да, это то, что я говорю.
 Vinay Sajip09 июл. 2009 г., 11:03
Ты говоришьdidn't подать это с Sun?
 Robert Munteanu09 июл. 2009 г., 10:56
У меня был плохой опыт работы с отчетами о сбоях JVM - даже через несколько месяцев он не появлялся в общедоступной базе данных об ошибках. Вот почему я спрашиваю здесь.
 akarnokd09 июл. 2009 г., 11:28
Вы не можете сделать многое, так как кажется, что ошибка является специфической для Linux ошибкой jvm. Вы можете попробовать переключиться на другой GC или подождать до 15. Вы также можете попробовать -client, установить привязку процессора к 1 ядру и т. Д.

Ответы на вопрос(1)

Решение Вопроса

которую вы получаете, является не ошибкой кода Java, а скорее проблемой одного из компиляторов Jit. Когда Jit запускается, он захватывает кучу памяти как память для того, что он делает в действительности). Эта память приходит из родной кучи.

Для действительно заинтересованных эта ошибка ультимативно исходит отсюда в ВМ (код C ++ впереди) http://www.google.com/codesearch/p?hl=en&sa=N&cd=1&ct=rc#aRIt9pqzOVI/src/share/vm/utilities/vmError.cpp&q=OutOfMemoryError%20Out% 20of% 20swap% 20space & амп; л = 258 к сожалению, это не «реальный» OutOfMemoryError, он не будет вести себя в соответствии с обычными правилами, его невозможно поймать и т. Д.

Собственные (JNI / JNA) методы могут напрямую выделять память из ОС. NIO напрямую использует память, компилятор горячих точек и другие

Эта память является частью собственной кучи приложений (вещи, которыми управляют malloc и друзья), возможно, в вашем приложении закончилась собственная куча, в результате чего это происходит, посмотрите на общую память на коробке, настройки ulimit и т. Д. Код JNI / JNA также может сыграть в этом некоторую роль, если они способны исчерпать доступную память, которую приложение имеет для нативного кода. Посмотрите на DirectMappedBuffers от NIO, поскольку они также могут украсть память из кучи Java.

Вполне возможно, учитывая, что вы только что обновили информацию о том, что, возможно, вы столкнулись с ошибкой в одном из компиляторов Jit, настройки GC и Jit могут повлиять на это, поэтому попробуйте изменить jit (-client на -server или -server на -client) на Посмотрите, имеет ли это какой-либо эффект, вы также можете попробовать изменить политику GC (однако помните, что вы изменяете политику GC, чтобы изменить ее взаимодействие с JIT, а не исправить проблему с памятью Java).

Вы также можете полностью отключить Jit с помощью флага командной строки -Djava.compiler = NONE, однако, так как это удалит любое генерирование собственного кода, это ухудшит вашу производительность.

Кроме того, если вы где-нибудь разместите аварийный файл hprof, я смогу дать вам еще несколько идей.

 04 авг. 2009 г., 22:08
Вы можете ограничить размер стека Java, если вы думаете, что это проблема с -Xss
 Robert Munteanu30 июл. 2009 г., 23:36
Спасибо за подробный ответ. Я уже обошел эту проблему, ограничив использование потоков внутри приложения. Мне кажется, что размер стека был увеличен между u3 и u14, и из-за этого у нас заканчивается память.

Ваш ответ на вопрос