2012-05-13 10 views
10

Ho 7 diversi daemon java che eseguo (tutti e 7) su 3 server diversi. La riga di comando java ha -Xmx2048m e -Xss1024k. Su questi 3 server, tutti i 21 processi mostrano poco meno di 2,5 GB per le dimensioni VIRT in cima e in cima. La dimensione RES varia da 300 a 1,9 GB in base al demone.Cosa potrebbe causare un processo java per superare di molto il limite Xmx o Xss?

Questo è tutto come dovrebbe essere.

Inserire il nuovo server. CPU più veloce, più RAM (16 GB anziché 8 GB), java leggermente più recente (1.6.0_10-b33 sui vecchi server, 1.6.0_31-b04 sul nuovo server). Entrambi i sistemi (e JVM) sono a 64 bit.

Trasferito 2 dei daemon sul nuovo server. Sul nuovo server, dato lo stesso compito, i demoni consumano molta più CPU (circa il valore di un core) e fanno meno operazioni. (Spostato dai processori 5110 sui vecchi sistemi a 5620 sul nuovo).

Praticamente un nucleo completamente aggiuntivo di utilizzo della CPU (thread GC ??) e segnalazione di VIRT da 5 GB e RES di 2 GB per un daemon e VIRT da 10,5 GB e RES di 2 GB per l'altro daemon.

Qualche idea che cosa potrebbe causare java ignorare (o sembrare ignorare in questo caso) i limiti di memoria?

+0

VIRT è una memoria virtuale, che non ha alcuna relazione diretta con lo spazio dell'heap. Consiglio di leggere le risposte a questa domanda: http://stackoverflow.com/questions/4893192/process-memory-vs-heap-jvm –

+0

Hai provato con la stessa versione di Java sulla nuova macchina? Sono entrambi la stessa bontà? –

+0

'Xmx' non specifica l'utilizzo della memoria della JVM; specifica la dimensione massima del pool di allocazione heap, che è solo uno dei pool di memoria utilizzati da JVM. – skaffman

risposta

8

Risulta che questo è un problema di glibc.

La risposta breve per me era:

export MALLOC_ARENA_MAX = 1

Questa diminuzione processo impronta (VIRT in alto) di ben il 5x. Torna ai livelli visti in CentOS 5.

versioni più recenti di glibc hanno una nuova funzionalità di "pool di memoria per-thread":

http://www.centos.org/docs/5/html/5.4/Technical_Notes/glibc.html

L'ultima voce nella sezione 1.71.1 registro discute (e si riferisce a un bug non pubblico ....)

+2

Potrebbe essere necessario impostare MALLOC_ARENA_MAX su 4 anziché su 1, per ottenere alcuni dei vantaggi della memoria multi-threading a cui era destinato il cambiamento. Vedi questo: issues.apache.org/jira/browse/HADOOP-7154 – michael