java.lang.OutOfMemoryError: demande 1958536 octets par Bloc::nouvelles. Hors de l'espace de swap

Nous sommes confrontés au problème ci-dessous à notre production enviournment de manière imprévisible
parfois, le serveur est dans un jour ou parfois dans une semaine, ci-dessous est l'erreur exacte
dump, ci-dessous sont les paramètres pour le serveur.

JDK: jdk1.6.0_21 
Serveur: Tomcat 7.0.2 
Système d'exploitation: Red Hat Enterprise Linux Server version 5.5

Dans catalina.sh le paramètre suivant a été fait:

JAVA_OPTS="-Xms1024M -Xmx1536M -XX:+HeapDumpOnOutOfMemoryError -XX:+AggressiveOpts 
-XX:-DisableExplicitGC  -XX:AdaptiveSizeThroughPutPolicy=0  
-XX:+UsePSAdaptiveSurvivorSizePolicy 
-XX:+UseAdaptiveGenerationSizePolicyAtMinorCollection  
-XX:+UseAdaptiveGenerationSizePolicyAtMajorCollection -XX:PermSize=768M 
-XX:MaxPermSize=768M    -XX:+PrintGCDetails -Xloggc:/tmp/gcLogs.txt"

export CATALINA_OPTS="-Dcom.sun.management.jmxremote.port=22222 
-Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.ssl=false 
-Dcom.sun.management.jmxremote.password.file=/jakarta-tomcat7/apache-tomcat-7.0.2/conf
/jmxremote.password -Dcom.sun.management.jmxremote.access.file=/jakarta-tomcat7/apache-
tomcat-7.0.2/conf/jmxremote.access"

Trace De L'Erreur:-

# 
# Une erreur fatale a été détectée par l'Environnement d'Exécution Java: 
# 
# java.lang.OutOfMemoryError: demande 1958536 octets par Bloc::nouvelles. Hors de l'espace de swap? 
# 
# Erreur interne (répartition.rpc:215), pid=18658, tid=589781904 
# Erreur: Morceau::nouvelles 
# 
# JRE version: 6.0_21-b06 
# Java VM: Java HotSpot(TM) Server VM (17.0-b16 mode mixte linux-x86 ) 
# Si vous souhaitez soumettre un rapport de bogue, veuillez visiter: 
# http://java.sun.com/webapps/bugreport/crash.jsp 
# 

--------------- T H R E A D --------------- 

Thread courant (0x23787400): JavaThread "CompilerThread0" démon [_thread_in_native, id=18668, pile(0x231f5000,0x23276000)] 

Stack: [0x231f5000,0x23276000], sp=0x23272e70, espace libre=1f723276000k 
Cadres natifs: (J=compilé en code Java, j=interprété, Vv=VM code, C=code natif) 
V [libjvm.donc+0x6a9262] 
V [libjvm.donc+0x2b277f] 
V [libjvm.donc+0x12e03c] 
V [libjvm.donc+0x12e536] 
V [libjvm.donc+0x5d67d0] 
V [libjvm.donc+0x2f809d] 
V [libjvm.donc+0x4f65a9] 
V [libjvm.donc+0x27b85f] 
V [libjvm.donc+0x278043] 
V [libjvm.donc+0x209767] 
V [libjvm.donc+0x280f8c] 
V [libjvm.donc+0x280839] 
V [libjvm.donc+0x66feb6] 
V [libjvm.donc+0x66959e] 
V [libjvm.donc+0x57a89e] 
C [libpthread..0+0x5832] 


