언리얼 엔진에서 멀티 프로세스 쿡 사용하기 | 언리얼 엔진 5.5 문서

멀티 프로세스 쿡(Multi-Process Cook) 은 사용 가능한 CPU 코어 및 메모리 리소스를 활용하여 쿠킹된 빌드를 생성하는 데 걸리는 시간을 줄입니다. 이를 위해 쿠킹을 다음과 같이 나눕니다.

여러 워커 하위 프로세스가 에셋 그룹을 쿠킹합니다.
하나의 디렉터 프로세스가 에셋 집합을 나누어 워커에게 할당한 다음, 결과를 수집하고 필요한 경우 출력을 결합합니다.

이 페이지의 내용은 다음과 같습니다.

멀티 프로세스 쿡의 현재 제한 사항에 대한 정보
멀티 프로세스 쿡을 구성하는 방법에 대한 지침
프로젝트에 대한 장점을 극대화하기 위한 가이드라인

장점과 제한 사항

멀티 프로세스 쿡은 병렬 처리를 위해 필수적으로 메모리를 교환합니다. 멀티 프로세스 쿡이 효과적이려면 단일 프로세스 쿡보다 많은 RAM을 사용해야 합니다.

많은 양의 에셋이 있는 프로젝트의 경우 멀티 프로세스 쿡은 쿠킹된 빌드를 완료하는 데 필요한 시간을 크게 줄입니다. 에픽게임즈는 4개의 하위 프로세스가 있는 대규모 프로젝트의 쿠킹을 내부적으로 테스트했으며, 단일 프로세스 쿠킹으로 동일한 프로젝트를 쿠킹하는 것과 비교하여 빌드 시간이 약 40% 단축되었습니다.

Lyra와 같은 소규모 프로젝트의 경우, 소량에 불과한 에셋의 쿠킹에 대한 이점보다 다수의 워커로 인한 처리 또는 메모리 오버헤드가 더 크기 때문에 멀티 프로세스 쿡이 빌드 시간을 단축할 가능성은 낮습니다.

시스템 리소스 병목현상

현재 멀티 프로세스 쿡은 디렉터 프로세스가 실행 중인 시스템에서만 워커 프로세스를 실행합니다. 시스템 리소스를 공유하면 효과적으로 사용할 수 있는 프로세스 수에 제약이 발생합니다.

멀티 프로세스 쿡은 향후 버전에서 원격 워커를 사용할 수 있도록 업데이트될 예정입니다.

두 가지 주요 병목현상은 다음과 같습니다.

머신의 RAM 용량
처리에 사용할 수 있는 코어의 수

RAM이 부족하면 디렉터 및 워커 프로세스가 가비지 컬렉션을 더 자주 시작합니다. 가비지 컬렉션으로 인한 쿠킹 속도 감소가 추가 워커로 인한 속도 향상보다 큰 비용을 유발합니다.

사용 가능한 코어 수가 부족하면 각 워커가 단일 스레드로 실행됩니다. 일반적으로 워커 스레드에서 발생하는 장기 실행 비동기 태스크는 메인 스레드를 차단하고, 이로 인한 쿠킹 속도 감소는 추가 워커로 인한 속도 향상보다 큽니다.

디버깅

멀티 프로세스로 인한 복잡성 증가 또한 시스템별 쿠커 버그의 디버깅을 더 어렵게 합니다. 각 워커의 로그 및 아티팩트는 디렉터에 다시 리플리케이트됩니다. 이는 에픽게임즈 내부, 특히 로그 구문과 아티팩트에서 진단할 수 있는 버그의 경우 잘 작동합니다. 그러나 디버거와 연결해야 하는 문제의 경우 멀티 프로세스로 인해 복잡성이 증가합니다.

멀티 프로세스 쿡은 일부 고급 플러그인 작성자에게 추가적인 부담을 줍니다. 여러 패키지에 걸쳐 쿠킹 프로세스 중에 데이터를 집계하는 플러그인은 이제 수집된 데이터를 디렉터에 리플리케이트하는 워커에 대한 틱 함수를 작성하기 위해 IMPCollector API를 사용해야 합니다.

멀티 프로세스 쿡 활성화

프로젝트의 환경설정 파일이나 쿠커에 대한 스타트업 인수를 사용하여 CookProcessCount 변수를 1보다 큰 숫자로 설정하면 멀티 프로세스 쿡을 활성화할 수 있습니다.

