2012-05-13 7 views
10

Tengo 7 daemons de Java diferentes que corro (los 7) en 3 servidores diferentes. La línea de comandos de java tiene -Xmx2048m y -Xss1024k. En estos 3 servidores, los 21 procesos muestran poco menos de 2,5 GB para tamaño VIRT en la parte superior y superior. El tamaño RES varía de 300 a 1.9 GB según el daemon que sea.¿Qué causaría que un proceso de Java excediera en gran medida el límite Xmx o Xss?

Eso es todo lo que debería ser.

Ingrese el nuevo servidor. CPU más rápida, más RAM (16 GB en lugar de 8 GB), Java un poco más nuevo (1.6.0_10-b33 en los servidores antiguos, 1.6.0_31-b04 en el nuevo servidor). Ambos sistemas (y JVM) son de 64 bits.

Movió 2 de los daemons al nuevo servidor. En el nuevo servidor, dada la misma tarea, los daemons consumen mucho más CPU (aproximadamente el valor de un núcleo) y obtienen Less. (Movido desde 5110 procesadores en los sistemas antiguos a 5620 en el nuevo).

Más o menos un núcleo extra completo de uso de CPU (GC thread ??) y reporta 5 GB VIRT y 2 GB RES para un daemon y 10.5 GB VIRT y 2 GB RES para el otro daemon.

¿Alguna idea de lo que causaría que java ignore (o parezca ignorar si ese es el caso) los límites de memoria?

+0

VIRT es la memoria virtual, que no tiene relación directa con el espacio del montón. Recomiendo leer las respuestas a esta pregunta: http://stackoverflow.com/questions/4893192/process-memory-vs-heap-jvm –

+0

¿Intentó con la misma versión de Java en la máquina nueva? ¿Son ambos los mismos bit-ness? –

+0

'Xmx' no especifica el uso de memoria de la JVM; especifica el tamaño máximo del conjunto de asignación de montón, que es solo uno de los grupos de memoria utilizados por la JVM. – skaffman

Respuesta

8

Resulta que este es un problema de glibc.

La respuesta corta para mí fue:

exportación MALLOC_ARENA_MAX = 1

Esta disminución de la huella de proceso (VIRT en la parte superior) por tanto como 5x. Volver a los niveles observados en CentOS 5.

Las versiones recientes de glibc tienen una nueva función de "grupos de memoria por hilo":

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

El último elemento de la sección 1.71.1 registro se discute (y se refiere a un error no público ...)

+2

Es posible que desee establecer MALLOC_ARENA_MAX en 4 en lugar de 1, para obtener algunos de los beneficios de la memoria de subprocesamiento múltiple que el cambio intentaba abordar. Vea esto: issues.apache.org/jira/browse/HADOOP-7154 – michael

Cuestiones relacionadas