동적 실행은 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를 사용하는 경우)에는 몇 가지 가능한 실패 원인을 제거합니다.