메모리 누수 분석

얼마전 어느 업체에서 메모리 누수가 있는 것 같단다. '프로세스가 차지하는 메모리의 사이즈가 크다. 서버가 느려지는 이유가 그 때문인 것 같다. 튜닝이 필요하다'. 그러나 프로세스의 메모리가 크다고 해서 그것을 문제로 판단할 수는 없다. 그 어플리케이션이 원래 많은 메모리를 차지한다면 어떻게 하겠는가?

 

현상을 분석하기 위해서 사전에 정리한 내용이다.

 

메모리 누수는 우선 시간을 두고 메모리 변화 추이를 보는 것이 중요하다. 메모리는 종류에 따라서 다른 용도로 사용된다. 어느 메모리에 문제가 있는지는 성능 카운터 값들의 추이를 그래프로 살펴보면 예상할 수 있다. 어느 메모리가 문제인지를 알게 되면, 메모리의 사용 용도가 결정되므로 살펴봐야 하는 문제의 범위를 줄일 수 있다. 

이런 작업을 하기 위해서는 따라서 관련된 성능 카운터의 변화 추이를 살펴보는 작업이 필요한데, 그러기 위해서는 적절한 메모리 관련 성능 카운터도 선택해야 한다. 그리고 적절한 성능 카운터를 선택하기 위해서는 우선 메모리의 종류 및 특징에 대해서 알아야 한다. 

 

다음 순서로 정리한다.

ㆍ

- Stack과 Heap의 구분( 참고, C# Heap(ing) Vs Stack(ing) in .NET: Part I )

- 각 메모리와 관련된 성능 카운터

- 메모리 변화 추이 유형 과 원인 분석

 

Stack은 주로 코드의 실행 순서를 추적하는 일을 한다.  어떤 메소드들이 호출되었는지, 메소드들을 호출하는데 사용되는 파라미터, 반환값 등이 이 메모리에서 관리된다.

Heap은 정보를 가지고 있는 실제 객체들이 생성되는 메모리이다.

 

만약 Stack 메모리의 크기가 계속 증가한다면, 큰 메모리를 사용하고 있는 메소드 호출이 반환되지 않는 경우

또는 백그라운드에서 실행되는 쓰레드들이 끝나지 않는 경우

 

■ Three step process to investigate memory leak

참고) https://www.codeproject.com/Articles/42721/Best-Practices-No-5-Detecting-NET-application-memo#3stepprocesstoinvestigatememoryleak

 

■ 각 메모리와 관련된 성능 카운터

 

Process/Private bytes : 해당 어플리케이션에서 사용하는 managed & unmanaged 메모리를 합한 사이즈

.NET CLR Memory/#bytes : 해당 어플리케이션에서 사용하는 .NET의 모든 managed Heap 메모리의 사이즈

.NET CLR Locks And Threads/# : 해당 어플리케이션에서 사용하는 커런트 논리 쓰레드의 수

참고) Best Practices No. 5: Detecting .NET application memory leaks

 

■ 메모리 변화 추이 및 원인 분석

 

private bytes는 증가, bytes는 그대로 --> unmanaged 메모리 leaking

private bytes 증가, bytes 증가 --> managed 메모리 leaking

Threads 수 증가 --> Thread Stack 메모리 leaking

 

■ 메모리 덤프 분석

 

예상되는 메모리 원인이 분석되면, 관련있는 소스 코드의 위치를 찾아내는 메모리 덤프 분석 작업을 한다.

다양한 분석 툴들을 사용해서(예, Windbg ), 상세 분석 작업을 진행할 수 있다.

 

Memory Leak Detection in .NET