2014-12-12 3 views
3

Java 프로세스의 상주 메모리가 점차 커지는 문제가 있습니다. Xmx는 4096MB로 정의되고 XX는 MaxPermSize = 1536m입니다. 활성 스레드의 수는 ~ 1500이고 Xss는 256K입니다.Jboss (Java) 프로세스에 의한 상주 메모리 사용량이 점차적으로 증가합니다.

응용 프로그램 서버 (JBoss 6.1)가 사용하는 상주 메모리가 시작될 때 ~ 5.6GB (이를 모니터하기 위해 최상위 명령을 사용하고 있습니다)입니다. 커널의 OOM 킬러가 RAM 공간 부족 (서버의 RAM이 9GB)으로 인해 프로세스가 종료 될 때 ~ 7.4Gb로 증가 할 때까지 점진적으로 증가합니다 (하루 0.3 ~ 0.5Gb 정도).

우리는 정기적으로 스레드 덤프를 모니터링했는데 스레드 누수가 의심스럽지 않습니다. 우리는 아직도이 여분의 기억이 어디에서 왔는지 파악할 수 없습니다.

Pmap 출력은 스택 및 힙에 대한 일반 블록과는 달리 많은 놈 블록을 보여 주며, 주로 힙 64Mb의 영역에서 힙 (heap), perm gen & 스택에 의해 차지되지 않습니다.

힙 덤프에서는 일반적으로 힙이 아닌 메모리 할당에 사용되는 DirectByteBuffers 및 sun.misc.Unsafe 개체를 찾으려고 시도했지만 개체 수와 메모리 용량은 명목상 같습니다. 이러한 객체를 GCed 한 후에도 여전히 기본 메모리를 사용할 수 있습니까? 힙이 아닌 메모리를 사용하게 될 수있는 다른 클래스는 무엇입니까?

우리의 응용 프로그램은 자체적으로 기본 호출을 가지고 있지만 일부 타사 라이브러리에는 자체 호출이있을 수 있습니다.

어떤 원인 일 수 있습니까? 이러한 증가를 디버깅하는 데 도움이 될 수있는 다른 세부 정보/도구는 무엇입니까? 우리가 알아야 할 알려진 문제는 무엇입니까? 플랫폼 : CentOS 5.6에서 실행되는 Jboss 6.1.

+2

메모리 누수에 대한 오라클의 문제 해결 가이드를 읽은 것으로 가정합니다. http://www.oracle.com/technetwork/java/javase/tools-141261.html – gknicker

+0

이 질문과 관련이 있습니다 : http://stackoverflow.com/questions/26041117/growing-resident-memory-usage-rss-of-java-process –

답변

0

Java 및 glibc> = 2.10 (Ubuntu> = 10.04, RHEL> = 6 포함)에 알려진 문제점이 있습니다.

치료법은 this env를 설정하는 것입니다. 변수는 : export MALLOC_ARENA_MAX=4

상주 메모리가 메모리 누수 또는 메모리 조각화 유사한 방식으로 크리프 알려져있다

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

This blog post says 설정에 대한 IBM 기사가있다.

Google에서 MALLOC_ARENA_MAX를 검색하거나 더 많은 참조를 위해

당신은 할당 된 메모리의 낮은 조각화 최적화하기 위해 조정 다른 malloc에 ​​옵션으로 할 수 있습니다 :

# 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 
+0

나를 위해 작동하지 않았다 :( –

0

RSS 사용의 증가는 기본 메모리 누수가 발생할 수 있습니다. 일반적인 문제는 ZipInputStream/GZIPInputStream을 닫지 않아서 발생한 네이티브 메모리 누수입니다.

ZipInputStream 개방되는 전형적인 방법은 Class.getResource/ClassLoader.getResource 문안과 java.net.URLopenConnection().getInputStream() 인스턴스를 호출하거나 Class.getResourceAsStream/ClassLoader.getResourceAsStream를 호출한다.이러한 스트림은 항상 닫혀 야합니다.

MALLOC_CONF 환경 변수를 지정하여 malloc 샘플링 프로파일 링을 활성화하여 jemalloc을 사용하여 원시 메모리 누수를 디버그 할 수 있습니다. 자세한 지침은이 블로그 게시물에서 확인할 수 있습니다. This blog post에는 jemalloc을 사용하여 Java 응용 프로그램에서 원시 메모리 누수를 디버그하는 방법에 대한 정보도 있습니다.

동일한 블로그에는 native memory leak related to ByteBuffers에 대한 정보도 들어 있습니다.

관련 문제