쓰레기 수거에 소요되는 시간은 얼마입니까?

Question

한 번에 많은 수의 응용 프로그램을 처리 할 수있는 오래된 응용 프로그램을 보관하는 응용 프로그램이 있으므로 한 번에 며칠 동안 실행해야합니다.

회사에서 개발 한 성능 테스트에서 상당히 좋은 성능을 보였지만 최근에는 고객을 위해 아카이브를 실행하고 있으며 실제로 실행 속도가 느린 것으로 보입니다. 성능은 성능이 저하되는 것으로 보입니다.

메모리 누수가없는 것 같습니다. jconsole로 모니터링 했으므로 사용할 수있는 메모리가 충분하고 줄어들지 않는 것 같습니다.

그러나 가비지 콜렉션이 생길 때까지 힙의 생존 공간과 테네시 세대가 매우 빨리 채워질 수 있다는 것을 알아 냈습니다. 오히려 자주 발생하는 것처럼 보입니다. 명백한 천천히의 근원.

응용 프로그램은 7 일 3 시간 동안 실행되었으며 jconsole에 따라 복사 가비지 수집 (772, 611 모음)을 수행하고 12 시간 25 분 동안 marksweep 압축 (145,940 모음)을 수행했습니다.

이것은 쓰레기 수거에 많은 시간을 소비하는 것처럼 보입니다. 이전에 누군가가 이와 같은 것을 들여다 보았는지 궁금합니다. 정상인지 아닌지 알고 있습니까?

편집

지역 처리는 예를 들어 내가 그 다음 문자열로 추가 XPath를 사용하여 SOAP 봉투에서 일부 XML을 추출 5 초 걸렸 로그의 한 부분에서 찾고, 느린 것 같다 루트 태그와 함께 버퍼 .. 그게 전부입니다. 나는 프로덕션 환경에서 실행 중이므로 아직 프로파일을 작성하지 않은 상태에서 데이터를 인터넷을 통해 가져 오거나 개발 환경에서 대규모 테스트 기반을 설정해야 할 필요가 있습니다.

자바 핫스팟 클라이언트 VM 버전 10.0-B23

실행

정말 그냥 것 이제까지 기본값이 어떻게 될지 실행, 특정 가비지 컬렉션 매개 변수를 구성하지 않은, 높은 처리량이 필요합니다. 사용중인 수집가를 찾는 방법을 모르십니까?

수정

종료까지 거기에가는 프로파일 러를 받고, 지속적으로 꽤 심하게 이루어졌다 로깅 문을 출력하는 상태 상자 오프 라인 트리밍 된 일부 코드가 있었다 느린 다운의 원인을 밝혀졌다. 쓰레기 수거는 실제 원인보다는 상태 텍스트를 메모리에 계속 복사하는 것으로부터의 증상이었습니다.

건배 얘들 아.

Answer 1

숫자에 따르면 전체 가비지 수집 시간은 7 일 실행 시간 중 약 18 시간입니다. 전체 실행 시간의 약 10 %에서 약간 증가했지만, 0 %로 낮추더라도 10 %의 실행 시간 만 절약 할 수 있습니다 ... 따라서 상당한 비용 절감을 원한다면 예를 들어 프로파일 러를 사용하여 다른 90 %를 더 잘 조사해야합니다.

Answer 2

적절한 프로파일 링이 없으면 이것은 추측 게임입니다. 그러나 anectode로서, 몇 년 전에 JDK 업그레이드 후 갑자기 응답 시간이 10 배나 느려졌습니다.우리는 더 이상 회사와 더 이상 존재하지 않는 유망한 사람이 추가 한 명시적인 GC 호출로 그것을 쫓아 냈습니다.

Answer 3

JVM 힙 발자국과 GC 시간 사이에 균형을 유지하려고 노력합니다. 또 다른 질문은 너무 자주 GCing을 요구하는 방식으로 할당 된 힙 (및 세대) (under-) 일 수 있습니다. 이 시스템에 muti-tenant JVM을 배치 할 때 공격적인 힙 수축과 함께 총 GC 시간의 5 % 미만으로 균형을 유지하려고 노력하여 풋 프린트를 낮게 유지했습니다 (다시 말하면 멀티 테넌트). 힙 (heap)과 세대 (generations)는 설정이 무엇이든간에 GCing을 자주하지 않으므로 대부분 항상 채 웁니다. 더 현실적인 정상 상태를 보려면 -Xms 매개 변수를 제거하십시오 (유휴 시간이있는 경우)

+1을 프로파일 링 제안에 적용합니다. 그것은 GC와 관련이 없지만 코드 일 수 있습니다.