IBM JDK 1.4.2를 사용하는 AIX의 Websphere Portal Server 5.1에서 포틀릿으로 상당히 복잡한 애플리케이션을 실행하고 있습니다. 우리 프로덕션 시스템에서는 자세한 GC 로그에서 이상한 동작을 볼 수 있습니다. 정상적인 동작 기간이 지나면 시스템은 더 큰 블록과 큰 블록을 빠르게 할당 할 수 있습니다. 시스템은 각 GC를 완료하기 위해> 1000ms를 소비하기 시작하지만 블록이 너무 빨리 할당되어 할당 실패 사이에 단지 30ms 간격이 있습니다.Websphere Portal Server와의 이상한 가비지 콜렉션 동작
- 각 할당 실패는 마지막 정수보다 약간 큰 정수 x 1024 바이트만큼 커집니다. 예 : 5MB, 그리고 잠시 후 5MB + 17 * 1024가 될 수도 있습니다.
- 이것은 최대 10 분 동안 지속될 수 있습니다.
- 블록은 크기가 8MB에서 14MB까지 커지는 경향이 있습니다.
- 쿼드 코어 시스템이며 다른 코어가 GC를 완료 할 때까지 기다리는 세 개의 코어로 GC를 수행하는 시간이 현재> 95 %라고 가정합니다. 10 분 동안. 아야.
- 이 시점에서 분명히 시스템 성능이 떨어집니다.
- 우리는 JSF, 최대 절전 모드 & JDBC, 웹 서비스 호출, log4j 출력 및 다른 것들을 가지고 있습니다.
이 코드는 응용 프로그램 코드가 아닌 인프라 구조로 해석됩니다. 루프 내부에서 잘못된 문자열 연결 인 경우 1024 블록보다 불규칙적 인 증가가 예상됩니다. StringBuffer 또는 ArrayList가 증가하면 블록 크기가 두 배가됩니다. 성장으로 인해 로그 버퍼링이나 다른 것을 생각하게되었습니다. 우리 애플 리케이션에서 아무 것도 생각할 수 없다. 할당량은 1MB, 14는 말할 것도 없다. 오늘은 디스크로 플러시되기 전에 메모리에 로깅을 기록했지만 GC 스레 싱의이 기간 동안 로깅 스테이트의 볼륨은 아무데도 없었다. MB 범위.
분명히 문제는 가비지 수집이 아니라 과도한 메모리 할당 때문입니다. 가비지 수집은 계속 유지하는 것이 최선입니다. 뭔가 큰 블록을 할당하고 너무 작은 단위로 비효율적으로 확장하려고합니다.
어떤 아이디어가 시스템에 부하가 걸렸을 때이 모든 원인이 될 수 있습니까? Portal Server와 비슷한 것을 본 사람이 있습니까?
참고 : 관심이있는 사람은 그 원인이 가끔씩 있지만 엄청난 데이터베이스 쿼리 인 것처럼 보이기 시작했습니다. 가장 큰 원인은 Hibernate 또는 JDBC 드라이버입니다.
IBM Java 5 및 6의 최신 버전에는 사용할 수있는 덤프 에이전트가 있습니다. 옵션은 -Xdump : stack : events = allocation, filter = #입니다. 는 "5m"과 같은 직선 크기 또는 "256k..512k"와 같은 범위 일 수 있습니다. 그래도 "#"을 잊지 마세요! 자세한 정보는 Java 진단 안내서를 확인하십시오. –