동적 실행은 Bazel의 기능입니다. 버전 0.21부터 동일한 작업의 로컬 및 원격 실행이 동시에 시작되는 경우 완료된 첫 번째 브랜치의 출력을 사용하고 다른 브랜치는 브랜치. 이 백도어는 원격 시스템의 실행 능력 및/또는 대규모 공유 캐시를 결합하여 빌드 시스템으로 로컬 실행의 지연 시간이 짧으며, 클린 빌드와 증분 빌드가 모두 가능합니다.
이 페이지에서는 동적 실행을 사용 설정, 조정, 디버그하는 방법을 설명합니다. 만약 로컬 및 원격 실행이 모두 설정되어 있고 Bazel을 조정하려고 함 이 페이지를 참고하세요. 아직 원격 실행이 설정되면 Bazel 먼저 원격 실행 개요를 참조하세요.
동적 실행을 사용 설정하시겠어요?
동적 실행 모듈은 Bazel의 일부이지만 동적 이미 실행 중인 경우 이미 로컬과 원격으로 컴파일할 수 있어야 합니다. 동일한 Bazel 설정을 배포할 수 있습니다
동적 실행 모듈을 사용 설정하려면 --internal_spawn_scheduler를 전달합니다.
Bazel에 플래그를 지정합니다. 그러면 dynamic라는 새 실행 전략이 추가됩니다. 이제 할 수 있습니다.
다음과 같이 동적으로 실행할 니모닉에 대한 전략으로 이를 사용합니다.
--strategy=Javac=dynamic 어떤 니모닉을 사용할지 선택하는 방법은 다음 섹션을 참고하세요.
동적 실행을 사용 설정할 수 있습니다.
동적 전략을 사용하는 니모닉에 대해 원격 실행 전략은
--dynamic_remote_strategy 플래그에서 가져온 후,
--dynamic_local_strategy 플래그. 통과
--dynamic_local_strategy=worker,sandboxed는 로컬의 기본값을 설정합니다.
작업자 또는 샌드박스 실행을 시도해 볼 수 있는 동적 실행 브랜치입니다.
있습니다. --dynamic_local_strategy=Javac=worker를 전달하면
Javac 연상 기호만 해당됩니다. 원격 버전도 동일한 방식으로 작동합니다. 두 플래그 모두
여러 번 지정할 수 있습니다. 작업을 로컬에서 실행할 수 없는 경우
그 반대의 경우도 마찬가지입니다
원격 시스템에 캐시가 있는 경우 --local_execution_delay
플래그는 원격 시스템이 실행된 후에 로컬 실행에 밀리초 단위의 지연 시간을 추가합니다.
캐시 적중을 나타냅니다 이렇게 하면 캐시가 많아질 때 로컬 실행이 방지됩니다.
가능성이 높습니다. 기본값은 1000ms이지만
캐시 적중이 일반적으로 걸리는 시간보다 조금 더 오래 걸립니다. 실제 시간은
왕복 소요 시간에 대한 정보를 수집했습니다. 일반적으로 이 값은
한 원격 시스템 사용자 중 일부가 충분히 멀리 떨어져 있지 않는 한
왕복 지연 시간을 추가할 수 있습니다. 이
Bazel 프로파일링 기능
일반적인 캐시 적중에 걸리는 시간을
살펴보겠습니다
동적 실행은 로컬 샌드박스 전략뿐만 아니라
영구 작업자를 사용합니다. 영구 작업자는
동적 실행과 함께 사용될 때 샌드박스와 함께 자동으로 실행되며
다중 작업자를 사용합니다. Darwin과 윈도우즈 시스템에서,
샌드박스 전략이 느릴 수 있습니다. 다음을 전달할 수 있습니다.
--reuse_sandbox_directories를 사용하여 이러한 시스템에서 샌드박스를 만드는 오버헤드를 줄입니다.
하지만 standalone 전략으로도 동적 실행을 실행할 수 있습니다.
standalone 전략은 실행을 시작할 때 출력 잠금을 설정해야 합니다.
원격 전략이 먼저 완료되는 것을 효과적으로 차단합니다. 이
--experimental_local_lockfree_output 플래그를 사용하면
로컬 실행이 출력에 직접 기록되도록 허용하지만
원격 실행이 먼저 완료되어야 합니다.
동적 실행의 브랜치 중 하나가 먼저 완료되었으나 실패인 경우 전체 작업이 실패합니다 이는 데이터 간의 차이를 방지하기 위해 의도된 선택입니다. 눈에 띄지 않도록 할 수 있습니다.
동적 실행 및 잠금 작동 방식에 관한 배경 정보는 Julio를 참고하세요. 메리노의 명곡 블로그 게시물
동적 실행은 언제 사용해야 하나요?
동적 실행에는 원격 실행 시스템입니다. 현재는 캐시 전용 원격 시스템을 사용할 수 있기 때문입니다. 확인할 수 있습니다
모든 유형의 작업이 원격 실행에 적합한 것은 아닙니다. 최고 기본적으로 로컬에서 더 빠른 검색, 예를 들어 영구 작업자 또는 원격 실행의 오버헤드가 실행 시간을 지배할 만큼 빠릅니다. 로컬에서 실행된 각 작업은 일부 CPU와 메모리를 잠그기 때문에 이러한 범주에 속하지 않는 작업을 실행하면 실행할 수 있습니다
출시일 기준
5.0.0-pre.20210708.4,
성능 프로파일링
작업을 완료하는 데 걸린 시간을 포함하여 작업자 실행에 대한 데이터를 포함합니다.
패배하지 않습니다. 동적 실행이 표시되는 경우
작업자 스레드가 리소스를 획득하는 데 상당한 시간이 들거나 많은 시간을 소비함
async-worker-finish에서 느린 오프라인 액션이 발생하여
작업자 스레드입니다.
8개의 Javac 작업자를 사용하는 위의 프로필에는 많은 Javac 작업자가 있습니다.
레이스에서 패배하여 async-worker-finish에서 작업을 마무리한 상태
스레드가 필요합니다. 이 문제는 비작업자 니모닉이 작업을 실행하기에 충분한 리소스를 가지고 있어
지연시킬 수 있습니다
Javac만 동적 실행으로 실행될 때 일을 시작한 후 경쟁에서 지는 수 밖에 없게 됩니다.
이전에 권장되는 --experimental_spawn_scheduler 플래그는 지원 중단되었습니다.
동적 실행을 사용 설정하고 모든 캠페인의 기본 전략으로 dynamic을 설정합니다.
이런 문제를 야기할 수 있는 니모닉과 관련해서도 매우 중요합니다.
문제 해결
동적 실행 관련 문제는
로컬 실행과 원격 실행의 일부 특정 조합에서만 매니페스트를 사용해야 합니다.
--debug_spawn_scheduler는 동적
도움이 될 수 있는 실행 시스템입니다. 또한
--local_execution_delay 플래그 및 원격 작업과 로컬 작업의 수
문제를 더 쉽게 재현할 수 있습니다.
standalone를 사용하여 동적 실행에 문제가 발생한 경우
--experimental_local_lockfree_output 없이 실행해 보거나
샌드박스 처리됩니다. 이로 인해 빌드가 약간 느려질 수 있습니다(
Mac 또는 Windows를 사용하는 경우)에는 몇 가지 가능한 실패 원인을 제거합니다.