원격 실행을 위한 원격 캐시 적중 디버깅

문제 신고 소스 보기 Nightly · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

이 페이지에서는 캐시 적중률을 확인하는 방법과 조사 방법을 설명합니다. 캐시 부적중을 방지합니다.

이 페이지에서는 성공적으로 작동하는 빌드 또는 테스트가 있다고 가정합니다. 원격 실행을 활용하며, 원격 실행을 효과적으로 활용하여 원격 캐시를 활용합니다.

캐시 적중률 확인

Bazel 실행의 표준 출력에서 다음을 나열하는 INFO 줄을 확인합니다. 프로세스로, 대략 Bazel 작업과 일치합니다. 이 줄에는 작업이 실행된 위치가 자세히 나와 있습니다. 원격으로 실행된 작업을 나타내는 remote 라벨, 로컬 샌드박스에서 실행된 작업의 경우 linux-sandbox, 기타 실행 전략의 경우 다른 값을 찾습니다. 결과가 원격 캐시에서 가져온 작업은 remote cache hit로 표시됩니다.

예를 들면 다음과 같습니다.

INFO: 11 processes: 6 remote cache hit, 3 internal, 2 remote.

이 예에서는 원격 캐시 조회가 6회 있었고 2개의 작업에는 캐시 조회가 없어 원격으로 실행되었습니다. 내부 3부분은 무시할 수 있습니다. 일반적으로 심볼릭 링크 생성과 같은 작은 내부 작업입니다. 이 요약에는 로컬 캐시 히트가 포함되지 않습니다. 프로세스가 0개이거나 예상보다 적은 경우 bazel clean 다음에 빌드/테스트 명령어를 실행합니다.

캐시 적중 문제 해결

예상한 캐시 적중률을 얻지 못하는 경우 다음을 실행합니다.

동일한 빌드/테스트 명령어를 다시 실행하면 캐시 히트가 발생하는지 확인

캐시를 채울 것으로 예상되는 빌드 또는 테스트를 실행합니다. 이 새 빌드가 특정 스택에서 처음 실행될 때는 캐시 적중. 원격 실행의 일부로 작업 결과가 캐시하고 후속 실행에서 이를 선택해야 합니다.
bazel clean을 실행합니다. 이 명령어는 로컬 캐시를 지우므로 로컬 캐시에서 데이터를 읽지 않고도 원격 캐시 적중을 조사할 수 있습니다.
다시 조사 중인 빌드와 테스트를 동일한 있습니다.
캐시 적중률의 INFO 선을 확인합니다. remote cache hit 및 internal를 제외한 프로세스가 표시되지 않으면 캐시가 올바르게 채워지고 액세스되고 있는 것입니다. 이 경우 다음 섹션으로 건너뜁니다.
불일치의 원인은 빌드가 밀폐되지 않아 두 실행에서 작업이 서로 다른 작업 키를 수신하는 것일 수 있습니다. 이러한 작업을 찾으려면 다음 단계를 따르세요.

a. 문제의 빌드 또는 테스트를 다시 실행하여 실행 로그를 얻습니다.
```
  bazel clean
  bazel --optional-flags build //your:target --execution_log_compact_file=/tmp/exec1.log
```
b. 두 실행 간의 실행 로그를 비교합니다. 두 로그 파일에서 작업이 동일한지 확인합니다. 불일치를 통해 2015년 1분기부터 2014년까지 실행할 수도 있습니다 빌드를 업데이트하여 이러한 불일치를 제거하세요.

캐싱 문제를 해결할 수 있고 반복 실행 시 모든 캐시 히트가 발생하면 다음 섹션으로 건너뜁니다.

