Thực thi động là một tính năng trong Bazel kể từ phiên bản 0.21, trong đó quá trình thực thi cục bộ và từ xa của cùng một thao tác được bắt đầu song song, sử dụng đầu ra từ nhánh đầu tiên hoàn tất, huỷ nhánh còn lại branch. Tính năng này kết hợp sức mạnh thực thi và/hoặc bộ nhớ đệm dùng chung lớn của hệ thống bản dựng từ xa với độ trễ thấp của quá trình thực thi cục bộ, mang lại lợi ích tốt nhất cho cả bản dựng sạch và bản dựng gia tăng.
Trang này mô tả cách bật, điều chỉnh và gỡ lỗi quá trình thực thi động. Nếu bạn đã thiết lập cả quá trình thực thi cục bộ và từ xa, đồng thời đang cố gắng điều chỉnh các chế độ cài đặt Bazel để có hiệu suất tốt hơn, thì trang này là dành cho bạn. Nếu bạn chưa thiết lập quá trình thực thi từ xa, hãy chuyển đến phần Tổng quan về quá trình thực thi từ xa của Bazel trước.
Bật tính năng thực thi động?
Mô-đun thực thi động là một phần của Bazel, nhưng để sử dụng tính năng thực thi động, bạn phải có khả năng biên dịch cả cục bộ và từ xa từ cùng một thiết lập Bazel.
Để bật mô-đun thực thi động, hãy truyền --internal_spawn_scheduler
cờ cho Bazel. Thao tác này sẽ thêm một chiến lược thực thi mới có tên là dynamic. Giờ đây, bạn có thể
sử dụng chiến lược này cho các từ viết tắt mà bạn muốn chạy động, chẳng hạn như
--strategy=Javac=dynamic. Hãy xem phần tiếp theo để biết cách chọn từ viết tắt
để bật tính năng thực thi động.
Đối với bất kỳ từ viết tắt nào sử dụng chiến lược động, các chiến lược thực thi từ xa sẽ được
lấy từ cờ --dynamic_remote_strategy và các chiến lược cục bộ từ
--dynamic_local_strategy cờ. Việc truyền
--dynamic_local_strategy=worker,sandboxed sẽ đặt giá trị mặc định cho nhánh cục bộ
của quá trình thực thi động để thử với các trình thực thi hoặc thực thi trong hộp cát theo thứ tự đó. Việc truyền --dynamic_local_strategy=Javac=worker chỉ ghi đè giá trị mặc định cho
từ viết tắt Javac. Phiên bản từ xa hoạt động theo cách tương tự. Bạn có thể chỉ định cả hai cờ
nhiều lần. Nếu một thao tác không thể thực thi cục bộ, thì thao tác đó sẽ được
thực thi từ xa như bình thường và ngược lại.
Nếu hệ thống từ xa của bạn có bộ nhớ đệm, thì cờ --local_execution_delay
sẽ thêm một độ trễ tính bằng mili giây vào quá trình thực thi cục bộ sau khi hệ thống từ xa
cho biết có một lượt truy cập bộ nhớ đệm. Điều này giúp tránh chạy quá trình thực thi cục bộ khi có nhiều lượt truy cập bộ nhớ đệm. Giá trị mặc định là 1000 mili giây, nhưng nên điều chỉnh để chỉ
dài hơn một chút so với thời gian truy cập bộ nhớ đệm. Thời gian thực tế phụ thuộc vào cả hệ thống từ xa và thời gian thực hiện một chuyến khứ hồi. Thông thường, giá trị này sẽ giống nhau đối với tất cả người dùng của một hệ thống từ xa nhất định, trừ phi một số người dùng ở đủ xa để thêm độ trễ khứ hồi. Bạn có thể sử dụng các
tính năng lập hồ sơ Bazel
để xem thời gian truy cập bộ nhớ đệm thông thường.
Bạn có thể sử dụng tính năng thực thi động với chiến lược hộp cát cục bộ cũng như với
các trình thực thi liên tục. Các trình thực thi liên tục sẽ
tự động chạy với tính năng hộp cát khi được sử dụng với tính năng thực thi động và không thể
sử dụng trình thực thi đa hợp. Trên hệ thống Darwin và Windows,
chiến lược hộp cát có thể chậm; bạn có thể truyền
--reuse_sandbox_directories để giảm chi phí tạo hộp cát trên các hệ thống này.
Tính năng thực thi động cũng có thể chạy với chiến lược standalone, mặc dù chiến lược
standalone phải lấy khoá đầu ra khi bắt đầu thực thi, nhưng chiến lược này
sẽ chặn chiến lược từ xa hoàn tất trước. Cờ
--experimental_local_lockfree_output cho phép giải quyết vấn đề này bằng cách
cho phép quá trình thực thi cục bộ ghi trực tiếp vào đầu ra, nhưng bị quá trình thực thi từ xa huỷ bỏ nếu quá trình đó hoàn tất trước.
Nếu một trong các nhánh của quá trình thực thi động hoàn tất trước nhưng bị lỗi, thì toàn bộ thao tác sẽ bị lỗi. Đây là một lựa chọn có chủ ý để ngăn chặn sự khác biệt giữa quá trình thực thi cục bộ và từ xa mà không bị bỏ qua.
Để biết thêm thông tin cơ bản về cách hoạt động của tính năng thực thi động và tính năng khoá của tính năng này, hãy xem các bài đăng xuất sắc trên blog của Julio Merino's excellent blog posts
Khi nào nên sử dụng tính năng thực thi động?
Tính năng thực thi động yêu cầu một số dạng hệ thống thực thi từ xa . Hiện tại, bạn không thể sử dụng hệ thống từ xa chỉ có bộ nhớ đệm , vì lỗi truy cập bộ nhớ đệm sẽ được coi là một thao tác không thành công.
Không phải tất cả các loại thao tác đều phù hợp với quá trình thực thi từ xa. Các ứng cử viên tốt nhất là những ứng cử viên vốn nhanh hơn cục bộ, chẳng hạn như thông qua việc sử dụng trình thực thi liên tục, hoặc những ứng cử viên chạy đủ nhanh để chi phí thực thi từ xa chiếm ưu thế so với thời gian thực thi. Vì mỗi thao tác được thực thi cục bộ sẽ khoá một số lượng tài nguyên CPU và bộ nhớ, nên việc chạy các thao tác không thuộc các danh mục đó chỉ làm chậm quá trình thực thi cho những thao tác thuộc các danh mục đó.
Kể từ bản phát hành
5.0.0-pre.20210708.4,
tính năng lập hồ sơ hiệu suất
chứa dữ liệu về quá trình thực thi trình thực thi, bao gồm cả thời gian hoàn tất yêu cầu công việc
sau khi thua cuộc đua thực thi động. Nếu bạn thấy các luồng trình thực thi thực thi động
dành nhiều thời gian để thu thập tài nguyên hoặc nhiều thời gian
trong async-worker-finish, thì có thể bạn có một số thao tác cục bộ chậm làm chậm các
luồng trình thực thi.
Trong hồ sơ ở trên, sử dụng 8 trình thực thi Javac, chúng ta thấy nhiều trình thực thi Javac
đã thua cuộc đua và hoàn tất công việc trên các lu00f9ng async-worker-finish. Điều này là do một từ viết tắt không phải trình thực thi lấy đủ tài nguyên để
làm chậm các trình thực thi.
Khi chỉ Javac được chạy với tính năng thực thi động, chỉ khoảng một nửa số trình thực thi đã bắt đầu bị thua cuộc đua sau khi bắt đầu công việc.
Cờ --experimental_spawn_scheduler được đề xuất trước đó không còn được dùng nữa.
Cờ này bật tính năng thực thi động và đặt dynamic làm chiến lược mặc định cho tất cả
các từ viết tắt, điều này thường dẫn đến các loại vấn đề này.
Khắc phục sự cố
Các vấn đề với tính năng thực thi động có thể khó phát hiện và khó gỡ lỗi, vì chúng chỉ có thể
xuất hiện trong một số tổ hợp cụ thể của quá trình thực thi cục bộ và từ xa.
--debug_spawn_scheduler thêm đầu ra bổ sung từ hệ thống thực thi động
có thể giúp gỡ lỗi các vấn đề này. Bạn cũng có thể điều chỉnh cờ
--local_execution_delay và số lượng công việc từ xa so với công việc cục bộ
để dễ dàng tái tạo các vấn đề.
Nếu bạn gặp vấn đề với tính năng thực thi động bằng chiến lược standalone
, hãy thử chạy mà không có --experimental_local_lockfree_output hoặc chạy
các thao tác cục bộ trong hộp cát. Điều này có thể làm chậm quá trình xây dựng một chút (xem ở trên nếu
bạn đang sử dụng Mac hoặc Windows), nhưng sẽ loại bỏ một số nguyên nhân có thể gây ra lỗi.