Actuel CompileTask: 
C2:3230 ! org.apache.jsp.com.common.press_jsp._jspService(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V (4433 octets) 


--------------- P R O C E S S --------------- 

Les Threads Java: ( => thread en cours ) 
0x09a21400 JavaThread "http-8080-exec-904" démon [_thread_in_native, id=17126, pile(SIGTERM: [libjvm.donc+0x57aaf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 
SIGQUIT: [libjvm.donc+0x57aaf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 


--------------- S Y S T E M --------------- 

Système d'exploitation:Red Hat Enterprise Linux Server version 5.5 (Tikanga) 

uname:Linux 2.6.18-194.17.1.el5PAE #1 SMP Mon Sep 20 07:34:07 EDT 2010 i686 
libc:glibc 2.5 2.5 NPTL 
rlimit: PILE 10240k, CORE 0 k, NPROC 114688, NOFILE 1024, COMME l'infini 
charge moyenne:0.39 0.38 0.54 

CPU:au total, 2 (2 cœurs par processeur, 1 threads par noyau) de la famille 6 modèle 15 stepping 11, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3 

De mémoire: 4k page, physique 6228576k(225096k gratuit), swap 6974456k(6974352k gratuit) 

vm_info: Java HotSpot(TM) Server VM (17.0-b16) pour linux-x86 JRE (1.6.0_21-b06), construit sur le 22 Juin 2010 01:04:46 par "java_re" avec gcc 3.2.1-7a (J2SE version) 

temps: Ven Déc 10 14:01:06 2010 
temps écoulé: 79552 secondes

Merci d'avance,
Amit

On dirait que tu es à cours de mémoire
oui, mais il doit être manipulé par la JVM avec plus de grâce. Je voudrais essayer de Java 6u23 qui a une beaucoup plus récente de la JVM. (Je soupçonne un bug dans la JVM) Cependant, vous pouvez trouver qu'il obtient toujours un OOM erreur. Je voudrais prendre un tas de vidage et d'essayer de voir pourquoi vous utilisez beaucoup d'espace. (ou d'augmenter le maximum)
Vous pouvez exécuter la version 64 bits? Vous disposez de 6 Go de mémoire. Vous pouvez essayer de jusqu'à 4 Go max avec la version 64 bits. (Ou pourquoi vous utilisez une grande quantité de mémoire 😉

OriginalL'auteur Amit | 2010-12-14

6

Pour l'enregistrement (et Google), cela ressemble à les deux ces bogues qui ont été résolus dans le 1.6u22 version de sun jdk. Donc, première chose à faire est de mettre à jour votre JVM. Si il arrive encore et toujours ce qui se produit sur une méthode particulière, vous pouvez exclure que la méthode de compilation (aussi longtemps que vous êtes conscient des implications sur les performances de l') avec la jvm suivant drapeau:
```
-XX:CompileCommand=exclude,org/apache/velocity/runtime/directive/Foreach,render
```
(comme l'a suggéré ici). Mais, la première mise à jour de votre jvm.

OriginalL'auteur Bobby Powers
4

Vous êtes en cours d'exécution avec beaucoup de JVM arguments qui affectent la mémoire. Avez-vous essayé empiriquement retrait de chaque option afin de voir lequel est à l'origine de la OOM? Ce OOM n'est pas en venant du tas Java, ça vient de la JVM C propre tas.

D'accord, Il est possible de la Fpo combinaison d'options est le déclenchement d'un bug dans la JVM.

OriginalL'auteur Amir Afghani
3

Comme indiqué par les autres réponses /commentaires, vous êtes à court de mémoire. Compte tenu de votre JVM paramètres, je dirais que la cause est 99% de chances d'être une fuite de mémoire.

Si vous avez fait beaucoup de chaud de les charger dans le serveur Tomcat exemple, il pourrait juste être causée par cette. Chaud de chargement est tristement célèbre pour une fuite de mémoire, et il n'y a pas beaucoup que vous pouvez faire à ce sujet dans la pratique ... sauf quittez et redémarrez votre serveur Tomcat plus souvent.

L'autre possibilité est que votre application est une fuite de mémoire. Si c'est le cas, alors vous aurez besoin d'utiliser un profileur de mémoire pour retracer la fuite.

Le fait que le OOME a provoqué une JVM crash est intéressant, mais probablement pas significative. (Il ressemble à la JVM a été d'essayer de JIT compiler une classe générée à partir d'une page JSP, quand il a couru hors de la mémoire. Le morceau demandé est plutôt grand, mais cela signifie probablement que vous avez une assez grande /compliqué JSP.)

Je pense que cela peut lié à une JVM bug ou d'une compilation JIT problème lors de la compilation d'une grande page JSP

OriginalL'auteur Stephen C

Vous devez vous connecter pour publier un commentaire.