RSS/VSS sont en croissance jusqu'à ce que toute la mémoire et échanger sur la machine se termine

Question

Nous avons un serveur weblogic 9.2 avec Java1.5.0.16 sur RHEL5.3 que nous déployons sur lui un service web et un système de gestion de contenu Alfresco. Nous fonctionnions correctement depuis ~ 3 ans sur HP-UX i11.23 et il y a un mois, nous avons migré vers Linux RH5.3 et de temps en temps (c'est arrivé 3 fois), nous avons remarqué que le processus commençait à utiliser de plus en plus de mémoire jusqu'à ce que toute la mémoire et échanger sur la machine se termine.

Le processus fonctionne toujours correctement et tous les fichiers journaux semblent normaux (comme si rien ne s'était passé), y compris le journal GC.

Glance for process ID 25450: 

B0000A Glance C.04.70.000 06:54:05 supra2 x86_64 Current Avg High 
CPU Util SU | 2% 2% 2% 
Disk Util D D | 97% 97% 97% 
Mem Util U U | 98% 98% 98% 
Swap Util U U | 60% 60% 60% 
Resources PID: 25450, java PPID: 25394 euid: 664 User:afspr04 
CPU Usage (util): 5.40 Total RSS : 40.6gb 
User CPU : 3.60 Text VSS : 56kb 
System CPU : 1.80 Data VSS : 66.1gb 
Priority : 15 Stack VSS : 2.0mb 
Nice Value : 0 Total VSS : 66.5gb 
Blocked On : SLEEP 
Major Faults : 235 
Minor Faults : 164 
Processor : 1 
Argv1: weblogic.Server 
Cmd : /opt/java1.5.0_16/bin/java -Dweblogic.Name=dmcmsserver -Doracle.net.tns_admin=/etc -server -javaagent:/opt/MercuryDiagn 
ostics/JavaAgent/DiagnosticsAgent/lib/probeagent.jar -Dprobe.id=supra2_afspr04_dmcms_ear_p4 -Dprobe.group=CMS_SERVER -D 
points.file.name=/opt/MercuryDiagnostics/JavaAgent/DiagnosticsAgent/etc/supra2_afspr04_dmcms_ear_p4 -Dcom.wily.introsco 
pe.agent.agentName=DMCMS -Xms7g -Xmx7g -XX:PermSize=256m -XX:MaxPermSize=256m -XX:NewSize=1792m -XX:MaxNewSize=1792m -X 
X:SurvivorRatio=4 -XX:TargetSurvivorRatio=90 -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Xnoclassg 
c -Xloggc:logs/gc.log -Doracle.net.tns_admin=/etc -Dweblogic.Stderr=/app/afspr04/dmcms_ear_p4/dmcmsdomain/logs/online.l 
og -Dweblogic.Stdout=/app/afspr04/dmcms_ear_p4/dmcmsdomain/logs/online.log -Damdocs.system.home=/app/afspr04/dmcms_ear_ 
p4/properties/jesi -Damdocs.messageHandling.home=/app/afspr04/dmcms_ear_p4/properties/jesi -Djesi.config.loader=amdocs. 
ecommerce.esi.utils.config.InterfaceConfigXPathLoader -Damdocs.uams.config.resource=config/mvc/ldap ... 

pmap montre la grande allocation comme anonyme pmap (triés par ordre alphabétique grande fois):

25450: /opt/java1.5.0_16/bin/java -Dweblogic.Name=dmcmsserver -Doracle.net.tns_admin=/etc -server -javaagent:/opt/MercuryDiagnostics/JavaAgent/DiagnosticsAgent/lib/probeagent.jar -Dprobe.id=supra2_afspr04_dmcms_ear_p4 -Dprobe.group=CMS_SERVER -Dpoints.file.name=/opt/MercuryDiagnostics/JavaAgent/DiagnosticsAgent/etc/supra2_afspr04_dmcms_ear_p4 -Dcom.wily.introscope.agent.agentName=DMCMS -Xms7g -Xmx7g -XX:PermSize=256m -XX:MaxPermSize=256m -XX:NewSize=1792m -XX:MaxNewSize=1792m -XX:SurvivorRatio=4 -XX:TargetSurvivo 
00002ab0f8000000 10518548 rwx-- [anon] 
00002ab798009000 8388612 rwx-- [anon] 
000000005fcce000 8038976 rwx-- [anon] 
00002aac7aab0000 7602176 rwx-- [anon] 
00002aaf74000000 5259284 rwx-- [anon] 
00002ab688000000 4194308 rwx-- [anon] 
00002aae4b930000 1684124 rwx-- [anon] 
00002aab80000000 1314836 rwx-- [anon] 
00002aab20000000 655376 rwx-- [anon] 
00002aac28000000 532488 rwx-- [anon] 
00002aac50000000 524292 rwx-- [anon] 
00002aaaec000000 327696 rwx-- [anon] 
00002aaad8000000 131088 rwx-- [anon] 
00002ab658000000 131060 rwx-- [anon] 
00002ab0dc000000 131044 rwx-- [anon] 
00002aaacc2f5000 114708 rwx-- [anon] 
... 
total 69733292K 

Avez quelqu'un a rencontré quelque chose de semblable?

Merci, Oz

Answer 1

Quelle est la CPU/RAM du serveur que vous utilisez? Vous devriez consulter le RHEL compatibility matrix for WLS 9.2 et vous assurer que votre configuration JDK/CPU est une combinaison prise en charge. En outre, puisque vous pourriez envisager JRockit comme votre JVM si c'est une option pour vous. Enfin, essayez également d'abaisser l'espace de tas maximum (-Xmx et -Xms) et de voir si le serveur est plus stable.

Answer 2

Nous avons le même genre de problèmes ici avec un OS différent (Sun Solaris 10 - 32bit) mais je vois un point commun: l'Introscope.

Nous avons suspecté d'allouer trop de mémoire (fuite de mémoire?) Car elle utilise une bibliothèque native (* .so accédée via JNI). Pour comprendre ce que je veux dire, il y a quelque chose que je dois clarifier dans ce cas concernant la mémoire du processus JVM: toute la mémoire du processus Java est divisée en deux parties différentes, l'une native et l'autre Java.

La mémoire de la partie Java (celle gérée par Garbage Collector) peut être surveillée via l'API JVM standard. Rappelez-vous simplement que Java ne peut surveiller que cette partie de la mémoire du processus JVM. Il contient le tas (eden & 2 survivants), oldgen, permgen. Cette partie de la mémoire est généralement la plus grande, c'est pourquoi il existe des moyens de la surveiller, alors qu'il n'y en a pas pour le reste.

Le reste de la mémoire du processus, la partie native, est différente. Il est constitué des sockets/tampons réseau, des descripteurs/tampons de fichiers, des structures de données et des tampons GC, des tampons de bibliothèques natives, du code natif compilé par le compilateur JIT et d'autres éléments spécifiques de JVM internes. Il y a aussi le code exécutable de la JVM et les bibliothèques natives. Il n'y a généralement pas de moyen standard (souvent pas du tout) de regarder dans cette partie, sauf à l'aide d'un débogueur.

Après avoir demandé à C & A propos de lib natif de Wily/Introscope, ils nous ont expliqué que:

• alloue de la mémoire dynamique;
• il n'y a aucun moyen de limiter sa consommation de mémoire;
• il n'y a aucun moyen de prédire sa consommation de mémoire;
• il est utilisé par Wily uniquement pour collecter les mesures spécifiques du système sous-jacent (par ex.Drapeaux d'OS, charge CPU, mémoire libre totale, nombre de processus, ...), car Introscope utilise l'API Java Agent pour tout le reste.

Pour 99% des applications, la partie "native" de la mémoire (la partie non-Java) est négligeable par rapport à la partie Java. Mais ici, avec l'Introscope dans notre jeu, les choses deviennent différentes car la partie native peut devenir arbitrairement grande et manger l'espace mémoire du processus jusqu'aux limites.

Nous avons conclu ici que ces valeurs spécifiques au système ne sont pas très intéressantes pour nous - et je pense que c'est le cas pour beaucoup d'entre vous puisqu'il existe d'autres façons de les obtenir: mem, free, top, taskmanager, .. - Alors nous avons décidé de l'enlever. Simplement.

Je crois que c'est la meilleure option. Essayez-le et dites-nous si cela a résolu vos problèmes de mémoire.