핫 스팟 리포트 생성

개요

이 글은 레벨 디자이너용 "핫 스팟 리포트" 생성법에 대한 설명서입니다. 이 리포트는 QA 부서에 의해 생성되는 것으로, 서브레벨 스트림인/아웃으로 인한 메모리 급락을 식별하기에 좋습니다. 이를 통해 어느 버킷이 메모리를 가장 많이 차지하는지, 어떤 레벨을 최적화시켜 메모리에 더욱 잘 맞게 할 것인지를 레벨 디자이너가 쉽게 파악할 수 있습니다.

원본 MemLeakCheck 데이터 생성하기

SP 레벨에 대한 메모리 상태를 그리는 데 사용할 원본 데이터를 구하는 작업은 다음과 같습니다:

1. UnrealConsole 을 불러온 뒤 테스트에 사용될 게임 인스턴스로 연결합니다.
2. DebugConsole 실행파일을 통해 캡처하려는 빌드를 실행시킵니다.
3. 캡처하려는 SP 레벨을 불러옵니다.
4. 레벨에서 다음 명령을 내립니다:
   DoMemLeakchecking 30

   위의 30은 memleakcheck 캡처 간격을 초 단위로 나타냅니다. 필요에 따라 빈도를 조절할 수는 있지만, 시간에 따른 추세를 제대로 파악하려면 일관된 수치가 좋습니다.

5. =stat levels= 을 켜면 P-레벨이 언제 변화하는지를 추적할 수 있습니다.
6. 전체 P-레벨 및 다음 P-레벨 이행시까지 진행합니다.
7. 이행한 P-레벨의 캡처를 두 번 한 다음, 메인 메뉴 및/또는 리부팅으로 빠져나옵니다.
8. 다른 레벨 캡처 시작 전에는 반드시 리부팅하십시오.
9. 프로파일링 중인 플랫폼에 따라 다음 폴더에 memleakcheck 파일이 생성됩니다:
   • PC/UDK:
     [install]\[GameName]\Profiling\MEMLEAKS
   • iOS (documents 디렉토리를 PC로 백업한 이후. documents 디렉토리 백업에 관한 정보는 Deployment Tools 페이지 참고):
     [install]\[GameName]\iOS_Backups\[DeviceName]\Profiling\MemLeaks
10. 각 memleakfile 은 시작된 레벨 이름을 딴 폴더명 속에 파싱됩니다.
    예를 들어 level-a 에서 캡처를 시작한 후 level-b 와 level-c 로 진행했다면, 그 전체에 대한 캡처는 level-a 폴더에 들어갈 것입니다.
11. 이 memleakcheck 파일/폴더를 쉽게 접근할 수 있는 위치로 복사합니다.

데이터를 뽑아낼 CSV 생성하기

1. 다음 폴더에서 memleakcheckdiffer.exe 를 실행시킵니다:
   ..\Binaries\
2. MemLeakCheckDiffer 에서, File > Open 선택 후 폴더와 하위폴더의 Memleak 파일을 전부 엽니다.
3. Browse, memleakcheck 파일을 넣어 둔 폴더로 이동해 갑니다.
4. 폴더가 MemLeakCheckDiffer 를 채울 때까지 기다립니다.
5. 모든 폴더가 MemLeakCheckDiffer 창을 채우고 나면, Generate Overall Report 를 선택합니다.
6. 각 레벨에 대한 CSV 가 생성되며, GlobalSummary CSV 역시도 생성됩니다.
7. CSV는 MemLeakCheck 파일을 넣어 둔 폴더 안에 위치합니다.

전체적인 추세 데이터 분석하기

1. 엑셀로 GlobalSummary 스프레드시트를 엽니다.
2. 콘텐츠 데이터를 좀 더 쉽게 시각화해 보기 위해, 다음 이외의 열은 전부 숨깁니다:
   • LowestTFP (가장 낮은 TFP)
   • AnimSequenceClasses (애님 시퀸스 클래스)
   • SkeletalMesh_Classes (스켈레탈 메시 클래스)
   • SoundNodeWave (사운드 노드 웨이브)
   • StaticMesh_Classes (스태틱 메시 클래스)
3. 버킷 이름으로 시작해서 열의 마지막 값으로 끝나는 이와 같은 열 다섯을 선택합니다.
4. 선택하고나서 Insert > Line Graph 를 선택합니다.
5. 각 콘텐츠 버킷의 상태는 물론 레벨상의 전체적인 메모리 추세를 개괄적으로 확인할 수 있습니다.

개별 레벨 CSV 분석하기

어디에 급락이 발생했는지를 알아본 다음에는, 어느 콘텐츠 버킷이 증가하여 메모리 상황을 변경시켰는지 알아내기 위한 작업을 해 줘야 할 것입니다. 이 작업은 특정 급락 지점에서 최저 메모리 값을 찾은 다음 급락점의 버킷 값을 구하여, 그 값을 급락이 시작되기 전의 버킷 값에서 빼 주는 작업이 됩니다. 이를 통해 어느 콘텐츠 버킷이 이 위치에서의 문제를 가장 많이 유발했는지 쉽게 알아낼 수 있습니다.

