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