OOME 발생한 Heap Dump 분석

Question

OutOfMemoryError는 정말 싫습니다. 재현하기도 힘들고, 에러 원인 파악도 쉽지 않고. 서비스를 운영하던중 OOME가 발생해서 Heap Dump를 받아 분석해봤습니다. 딱 봐도 hibernate 쪽에서 발생한 것 같은데.원인이 뭔지 모르겠습니다. 서서히 Heap 메모리(Old Gen) 쌓여 문제가 발생됩니다. Heap 덤프 분석 이후 진도를 나가지 못하겠습니다. ㅡㅡ; 참고로 하이버네이트 버전은 5.0.12 입니다.

자몽아이스티맛 · Answer

들어가기에 앞서 초보라는 것을 명시하구... 세션팩토리에서 발생한거라면 다음과 같이 예상해볼거 같습니다.1. 쿼리 저장소에 쌓이는 쿼리 데이터량2. 콜렉션 바운드 해시 맵을 판단해보면 연관관계가 설정되어 있는 테이블들이 원인 즉 이용자가 많아서 쿼리 저장소에 쿼리 데이터가 많이 쌓이는데, 이 쿼리들이 연관관계 매핑된 테이블들을 대상으로 한 쿼리들이지 않을까 예상해봅니다.

아이앤코리아 · Answer

음..제 경험상으로는 위와 같은 현상은 특정 function에서 Data를 조회 시 WHERE 조건없이 다량의 Data를 조회할 때 대다수가 발생합니다.아마도 Jennifer 같은 Tool도 같이 설치되어 있으시면 분석이 더 쉬울 수 있을 겁니다.수행 Query 중에 조건절이 빠진 채 다량으로 Data를 가지고 오는 업무가 없는지 한번 찾아보세요아마도 쉽게 찾으실 수 있을 겁니다.

fender · Answer

메모리를 차지하는 인스턴스는 확인된 상황이니 왜 가비지 컬렉팅 대상이 되지 않는지를 따져봐야할 것으로 보입니다. 어떤 도구를 사용하시는지 모르겠지만 보통 프로파일링 툴에서는 GC 루트로 부터의 경로를 보여주는 기능이 있습니다.추측입니다만, 관련된 클래스가 모두 하이버네이트 쪽이라면 아무래도 저런 수준의 메모리 누수가 존재할 가능성은 높지 않을테니, 아마 윗 분 말씀대로 잘못된 SQL 등으로 인해 일시에 많은 데이터가 적재되거나 하는 원인일 경우가 조금 더 의심이 갑니다.이 경우 해당 요청이나 질의에 대한 변수 등도 덤프 내용 중에 남아있을 가능성이 있으니 분석 과정에서 주의 깊게 보시면 될 것 같습니다.

복슬이 · Answer

답변 고맙습니다. hibernate 디버깅 로그를 키고, 페이지를 하나하나 눌러 보니 문제가 있어 보이는 부분을 찾았습니다. select ~ where field in(...) 이런 형태 쿼리가 있었는데.. in에 바인드 되는 List 사이즈가 10만 넘는 부분이 있었습니다. 10만개,... 물론 코드가 잘못됐죠. 이 과정에서 쿼리 사이즈가 커지고, 하이버네이트에서는 이를 캐싱했기 때문에 발생한 문제로 보고 있습니다. 아직까지는 추정이고요. 며칠 모니터링 해봐야죠.

OOME 발생한 Heap Dump 분석

4개의 답변

Q&A 목록