동적 실행은 로컬 및 원격으로 실행되는 Bazel의 기능입니다. 첫 번째 브랜치의 출력을 사용하여 동일한 작업이 병렬로 시작됩니다. 다른 브랜치를 취소합니다. 이는 실행 능력과 로컬 지연 시간이 짧은 원격 빌드 시스템의 실행함으로써 클린 빌드와 증분 빌드를 위한 두 환경을 모두 활용할 수 있습니다. 있습니다.
이 페이지에서는 동적 실행을 사용 설정, 조정, 디버그하는 방법을 설명합니다. 만약 로컬 및 원격 실행이 모두 설정되어 있고 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 연상 기호만 해당됩니다. 원격 버전도 동일한 방식으로 작동합니다. 두 플래그 모두
여러 번 지정할 수 있습니다. 작업을 로컬에서 실행할 수 없는 경우
그 반대의 경우도 마찬가지입니다
원격 시스템에 캐시가 있는 경우 --dynamic_local_execution_delay 플래그
원격 시스템이 로컬 실행에 대한 지연 시간을
캐시 적중을 나타냅니다 따라서 더 많은 캐시 적중 시 로컬 실행이 방지됩니다.
가능성이 높습니다. 기본값은 1000ms이지만 약간만 조정해야 합니다.
캐시 적중이 일반적으로 걸리는 시간보다 오래 걸립니다. 실제 시간은 리모컨과
왕복 소요 시간을 기반으로 합니다. 일반적으로 값은 동일합니다.
특정 원격 시스템의 모든 사용자(일부 사용자 중 일부가 충분히 멀리 떨어져 있는 경우 제외)
왕복 지연 시간을 추가합니다. Bazel 프로파일링 사용
특성을 사용해
캐시 적중이 발생합니다
동적 실행은 로컬 샌드박스 전략뿐만 아니라
영구 작업자를 사용합니다. 영구 작업자는
동적 실행과 함께 사용될 때는 샌드박스와 함께 실행되고 멀티플렉스를
작업자와 함께 사용하는 것입니다. Darwin과 윈도우즈 시스템에서 샌드박스 처리된
전략이 느릴 수 있습니다 --reuse_sandbox_directories를 전달하여
오버헤드가 발생할 수 있습니다.
하지만 standalone 전략으로도 동적 실행을 실행할 수 있습니다.
standalone 전략은 실행을 시작할 때 출력 잠금을 설정해야 합니다.
원격 전략이 먼저 완료되는 것을 효과적으로 차단합니다. 이
--experimental_local_lockfree_output 플래그를 사용하면
로컬 실행이 출력에 직접 기록되도록 허용하지만
원격 실행이 먼저 완료되어야 합니다.
동적 실행의 브랜치 중 하나가 먼저 완료되었으나 실패인 경우 전체 작업이 실패합니다 이는 데이터 간의 차이를 방지하기 위해 의도된 선택입니다. 눈에 띄지 않도록 할 수 있습니다.
동적 실행 및 잠금 작동 방식에 관한 배경 정보는 Julio를 참고하세요. Merino의 훌륭한 블로그 게시물
동적 실행은 언제 사용해야 하나요?
동적 실행에는 일종의 원격 실행 시스템이 필요합니다. 현재 캐시 전용 원격 시스템은 캐시 부적중이기 때문에 사용할 수 없습니다. 실패한 작업으로 간주됩니다
모든 유형의 작업이 원격 실행에 적합한 것은 아닙니다. 최고 기본적으로 로컬에서 더 빠른 검색, 예를 들어 지속적 작업자 또는 빠르게 실행되는 작업자 사용 원격 실행의 오버헤드가 실행 시간을 지배할 정도로 충분합니다. 이후 로컬에서 실행된 각 작업은 일정량의 CPU 및 메모리 리소스를 잠그고 이러한 카테고리에 속하지 않는 액션을 실행하면 실행이 지연될 뿐입니다 있습니다.
출시일 기준
5.0.0-pre.20210708.4,
성능 프로파일링에는 데이터가 포함됩니다.
작업 요청을 완료하는 데 걸린 시간을 포함하여
경쟁에서 이기지 않습니다 동적 실행 작업자 스레드가 표시되는 경우
리소스를 확보하는 데 상당한 시간을 소비하거나
async-worker-finish님, 느린 로컬 작업이 발생하여 작업자가 지연될 수 있습니다.
스레드가 필요합니다.
8개의 Javac 작업자를 사용하는 위의 프로필에는 많은 Javac 작업자가 있습니다.
레이스에서 패배하여 async-worker-finish에서 작업을 마무리한 상태
스레드가 필요합니다. 이 문제는 비작업자 니모닉이 작업을 실행하기에 충분한 리소스를 가지고 있어
지연시킬 수 있습니다
Javac만 동적 실행으로 실행될 때 일을 시작한 후 경쟁에서 지는 수 밖에 없게 됩니다.
이전에 권장되는 --experimental_spawn_scheduler 플래그는 지원 중단되었습니다.
동적 실행을 사용 설정하고 모든 캠페인의 기본 전략으로 dynamic을 설정합니다.
이런 문제를 야기할 수 있는 니모닉과 관련해서도 매우 중요합니다.
성능
동적 실행 접근 방식에서는 사용 가능한 리소스가 충분하다고 가정합니다. 서비스를 개선하기 위해 추가 리소스를 투입할 가치가 있다는 것을 확인할 수 있습니다 그러나 리소스를 과도하게 사용하면 Bazel 자체 속도가 느려지거나 원격 시스템에 예기치 않은 압력을 가할 수 있습니다. 현재 동적 실행 동작을 변경하기 위한 몇 가지 옵션은 다음과 같습니다.
--dynamic_local_execution_delay는 로컬 브랜치의 시작을 숫자만큼 지연합니다.
대기 시간(밀리초)이 소요될 수 있지만,
원격 캐시 적중을 인식하지 못할 수 있습니다. 따라서 빌드에 도움이 되는
로컬 리소스를 낭비하지 않는 것이 일반적입니다.
출력은 캐시에서 찾을 수 있습니다. 캐시의 품질에 따라
이를 줄이면 더 많은 로컬 리소스를 사용하는 대신 빌드 속도가 향상될 수 있습니다.
리소스를 배포합니다
--experimental_dynamic_local_load_factor은(는) 실험용 고급 리소스입니다.
관리 옵션도 제공합니다 0에서 1, 0 사이의 값을 사용하여 이 기능을 끕니다.
0보다 큰 값으로 설정하면 Bazel이
많은 작업이 대기 중인 경우 로컬에 예약된 작업을
지정할 수 있습니다 1로 설정하면 최대한 많은 작업을 예약할 수 있습니다.
사용 가능한 CPU입니다 (--local_cpu_resources 기준). 값이 낮을수록
작업 수가 많을수록 이에 따라 예약 작업 수가 줄어들게 됩니다.
실행할 수 있습니다 직관적이지 않게 들릴 수 있지만 리모컨이 꼭 필요합니다.
로컬 실행은 많은 작업이 실행되고 있을 때는 별다른 도움이 되지 않습니다.
로컬 CPU가 원격 작업을 관리하는 데 더 낫습니다.
--experimental_dynamic_slow_remote_time는 로컬 브랜치 시작을 우선시합니다.
원격 브랜치가 최소 이 시간 동안 실행되었을 때 일반적으로
가장 최근에 예약된 작업이
레이스에서 이기고 있지만 가끔 원격 시스템이 멈추거나 더 오래 걸리는 경우
빌드가 진행되도록 할 수 있습니다. 이 기능은 기본적으로 사용 설정되어 있지 않습니다.
원격 시스템의 문제를 숨겨야 할 수도 있습니다.
원격 시스템 성능을 모니터링할 수 있습니다.
--experimental_dynamic_ignore_local_signals을(를) 사용하여 리모컨이
주어진 신호로 인해 로컬 생성이 종료되면 브랜치가 인계받습니다. 이것은
작업자 리소스 제한과 함께 주로 유용합니다
--experimental_worker_memory_limit_mb님,
--experimental_worker_sandbox_hardening,
및
--experimental_sandbox_memory_limit_mb)),
작업자 프로세스가 리소스를 너무 많이 사용하면 종료될 수 있습니다.
JSON 트레이스 프로필에는 확인할 수 있는 실적 관련 그래프가 많음 균형을 맞춰야 합니다
문제 해결
동적 실행 관련 문제는
로컬 실행과 원격 실행의 일부 특정 조합에서만 매니페스트를 사용해야 합니다.
--debug_spawn_scheduler는 동적 실행의 출력을 추가합니다.
도움이 될 수 있습니다 또한
--dynamic_local_execution_delay 플래그 및 원격 및 로컬 작업의 수
문제를 더 쉽게 재현할 수 있습니다.
standalone를 사용하여 동적 실행에 문제가 발생한 경우
--experimental_local_lockfree_output 없이 실행해 보거나
샌드박스 처리됩니다. 이로 인해 빌드가 약간 느려질 수 있습니다(
Mac 또는 Windows를 사용하는 경우)에는 몇 가지 가능한 실패 원인을 제거합니다.