[additional] 4장 - 힙메모리 OOM 트러블슈팅 사례를 같이 읽어보아요

[kth990303]

연관 챕터

7

조사 내용

책에서 세션을 과다하게 보관하여 힙메모리 이슈가 발생할 수 있다고 안내돼있더라고요. 이와 유사한 사례들을 읽고 같이 공부해보면 좋을 거 같아 준비해봤습니다. 시간이 괜찮으면 두 가지 사례를 같이 읽고, 부족하면 하나만 같이 읽어도 좋을 듯합니다!

어랏!! 여기에서 OOM이 발생할 줄이야...

• Mybatis 캐시 정책 및 GC 동작방식을 이해한 후, OOM을 해결한 롯데 기술블로그 포스팅입니다.

Java 시스템 운영 중 알아두면 쓸모 있는 지식들

• tomcat 인스턴스 설정값과 GC 에 대해 얘기하고 있는 포스팅입니다.

---

@caffeine-library/readers-release-everything

[binchoo]

최근 NodeJS 웹 페이지 빌드를 위한 CodeBuild 수행 시간을 튜닝하던 중 OOM 메모리가 발생했었습니다. 금일 발표 때 소개 드릴게요.

vue-tsc 사용하여 타입 검증시 V8 엔진에 할당된 2GB 힙 메모리가 터지는 현상

• (깃허브에 많은 보고 사례)
• 직접 원인: tsc(타입스크립트 컴파일러) 수행 중 리소스가 많이 야기되는 점
• 간접 원인: 검증 작업에 많은, 큰 크기의 노드 모듈을 프로젝트가 의존했기 때문에
• 해소 방법: 힙을 늘리거나, 힙을 아끼자...
  • 힙을 늘리기 위한 --max-old-space-size 증설
  • 힙을 아끼기 위해 tsconfig에서 exclude로 패키지 제외하거나, 중복 의존하는 타입(근데 버전은 다른) 비효율 해결하기

Overcoming “JavaScript Heap Out of Memory Error” During TypeScript Compilation in a MUI5 React Project: A Case Study

• 어느 미디움 글에서 이슈가 되는 패키지를 분석해, 중복 의존성이 있다는 점을 캐치. 스마트한 해결 사례를 공유 주셨더라구요.

[leejaeseung]

로깅과 OOM

예전에 테스트 과정에서 있었던 OOM 이슈가 떠올라서 공유드려 봅니다. 되게 심플하지만 자칫 놓치기 쉬운 부분이었다고 생각합니다 ㅎㅎ

배치성으로 대량의 DB(MongoDB) insert 를 하는 어플리케이션을 개발하였습니다. 에러 처리를 최대한 꼼꼼히 하려 했고, DB 에서 실패할 수 있는 에러들에 대해 모두 custom exception 으로 변환해 주었습니다.

테스트 환경에서 DB 부하 테스트를 하던 도중 부하를 과도하게 많이 주어서 DB 서버의 CPU 가 100% 까지 쳤고, insert 는 모두 실패했습니다. 그러던 중, 애플리케이션이 한동안 아무 로그도 찍지 않고 있다가 OOM 을 일으키며 죽어버리더라구요.

원인은 DB 의 에러메시지를 로깅하는 코드였습니다. 그때까진 최대한 자세한 에러메시지를 로깅하면 좋을거란 생각에 exception.getMessage 를 그대로 custom exception 에 넣어주었거든요. DB 에 100만 건 가량의 bulk insert 를 했고, DB 의 에러는 insert 된 각 row 의 실패 사유를 한 줄씩 모두 찍어주고 있었습니다. message 변수로 존재할 때는 괜찮았지만 로그를 찍는 순간 몇천만 개의 단어가 로깅되면서 터져버렸던 거였습니다.. ㄷㄷ

그때 이후론 custom exception 의 메시지는 최대한 간결하고 예상 가능하게 넣으려 하고 있습니다. ㅎㅎㅎ API 서버에선, 사용자에게 보여주는 에러 메시지와 에러 알림/디버깅용 메시지를 따로 분리하는 것도 적용해 보았구요