동적 실행은 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 및 Windows 시스템에서는 샌드박스화된 전략이 느릴 수 있습니다. --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 자체 또는 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를 사용하는 경우 위 참고) 오류의 원인이 될 수 있는 몇 가지 요소가 제거됩니다.