¿Cómo puede un proceso de Java con -Xmx1024m ocupar 3 GB de memoria residente?

Question

Es una aplicación web Java en Websphere6.1, Solaris 10, JDK 1.5.0_13. Establecemos el tamaño máximo de almacenamiento dinámico en 1024 m. jmap muestra que el estado del montón es saludable. El uso de la memoria del montón es solo del 57%. Sin OutOfMemory en absoluto.

Pero vimos RSS muy alto (3GB) para este proceso de java de ps. pmap muestra un bloque de memoria privada 1.9G.

 
3785: /dmwdkpmmkg/was/610/java/bin/java -server -Dwas.status.socket=65370 -X 
Address Kbytes  RSS Anon Locked Pgsz Mode Mapped File 
... 
0020A000 2008 2008 2008  - 8K rwx-- [ heap ] 
00400000 1957888 1957888 1957888  - 4M rwx-- [ heap ] 
8D076000  40  40  40  - 8K rw--R [ stack tid=10786 ] 
... 

¿Es una pérdida de memoria de montón C en código nativo? ¿Qué enfoque se recomienda para descubrir la causa raíz?

Answer 1

Este Troubleshooting Memory Leaks documento de Sun puede ayudarlo a encontrar el problema de por qué su alto RSS, especialmente en la sección 3.4.

Como está ejecutando Websphere, tal vez pueda usar el -memorycheck en su máquina virtual. Para más detalles, vea here.

No es necesariamente una fuga en el código nativo. Si mira here, en Solaris podría haber un problema con los archivos que se mantienen abiertos.

Es solo un montón de enlaces y consejos, pero tal vez útil para rastrear su problema.

Answer 2

¿Está utilizando las bibliotecas JNI? No estoy seguro de cómo el código nativo asigna RAM pero ahí es donde comenzaría a buscar.

Answer 3

El tamaño del almacenamiento dinámico es el tamaño del almacenamiento dinámico de Java, todavía hay la máquina virtual y otras bibliotecas que son parte del proceso.

Intenta ejecutar Hello World con un tamaño de almacenamiento dinámico de 1024m y un "para (;;)" y ver cuánto ocupa. Eso debería darte una referencia para el uso general de la memoria.

Answer 4

Esto puede suceder incluso cuando no hay una pérdida de memoria nativa (como recursos zip no abiertos).

Corrí hacia el mismo problema. Este es un problema conocido con glibc> = 2.10

La cura es establecer esta variable env export MALLOC_ARENA_MAX=4

artículo de IBM acerca de la configuración MALLOC_ARENA_MAX https://www.ibm.com/developerworks/community/blogs/kevgrig/entry/linux_glibc_2_10_rhel_6_malloc_may_show_excessive_virtual_memory_usage?lang=en

Google para MALLOC_ARENA_MAX o buscar en lo que encontrar muchas referencias

Es posible que desee ajustar también otras opciones para optimizar malloc de baja fragmentación de memoria asignada:

# tune glibc memory allocation, optimize for low fragmentation 
# limit the number of arenas 
# requires glibc >= 2.16 since there was a bug in 
# MALLOC_ARENA_TEST parameter handling that cause MALLOC_ARENA_MAX not to work 
export MALLOC_ARENA_MAX=2 
# disable dynamic mmap threshold, see M_MMAP_THRESHOLD in "man mallopt" 
export MALLOC_MMAP_THRESHOLD_=131072 
export MALLOC_TRIM_THRESHOLD_=131072 
export MALLOC_TOP_PAD_=131072 
export MALLOC_MMAP_MAX_=65536 

Usted puede llamar a la función nativa malloc_info para obtener información acerca de las asignaciones de memoria. Aquí hay un ejemplo de using JNA to call the native malloc_info method.