예를 들어 어떤 레벨이 급락 전에는 애님시퀸스 클래스 데이터가 10 MB 였는데 급락이 시작되자 이 버킷이 25 MB 로 늘어났다면, 레벨 디자이너와 개발자는 여기서 애니메이션 데이터가 많이 필요한 무언가가 로드되었다는 것을, 그것이 바로 메모리를 낮춘 원인이라는 것을 알 수 있게 됩니다.

이 데이터는 가급적 급락이 발생할 때마다 포함되어야 할 것입니다. 급락이 발생할 때, 로드된 서브레벨을 포함해서 변화된 콘텐츠 버킷이 얼마나 되는가를 레벨 디자이너에게 알려주기만 해도 보통은 레벨에서 무엇을 바꾸고 정리해 줘야 할 지를 알아보는 데 충분합니다.

레벨 디자이너용 '인간-친화적' 핫 스팟 리포트 준비하기

레벨 디자이너용 핫 스팟 리포트를 준비할 때 염두에 두어야 할 것은, 액션 가능한 정보를 가급적 많이 전달해 줘야 한다는 것입니다. 즉 메모리 급락 발생시 무슨 일이 벌어지고 있었는지 알 필요가 있다는 뜻입니다. 이를 위해 메모리가 낮아지기 시작했을 때 새로이 스트림 인 된 목록이 포함되었는지 확인해야 합니다.

bugit 위치도 제공해 줘야 레벨 디자이너가 급락 발생 이전의 레벨 영역으로 직접 이동하여, 에디터나 게임에서 이 위치 주변을 살펴 보고 여기서 무슨 일이 벌어지는지, 얼마나 많이 변경해 줘야 할 지 감을 잡을 수 있을 것입니다.

저희의 핫 스팟 리포트 예제는 다음과 같습니다:

BugItGo -1858.2000 -2162.7903 1572.0010 64073 -16686 0=

BugItGo 904.3768 261.3029 1761.1804 -4788 -20256 72

콜아웃 되는 항목

급락이 발생하는 곳의 단일 버켓 내 큰 변경사항은 보통 콜아웃 하기 좋은 것입니다. 많은 경우 시네마틱같은 것은 특정 버킷의 양이 커지게 만드는데, 이는 버그이긴 하지만 bake and prune 을 켜 주기만 하면 간단히 고칠 수 있습니다. 이와 같이 쉽게 딸 수 있는 과일은 항상 가급적 빨리 따는 것이 좋습니다.

피할 항목

핫 스팟 리포트를 수집할 때, 레벨 디자이너가 영향력을 행사할 수 없는 버킷의 콜아웃은 피하는 것이 좋습니다. 액션 가능한 데이터를 주지 않는 버킷이 있는지 고려하기도 해야 합니다. 저희 테스트의 경우 텍스처 풀 통계는 메모리용으로는 살펴보기에 적합하지 않은데, 왜냐하면 제한된 방식이 녹화된 방식과 다르기 때문입니다.

후속 핫 스팟 리포트 준비하기

후속 리포트를 통해 레벨 디자이너는 첫 메모리 리포트를 받은 이후 얼마나 개선되었는지 또는 악화되었는지를 알아볼 수 있습니다. 메모리가 개선되었다면 (메모리 상황이 괜찮아서 또다른 리포트가 필요치 않더라도) 후속 리포트를 보내 줘야 레벨 디자이너가 하는 작업이 긍정적인 효과를 내고 있는지를 판단하는 데 도움이 됩니다.

최종 목표는 레벨을 메모리에 맞도록 유지하는 것이며, 레벨 디자이너가 현재까지 레벨을 쌓아 올린 방식이 그와 같은 목표를 달성하는 데 큰 비중을 차지하고 있음을 확인시키는 것입니다.

장기간 실행

메모리에 충분한 레벨이 있다면, 복수의 레벨에 걸쳐 장기간의 메모리 실행을 할 차례입니다. 이 작업은 그저 막히지 않고 길게 늘여진 큰 레벨을 하나 찾은 다음 domemleakchecking 30 명령을 내리고 가급적 멀리 가 보는 것입니다. 저희는 가급적 길게 늘이기 위해 reducepoolsize 옵션으로 실행합니다.

이 데이터를 사용하면 개별 레벨 실행과 연속적인 실행간의 차이점을 비교하여 기본적인 메모리 델타를 구할 수 있습니다. 이 델타를 살펴보면 개별 레벨 속에 세우기 시작할 때 얼마나 많은 부하가 필요할 지를 알아볼 수 있으며, 메모리 누수 발생 위치를 파악하는 데도 도움이 될 것입니다.

콜드 스팟 리포트

메모리 급락이 해결되고 게임이 메모리 제약 내에서 돌아가(는 데다 시간적인 여유가 있으)면 콜드 스팟 리포트 시스템을 구현할 수 있습니다. 무슨 뜻이냐면 똑같은 주기적 메모리 수집 과정을 거친 다음, 뭔가 잘라내기 보다는 추가시킬 영역을 찾아내는 데 주력해 보는 것입니다. 때맞춰 시작하기만 하면 레벨 디자이너가 레벨을 메모리 제약에 더욱 잘 맞도록 알차게 레벨을 채울 수 있을 것입니다.