JavaScript 애플리케이션에서 Out Of Memory(OOM) 문제가 발생하면, 그 원인을 파악하고 해결하기 위해서는 메모리 상태를 자세히 분석해야 합니다.
이 글에서는 크롬 개발자 도구(DevTools)를 사용하여 OOM 발생 전후의 Heap Snapshot을 비교하고 문제를 분석한 경험을 공유합니다. 👩🏻💻
OOM 분석 준비: Heap Snapshot 수집
먼저 OOM 원인을 분석하려면 OOM 발생 전후의 Heap Snapshot이 필요합니다.
Heap Snapshot은 JavaScript 메모리 상태를 저장한 파일로, 메모리 사용량과 객체 할당 상태를 분석하는데 유용합니다.
크롬 개발자 도구(DevTools)에서 Heap Snapshot 비교하기
OOM 문제를 해결하기 위해 저는 크롬 개발자 도구를 사용했습니다.
아래는 Heap Snapshot을 수집하고 비교하는 구체적인 방법입니다.
먼저 크롬의 개발자 도구를 열어줍니다!
- Mac OS: Option + Command + I
- Windows: Ctrl + Shift + I
개발자 도구가 열리면 상단의 Memory 탭을 선택합니다.
Heap Snapshot을 비교하려면 먼저 OOM 발생 전후로 수집한 Heap Snapshot 파일을 준비해야 합니다.
Memory 탭에서 `Load`버튼을 클릭하여 비교할 파일들을 업로드합니다.
저는 Heap Snapshot을 다음 두 가지 방식으로 확인하였습니다.
Summary 탭으로 개별 Heap 상태를 상세히 볼 수 있습니다.
Comparison 탭으로 두 개의 Snapshot을 비교할 수 있습니다.
Heap Snapshot 분석: OOM 원인 파악하기
Heap Snapshot을 비교하여 어떤 객체가 메모리를 과도하게 사용하는지 확인합니다. 예를 들어, 다음과 같이 OOM 발생 전후의 메모리 사용량을 비교할 수 있습니다.
첫 번째와 두 번째 Snapshot 비교
두 번째 스냅샷과 첫 번째 스냅샷을 `Comparison` 옆에 선택해서 비교해 보겠습니다.
두 스냅샷은 메모리 부하가 없을 때의 스냅샷입니다. Size Delta 기준으로 내림차순 정렬을 하면 애플리케이션이 string을 가장 많이 사용하는 것을 확인할 수 있습니다.
세 번째와 네 번째 Snapshot 비교
네 번째 스냅샷과 세 번째 스냅샷을 선택해서 비교해 보겠습니다.
네 번째 스냅샷은 oom이 발생한 시점 스냅샷과 세 번째 스냅샷은 oom 발생 직전 스냅샷입니다.
두 snapshot을 비교하면 특정 객체(Array)의 메모리 사용량이 급격히 증가한 것을 확인할 수 있습니다.
네 번째와 다섯 번째 Snapshot 비교
다섯 번째 스냅샷과 네 번째 스냅샷을 선택하여 비교해 보겠습니다.
다섯 번째 스냅샷은 oom 발생 이후의 스냅샷입니다. 이전 Snapshot에서 가장 많이 사용하던 객체(Array)의 Size가 감소한 것을 알 수 있습니다.
분석 결과: OOM 원인 및 해결
Snapshot 비교를 통해 다음과 같은 결론을 도출했습니다.
- 문제 원인: 애플리케이션의 특정 시점에서 일시적인 메모리 부하 발생.
- 해결 방법: 메모리 누수가 아닌 일시적 부하임을 확인하여, 코드 최적화와 부하 분산을 통해 문제를 완화할 수 있음.
💡OOM 문제는 애플리케이션에서 흔히 발생하는 메모리 이슈 중 하나입니다. 크롬 개발자 도구의 Heap Snapshot 비교 기능을 활용하면 메모리 사용 상태를 시각적으로 분석하고, OOM 원인을 파악하여 효율적으로 문제를 해결할 수 있습니다.
'개발끄적' 카테고리의 다른 글
| 414 Request-URI Too Large 오류 해결 방법 (0) | 2024.11.21 |
|---|---|
| GraphQL vs REST: 어떤 것을 선택할 것인가? (0) | 2024.11.18 |
| 효율적인 프로그래밍을 위한 동기/비동기와 블로킹/논블로킹 이해하기 (0) | 2024.11.10 |
| 쿠키(Cookie)와 세션(Session) (0) | 2024.11.03 |
| Header Referer를 아시나요? (0) | 2024.07.30 |