사용 된 %와 비교하여 예상치 않게 큰 힙 크기

Question

메모리 할당 질문이 있습니다. 우리는 몇 가지 서비스를 가장 먼저 분석했으며, RES 값이 약 1.8GB임을 알았습니다.이 값은 당시 1.8GB의 메모리를 보유하고 있음을 의미합니다. 우리가 방금 시작했으면 (캐시에서 읽고, 처리하고, 다른 캐시로 푸시), CPU 집약적 인 처리가 완료된 후에도 계속 볼 수 있습니다. 우리가 예상 한대로 뭔가가 GC되지 않았 음을 의미합니다.

우리는 다음과 같은 매개 변수를 사용하여 프로그램을 실행 : -Xms256m 내가 이해 내가 이 기대 이제 어떻게 256의 초기 힙 크기, 3096.

의 최대 힙 크기를 의미 -Xmx3096m은 처음에는 필요에 따라 힙이 커지며, 메모리가 할당 해제되면 필요에 따라 축소됩니다 (이것은 내 첫 실수 일 수 있음). 그래서 사용되는 힙에 극적으로 떨어, 우리가 처리를 완료했습니다 사용 힙 1GB의 힙 2GB 크기

5 분입니다 :에

• 3 분 : 우리가 실제로 jvisualvm 함께 참조하면 다음과 같다 충분히 제로 약 1.5GB
• 7 분에 그러나 단지 방울 힙 사이즈 근처 -> 오직 1백-2백메가바이트 정도 사이 힙 사용 처리 주기적 실시간 작은 비트, 힙 사이즈는 역시 일정하게 남아 약 1.7GB.

제 질문은 왜 내 힙이 줄어들지 않았을까요? 이 프로세스가 귀중한 메모리의 리눅스 박스에서 다른 프로세스를 강탈하는 것이 아닌가? 그렇다면 어떻게 해결할 수 있을까? 우리는 가끔 메모리 부족 오류를보고, 이러한 프로세스가 가장 '예기치 않은'메모리 크기를 할당 받으면서 나는 그들과 함께 시작하는 것이 가장 좋을 것이라고 생각했습니다.

건배, 데이브.

(~ JVM 메모리 조정에 대한 이해의 결여 실례!)

Answer 1

힙 확장 및 축소 조정에 대해서는 this answer을 참조하십시오. 기본적으로 JVM은 힙 축소에 너무 공격적이지 않습니다. 또한 힙에 충분한 여유 공간이있는 경우 오랜 기간 동안 GC가 실행되지 않으며, 이는 시간을 줄이는 것이 유일한 시간이라고 생각합니다.

최대로드는 응용 프로그램에 충분한 헤드 룸을 제공하지만 항상 사용중인 경우 OS 성능에 허용되는 값으로 구성하는 것이 가장 이상적입니다.예측 가능성과 잠재적으로 더 나은 성능을 위해 최소값을 최대 값으로 설정하는 것은 드문 일이 아닙니다 (나는 그것을 공개 할 아무 것도 없습니다).

Answer 2

나는 완전한 답변을 가지고 있지 않지만, a similar question has come up before. 이전 논의에서 조정 매개 변수로 -XX:MaxHeapFreeRatio=을 조사하여 힙을 운영 체제로 강제로 되돌려 야합니다. documentation here이 있는데 기본값을 사용하면 사용하지 않은 힙이 매우 많은 양의 JVM 소유로 남을 수 있습니다.

Answer 3

글쎄, GC는 생각할 때 항상 실행되는 것은 아니며 항상 이해할 수있는 것을 수집하지는 않습니다. 힙 공간이 거의 없으면 오래된 gen 공간에서 객체를 수집하기 시작할 수도 있습니다. (일반적으로 old gen에서 수집하는 것은 GC가 실제로해야 할 때까지 피하려고하는 stop-the-world 콜렉션을 포함하기 때문입니다 그것).

Answer 4

TPTP, visualvm 또는 JProbe (상업용이지만 시험 사용 가능)를 사용하여 어떤 일이 발생하는지 정확하게 알아낼 수 있습니다.

다른 주목할 점은 파일 핸들러입니다. 세부 사항은 없지만 동료 중 한 명은 몇 년 전에 여러 파일을 열었던 프로세스로 인해 힙 포화 문제가 발생했습니다. 네이티브 힙에 4KB 버퍼가 할당 될 때마다 열리 며, 처리가 끝나면 해제됩니다. 나는이 아주 모호한 표시가 도움이되기를 바랍니다. ...