UDN
Search public documentation:

HotSpotReportGenerationKR
English Translation
日本語訳
中国翻译

Interested in the Unreal Engine?
Visit the Unreal Technology site.

Looking for jobs and company info?
Check out the Epic games site.

Questions about support via UDN?
Contact the UDN Staff

UE3 홈 > 퍼포먼스, 프로파일링과 최적화 > 콘텐츠 프로파일링과 최적화 > 핫 스팟 리포트 생성

핫 스팟 리포트 생성


개요


이 글은 레벨 디자이너용 "핫 스팟 리포트" 생성법에 대한 설명서입니다. 이 리포트는 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-blevel-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 위치도 제공해 줘야 레벨 디자이너가 급락 발생 이전의 레벨 영역으로 직접 이동하여, 에디터나 게임에서 이 위치 주변을 살펴 보고 여기서 무슨 일이 벌어지는지, 얼마나 많이 변경해 줘야 할 지 감을 잡을 수 있을 것입니다.

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

이 테스트 도중 가장 낮은 메모리는 20 MB 였으며, 다음 서브레벨이 로드되었을 때였습니다:

  • SP_Example_W
  • SP_Example_02_boss
  • SP_Example_02_S
  • SP_Example_03
  • SP_Example_04

아래 그래프에서 보면 30 MB 마크 아래로의 급락은 두 지점이 있습니다:

examplegraph.jpg

첫째 급락

다음 bugit 위치를 통해 이 급락 발생 직전의 레벨 영역으로 이동할 수 있습니다:

  BugItGo -1858.2000 -2162.7903 1572.0010 64073 -16686 0=
  

이 급락 도중 애님 시퀸스 클래스가 15 MB, 스켈레탈 메시 클래스가 5 MB, 사운드 노드 웨이브가 5 MB, 스태틱 메시 클래스가 2 MB 씩 각각 늘었습니다.

이 급락이 발생한 첫 지점인 세 번째와 여섯 번째 캡처 사이에 새로이 스트림 인 된 서브레벨은 다음과 같습니다:

  • SP_Example _Cine

둘째 급락

다음 bugit 위치를 통해 두 번째 급락 발생 직전의 레벨 영역으로 이동할 수 있습니다:

  BugItGo 904.3768 261.3029 1761.1804 -4788 -20256 72
  

이 급락 도중 애님 시퀸스 클래스는 10 MB, 스켈레탈 메시 클래스는 2.5 MB, 사운드 노드 웨이브는 5 MB, 스태틱 메시 클래스는 1 MB 올랐습니다.

두 번째 급락 도중, 즉 8 번째와 12 번째 캡처 사이에 스트림 인 된 서브레벨은 다음과 같습니다:

  • SP_Example_02_boss
  • SP_Example_02_S
  • SP_Example_03

콜아웃 되는 항목


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

피할 항목


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

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


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

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

장기간 실행


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

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

콜드 스팟 리포트


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