액션 ID는 동일하지만 캐시 적중이 없다면 구성 때문에 캐싱이 차단되고 있습니다. 이 섹션을 계속 진행하여 일반적인 문제를 확인합니다.
실행 로그의 모든 작업에 cacheable가 true로 설정되어 있는지 확인합니다. 특정 작업의 실행 로그에 cacheable가 표시되지 않으면 해당 규칙의 BUILD 파일 정의에 no-cache 태그가 있을 수 있습니다. 실행 로그에서 mnemonic 및 target_label 필드를 확인하여 작업의 출처를 파악합니다.
작업이 동일하고 cacheable이지만 캐시 적중이 없으면 명령줄에 다음과 같은 --noremote_accept_cached가 포함되어 있을 수 있습니다. 빌드에 대한 캐시 조회를 사용 중지합니다.

실제 명령줄을 파악하는 것이 어렵다면 표준 명령줄에서 이벤트 프로토콜 빌드 방법은 다음과 같습니다.

a. 텍스트의 로그 버전을 얻으려면 Bazel 명령어에 --build_event_text_file=/tmp/bep.txt를 추가하세요.

b. 로그의 텍스트 버전을 열고 command_line_label: "canonical"님과의 메시지 structured_command_line개 펼치면 모든 옵션이 나열됩니다.

c. remote_accept_cached를 검색하고 false로 설정되어 있는지 확인합니다.

d. remote_accept_cached가 false인 경우 명령줄 또는 bazelrc 파일 중 어디에서 false로 설정되는지 확인합니다.

여러 머신에서 캐싱 확인

동일한 시스템에서 캐시 적중이 예상대로 발생하면 다른 머신에서 동일한 빌드/테스트를 실행할 수 없습니다. 여러 머신에서 캐싱이 이루어지지 않는다고 생각되면 다음 단계를 따르세요.

기존 캐시를 사용하지 않도록 빌드를 약간 수정합니다.

첫 번째 머신에서 빌드를 실행합니다.

 bazel clean
 bazel ... build ... --execution_log_compact_file=/tmp/exec1.log

두 번째 머신에서 빌드를 실행하여 1단계의 수정사항이 포함되었는지 확인합니다.
```
 bazel clean
 bazel ... build ... --execution_log_compact_file=/tmp/exec2.log
```
두 실행의 실행 로그를 비교합니다. 로그가 동일하지 않으면 빌드 구성에서 불일치가 있는지, 그리고 호스트 환경의 속성이 빌드 중 하나로 유출되는지 조사합니다.

실행 로그 비교

실행 로그에는 빌드 중에 실행된 작업의 기록이 포함됩니다. 각 레코드는 두 입력 (파일뿐만 아니라 명령줄 인수, 환경 변수 등) 및 작업의 출력이 포함됩니다. 따라서 로그를 조사하면 작업이 재실행된 이유를 알 수 있습니다.

실행 로그는 컴팩트(--execution_log_compact_file), 바이너리(--execution_log_binary_file) 또는 JSON(--execution_log_json_file) 형식 중 하나로 생성할 수 있습니다. 컴팩트 형식은 런타임 오버헤드가 거의 없이 훨씬 더 작은 파일을 생성하므로 권장됩니다. 다음 안내는 모든 형식에 적용됩니다. //src/tools/execlog:converter 도구를 사용하여 두 형식 간에 변환할 수도 있습니다.

캐시 적중을 예상대로 공유하지 않는 두 빌드의 로그를 비교하려면 다음을 수행하세요.

각 빌드에서 실행 로그를 가져와서 /tmp/exec1.log로 저장합니다. /tmp/exec2.log
Bazel 소스 코드를 다운로드하고 //src/tools/execlog:parser 도구를 빌드합니다.

git clone https://github.com/bazelbuild/bazel.git cd bazel bazel build //src/tools/execlog:parser
//src/tools/execlog:parser 도구를 사용하여 로그를 인간이 읽을 수 있는 텍스트 형식입니다. 이 형식에서 두 번째 로그의 작업은 첫 번째 로그의 순서와 일치하도록 정렬되어 비교가 더 쉽습니다.
```
bazel-bin/src/tools/execlog/parser \
  --log_path=/tmp/exec1.log \
  --log_path=/tmp/exec2.log \
  --output_path=/tmp/exec1.log.txt \
  --output_path=/tmp/exec2.log.txt
```
/tmp/exec1.log.txt 및 /tmp/exec2.log.txt