메모리 누수를 마주치다.

메모리 누수란 더 이상 사용되지 않는 데이터가 메모리 상에 남아 공간을 차지하고 있는 현상이다. 코드를 잘못 작성하였으니 찾아서 고쳐보자.

문제 등장 배경

내 블로그 사이트는 사이즈가 작은 비교적 간단한 프로그램인데도, 블로그 글을 작성 하다 보면 어느샌가 타이핑에 비해 화면에 반응이 느려지고 있었고, 글이 길어 질수록 느려지는 정도도 비례하여 심해졌다.

처음에는 별 생각 없이 네트워크 문제이거나 컴퓨터 성능이 부족한건가 하며 넘기려 했지만 곰곰히 따져보니 다른데서 경험해 보지 못한 기현상이 내 블로그에서 일어난다는 사실이 확실하게 문제라고 생각이 들었고, 내 코드 어딘가 잘못됬으니 한번 찾아보자 싶었다.

해결 과정

크롬 개발자 도구 퍼포먼스 녹화

크롬에서 [f12] 키로 열수 있는 개발자도구에서 퍼포먼스 탭을 통해 녹화를 시작하였다.

녹화결과를 보니 리스너가 상당히 많은 부분 (자원) 을 차지하는 것을 볼 수 있었다.
이것만으로는 약간 애매하니 메모리를 녹화 해 본다

크롬 개발자 도구 메모리 녹화

이번에는 상단의 퍼포먼스 탭 바로 옆에 있는 메모리 에서 녹화를 시작해 보았다.

상단영역의 길고 짧은 바 그래프가 모여있는 영역에서 파란색 부분은 가비지 컬렉터가 처리 하지 못하고 남아있는 메모리의 양이다. 상당히 많은 부분을 차지하고 있는 것을 볼수 있었다.

해당 탭에서 또 보아야 할 것이 있는데

• ShallowSize = 데이터 자기 자신의 크기
• RetainedSize = 데이터가 존재하기 위하여 참조하는 모든것들을 합친 크기

해당 값들을 참고해서 문제원인을 추측 할 수도있고, 타임라인의 범위를 시작부터 끝까지 넓혀가며 사이즈 변화를 체크 해볼수도 있다.

나의 경우에는 타임라인을 훑어 보던 중, 시간이 지남에 따라 css 관련 사이즈가 계속해서 증가하는것을 보게 되었다. css 관련 사이즈가 커지는것은 일반적으로 이상하므로, 바로 감이 왔다.

어디가 문제였는가

크롬 개발자 도구를 통해 이상한 동작을 포착하였다 하더라도, 내 코드 안에서 문제를 일으키는 부분이 정확하게 어딘지 파악하기 애매할 수도 있다. 다행이 나의 경우에는 내가 직접 코드를 작성하였기 때문에 바로 촉이 오는 부분이 있었는데,

useEffect(() => {
  initHighlightStyle();
},[props.doc])

// props = {doc: string , editalbe: boolean}

바로 이부분이었다. 블로그에 코드블럭도 포함이 되다 보니, 코드에 대하여 스타일을 입히는 작업이 필요했는데, 문제는 해당 함수는 한번만 호출되어도 충분한데, useEffect 의 의존성 부분에 할당된 props.doc 이 말썽 이었던 것이다.

해당 doc 은 본문 전체로, 다시말해 매 타이핑 마다 하이라이팅 함수가 계속해서 실행되고 있었던 것이었다.

의존성 배열에 해당 데이터가 포함된 이유는... 코파일럿이다...사실 의존성 배열에 들어가야 할 데이터는 프롭스에 따로 있지만 코파일럿이 자동 완성을 작성해 주었고, 그냥 지나쳐 버린 내 실수가 컷다.

아래와 같이 수정하였다.

useEffect(() => {
  if (!props.editable) {
    // 블로그 포스팅 조회시
    initHighlightStyle();  
  }
},[props.editable])

수정 이후 퍼포먼스

퍼포먼스의 대부분을 차지하던 리스너가 바닥을 기는 모습을 확인하였다. 그에 따른 결과로 long task 역시 녹화에 포착되지 않았다.

수정 이후 메모리

가비지 컬렉터가 데이터를 수거하지 못해 파란색 영역이 거의 대부분이던 이전과 다르게 정상적으로 데이터를 잘 가져가고 있는 모습을 확인하였다. 또한 타임라인의 경과에 따른 css 크기 증가도 관찰 되지 않았다.

마치며

메모리 누수 그리고 디버깅 라고 하면 어쩌면 내 레벨에서는 아직 무리일것 같은 느낌을 주는
느낌 이었다. 아주 다행이도 이번에 작은 규모의 사이트에서 발생한 현상으로 인해 첫 메모리 누수 디버깅을 해볼수 있어서 좋은 경험을 했다고 본다.