최상의 결과를 얻으려면 CookProcessCount에 다양한 값을 테스트하세요. CookProcessCount의 최적값은 프로젝트 및 머신의 가용 리소스에 따라 다를 수 있습니다.

환경설정 파일에서 멀티 프로세스 쿡 활성화

멀티 프로세스 쿡을 활성화하려면 프로젝트의 *Editor.ini 에 [CookSettings]:CookProcessCount 항목을 추가하고 1보다 큰 정수로 설정하세요. 예시는 다음과 같습니다.


	[CookSettings]

	CookProcessCount=4

스타트업 파라미터를 통한 멀티 프로세스 쿡 활성화

쿠커 스타트업 파라미터를 통해 멀티 프로세스 쿡을 활성화하려면 -cookprocesscount=N 을 사용하여 CookProcessCount를 설정하세요. 여기서 N 은 사용하려는 프로세스의 수입니다. 예시는 다음과 같습니다.


	-cookprocesscount=4.

UnrealAutomationTool(UAT)을 사용하여 빌드를 패키징하는 경우, AdditionalCookerOptions 를 사용하여 AutomationTool을 통해 쿠커 프로세스로 이 인수를 전달할 수 있습니다.


	-AdditionalCookerOptions="<YourOtherOptions> -cookprocesscount=4"

프로젝트 런처 를 사용하여 언리얼 에디터에서 자동화 툴을 실행하는 경우, 프로젝트 런처 세팅에 AdditionalCookerOptions 인수를 지정하는 AdditionalCookerOptions 필드가 있습니다.

환경설정 및 조정

멀티 프로세스 쿡의 주요 조정 파라미터는 사용된 프로세스의 수(CookProcessCount)이며, 프로젝트는 오버헤드로 인해 쿠킹 프로세스가 느려지기 전에 이 값을 최대한 늘려야 합니다. 비용이 증가하기 시작하면, 다른 파라미터를 변경하여 병목현상에 영향을 미치고 워커를 늘릴 수 있습니다.

쿠커 메모리 세팅

쿠커에는 메모리 사용을 제어하며 가비지 컬렉션의 시점을 지정하는 단 하나의 옵션 세트가 있습니다. Engine\Config\BaseEngine.ini 의 [CookSettings] 섹션에 있는 코멘트를 참조하고 컴퓨터의 메모리가 부족하면 조정해 보세요.

DefaultEditor.ini


	[CookSettings]
	MemoryMinFreePhysical=
	MemoryMaxUsedPhysical=
	SoftGCStartNumerator=
	SoftGCDenominator=

문제 해결

다음은 멀티 프로세스 쿡 중에 발생할 수 있는 잠재적인 오류와 권장 조치입니다.

%s 패키지는 현재 연결이 끊긴 CookWorker로만 쿠킹할 수 있습니다. 패키지를 쿠킹할 수 없습니다. (Package %s can only be cooked by a now-disconnected CookWorker. The package can not be cooked.)

이 오류는 CookWorker가 충돌할 때 표시됩니다. CookWorker 충돌을 디버깅하면 이 후속 오류는 무시됩니다. 충돌은 이전 오류로 기록됩니다.
%s에서 철회 결과 메시지를 받았습니다. 철회할 수 있는 패키지가 없습니다. (Retraction results message received from %s; no packages were available for retraction.)

하나의 CookWorker가 다른 워커보다 먼저 완료되면 쿠커는 작업 중인 워커의 작업을 다른 워커에 분산하려고 시도합니다. 월드 파티션 레벨의 경우에는 아직 불가능합니다. 쿠커는 반복적으로 철회를 시도하고 실패하여 퍼포먼스 문제와 로그 스팸을 일으킵니다. 현재 버전의 UE에는 이에 대한 수정 사항이 없습니다. 계획된 수정은 레벨에서 생성된 패키지를 여러 CookWorker에 분할할 수 있도록 월드 파티션 케이스를 수정하는 것입니다.
%s가 %.1f초 동안 RetractionRequest 메시지에 응답하지 않았습니다. 계속 기다리는 중입니다… (%s has not responded to a RetractionRequest message for %.1f seconds. Continuing to wait…)

보고된 기간이 1,000초를 초과하면 일반적으로 CookWorker에 데드록이 있음을 나타냅니다. 디버거를 사용하여 CookWorker에 연결해 수행 중인 작업을 확인하세요.