(+) VisualVM

예전에 엑셀 추출을 하다가 관리자가 oom으로 자꾸 내려가서 그걸 개선해야 했었던 적이 있다. 해결을 하기 위해서 원인을 먼저 찾아보니 사용하는 라이브러리에서 엑셀을 추출하는 과정에서 row 들을 엑셀에 입혀놓고 뭔가 재처리를 위해서 접근을 할 수 있도록 메모리 상에 계속 가지고 있는 데, 이 단위수가 높아질수록 메모리를 많이 사용하는 것이었다.

그래서 row 에 대한 재접근을 포기하고 보관하는 row를 줄이면 메모리 사용량이 줄어들 것으로 추측되어서 코드를 그렇게 바꿨는데, 문제는 실제로 메모리를 적게 쓰는지를 알 수 없었다.

그때 사용한게 VisualVM 인데 여러 용도가 있다.

1. 모니터링: VisualVM은 JVM에서 실행 중인 애플리케이션의 상태를 모니터링할 수 있습니다. CPU 사용량, 메모리 사용량, 스레드 상태, 가비지 컬렉션(Garbage Collection) 등을 실시간으로 모니터링하여 애플리케이션의 성능과 리소스 사용을 파악할 수 있습니다.

2. 프로파일링: VisualVM은 애플리케이션의 실행 시간 동안의 성능 프로파일링을 제공합니다. CPU 사용량이나 메모리 사용량이 높은 부분을 식별하고, 성능 저하의 원인을 분석할 수 있습니다. 프로파일링 결과를 통해 애플리케이션의 병목 현상을 찾고 최적화할 수 있습니다.

3. 스레드 분석: VisualVM은 애플리케이션 내의 스레드 상태를 분석할 수 있습니다. 스레드 덤프(Thread Dump)를 통해 데드락(Deadlock)이나 스레드 차단(Thread Blocking) 등의 문제를 식별하고 해결할 수 있습니다.

4. 힙 덤프 분석: VisualVM은 힙 덤프(Heap Dump)를 생성하고, 애플리케이션의 힙 메모리 상태를 분석할 수 있습니다. 객체의 수, 메모리 누수(Memory Leak), 가비지 컬렉션의 효율 등을 분석하여 메모리 관련 문제를 해결할 수 있습니다.

그 때 사용했던 방법은 서버의 힙 용량을 의도적으로 적게 띄워서 동일한 요청으로 기존 코드, 새로운 코드에 요청하면서 메모리 사용량을 보면서 해결했다. 개선된 코드에서 실제로 힙 사용량의 증가폭이 적었다.

개선된 코드로 테스트를 해보고 'oom이 안나는구나, 개선 된거구나' 하고 무작정 반영하기 보다는 실제로 데이터를 가지고 '이렇게 개선 되었다' 라고 정확하게 근거를 통해 판단하는게 맞다.