Utilizzo crescente della memoria residente (RSS) del processo Java

La nostra recente osservazione sul nostro sistema di produzione ci dice che l’utilizzo della memoria residente del nostro contenitore Java cresce. Riguardo a questo problema, abbiamo fatto alcune indagini per capire perché il processo java consuma molta più memoria di Heap + Thread Stacks + Oggetti condivisi + Code Cache + etc, usando alcuni strumenti nativi come pmap. Di conseguenza, abbiamo trovato alcuni blocchi di memoria a 64M (in coppia) allocati dal processo nativo (probabilmente con malloc / mmap):

0000000000400000 4K rx-- /usr/java/jdk1.7.0_17/bin/java 0000000000600000 4K rw--- /usr/java/jdk1.7.0_17/bin/java 0000000001d39000 4108K rw--- [ anon ] 0000000710000000 96000K rw--- [ anon ] 0000000715dc0000 39104K ----- [ anon ] 00000007183f0000 127040K rw--- [ anon ] 0000000720000000 3670016K rw--- [ anon ] 00007fe930000000 62876K rw--- [ anon ] 00007fe933d67000 2660K ----- [ anon ] 00007fe934000000 20232K rw--- [ anon ] 00007fe9353c2000 45304K ----- [ anon ] 00007fe938000000 65512K rw--- [ anon ] 00007fe93bffa000 24K ----- [ anon ] 00007fe940000000 65504K rw--- [ anon ] 00007fe943ff8000 32K ----- [ anon ] 00007fe948000000 61852K rw--- [ anon ] 00007fe94bc67000 3684K ----- [ anon ] 00007fe950000000 64428K rw--- [ anon ] 00007fe953eeb000 1108K ----- [ anon ] 00007fe958000000 42748K rw--- [ anon ] 00007fe95a9bf000 22788K ----- [ anon ] 00007fe960000000 8080K rw--- [ anon ] 00007fe9607e4000 57456K ----- [ anon ] 00007fe968000000 65536K rw--- [ anon ] 00007fe970000000 22388K rw--- [ anon ] 00007fe9715dd000 43148K ----- [ anon ] 00007fe978000000 60972K rw--- [ anon ] 00007fe97bb8b000 4564K ----- [ anon ] 00007fe980000000 65528K rw--- [ anon ] 00007fe983ffe000 8K ----- [ anon ] 00007fe988000000 14080K rw--- [ anon ] 00007fe988dc0000 51456K ----- [ anon ] 00007fe98c000000 12076K rw--- [ anon ] 00007fe98cbcb000 53460K ----- [ anon ] 

Interpreto la linea con 0000000720000000 3670016K fa riferimento allo spazio heap, di quale dimensione definiamo usando il parametro JVM “-Xmx”. Subito dopo, iniziano le coppie, di cui la sum è esattamente 64M. Stiamo usando CentOS versione 5.10 (finale) arch 64-bit e JDK 1.7.0_17.

La domanda è: quali sono quei blocchi? Quale sottosistema li assegna?

Aggiornamento: non utilizziamo invocazioni di codice nativo JIT e / o JNI.

Mi sono imbattuto nello stesso problema. Questo è un problema noto con glibc> = 2.10

La cura è di impostare questa variabile env export MALLOC_ARENA_MAX=4

Articolo IBM sull’impostazione di 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=it

Google per MALLOC_ARENA_MAX o cercalo su SO per trovare molti riferimenti.

Potresti voler ottimizzare anche altre opzioni di malloc per ottimizzare la frammentazione bassa della memoria allocata:

 # tune glibc memory allocation, optimize for low fragmentation # limit the number of arenas 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 

È anche ansible che ci sia una perdita di memoria nativa. Un problema comune sono le perdite di memoria native causate dalla mancata chiusura di ZipInputStream / GZIPInputStream .

Un tipico metodo di apertura di ZipInputStream consiste in una chiamata a Class.getResource / ClassLoader.getResource e alla chiamata di openConnection().getInputStream() java.net.URL o chiamando Class.getResourceAsStream / ClassLoader.getResourceAsStream . Bisogna assicurarsi che questi flussi vengano sempre chiusi.

È ansible utilizzare jemalloc per eseguire il debug di perdite di memoria native abilitando il profilo di campionamento malloc specificando le impostazioni nella variabile di ambiente MALLOC_CONF . Istruzioni dettagliate sono disponibili in questo post del blog: http://www.evanjones.ca/java-native-leak-bug.html . Questo post del blog contiene anche informazioni sull’utilizzo di jemalloc per eseguire il debug di una perdita di memoria nativa nelle applicazioni java.

Lo stesso blog contiene anche informazioni su un’altra perdita di memoria nativa relativa a ByteBuffers .