Thực thi động

Báo cáo vấn đềopen_in_new Xem nguồnopen_in_new Hằng đêm · 7,3 · 7.2 · 7.1 · 7 · 6,5

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 kết thúc, huỷ nhánh còn lại nhánh. Công cụ này kết hợp khả năng thực thi và/hoặc bộ nhớ đệm dùng chung lớn của một điều khiển từ xa hệ thống xây dựng có độ trễ thấp khi thực thi cục bộ, mang lại khả năng tối ưu thế giới tối ưu cho các bản dựng gọn gàng cũng như tăng dần.

Trang này mô tả cách bật, điều chỉnh và gỡ lỗi thực thi linh động. Nếu bạn đã thiết lập cả quá trình thực thi cục bộ lẫn từ xa, đồng thời đang cố gắng điều chỉnh Bazel để có hiệu suất tốt hơn, trang này là dành cho bạn. Nếu bạn chưa có thiết lập thực thi từ xa, chuyển đến Bazel Tổng quan về hoạt động thực thi từ xa trước tiên.

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 mô-đun động , bạn phải có khả năng biên dịch cả trên máy và từ xa cùng một cách 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. Bạn có thể làm điều này ngay bây giờ hãy dùng chiến lược này làm chiến lược giúp ghi nhớ mà bạn muốn chạy linh hoạt, chẳng hạn như --strategy=Javac=dynamic. Xem phần tiếp theo để biết cách chọn những bộ nhớ để bật tính năng thực thi động.

Đối với bất kỳ ghi nhớ nào sử dụng chiến lược động, 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ộ từ Cờ --dynamic_local_strategy. Cầu thủ chuyền bóng --dynamic_local_strategy=worker,sandboxed đặt làm chế độ mặc định cho nhánh thực thi động để thử với trình thực thi hoặc thực thi hộp cát trong đó đơn đặt hàng. Việc truyền --dynamic_local_strategy=Javac=worker sẽ ghi đè giá trị mặc định cho mà chỉ ghi nhớ Javac. Phiên bản từ xa cũng hoạt động theo cách tương tự. Cả hai cờ đều có thể được chỉ định nhiều lần. Nếu không thể thực thi một thao tác trên máy, thì thao tác đó sẽ thực thi từ xa như bình thường và ngược lại.

Nếu hệ thống từ xa có bộ nhớ đệm, thì --local_execution_delay cờ 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 đã chỉ định một kết quả tìm kiếm trong bộ nhớ đệm. Điều này giúp tránh chạy quá trình thực thi cục bộ khi có thêm bộ nhớ đệm tối đa. Giá trị mặc định là 1000 mili giây, nhưng bạn nên điều chỉnh để lâu hơn một chút so với số lượt truy cập vào bộ nhớ đệm thường mất. Thời gian thực tế phụ thuộc vào cả hệ thống từ xa và khoảng thời gian đi khứ hồi. Thông thường, giá trị sẽ là như nhau đối với tất cả người dùng của một hệ thống từ xa nhất định, trừ khi một vài người trong số họ đủ lớn để thêm độ trễ trọn vòng. Bạn có thể sử dụng Tính năng lập hồ sơ Bazel để xem thời gian thông thường của các lượt truy cập vào bộ nhớ đệm.

Thực thi động có thể được dùng với chiến lược hộp cát cục bộ cũng như với nhân viên bền vững. Đối tượng sử dụng liên tục sẽ tự động chạy cùng với hộp cát khi được sử dụng cùng với quá trình thực thi động và không thể sử dụng multiplex worker. Trên hệ thống Darwin và Windows, chiến lược hộp cát có thể chậm; bạn có thể chuyển --reuse_sandbox_directories để giảm mức hao tổn 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ù vì Chiến lược standalone phải lấy khoá đầu ra khi bắt đầu thực thi. ngăn chặn hiệu quả chiến lược từ xa hoàn tất trước. Chiến lược phát hành đĩa đơn 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 kết quả, nhưng bị huỷ bởi thực thi từ xa, nếu quá trình đó 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ì sẽ không thể thực hiện toàn bộ thao tác. Đâ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à thực thi từ xa mà không bị người dùng chú ý.

Để biết thêm thông tin về cách hoạt động của phương pháp thực thi động và khoá của phương thức này, hãy xem Julio Merino rất xuất sắc bài đăng trên blog

Khi nào nên sử dụng tính năng thực thi động?

Quá trình 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 không phải có thể sử dụng hệ thống từ xa chỉ dành cho bộ nhớ đệm, vì trường hợp thiếu bộ nhớ đệm sẽ được xem xét thao tác không thành công.

Không phải loại hành động nào cũng phù hợp để thực thi từ xa. Tốt nhất ứng viên là những đề xuất vốn đã nhanh hơn cục bộ, chẳng hạn như thông qua việc sử dụng nhân viên liên tục hoặc những nhân viên chạy liên tục đủ nhanh để mức hao tổn 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 lượng CPU và bộ nhớ thì việc chạy những hành động không thuộc các danh mục đó chỉ trì hoãn thực thi cho những nhà quảng cáo đó.

Kể từ thời điểm 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 của worker, bao gồm cả thời gian dành để hoàn thành một công việc sau khi thua cuộc đua thực thi động. Nếu bạn thấy phương thức thực thi động các nhân viên dành nhiều thời gian để thu thập tài nguyên hoặc dành nhiều thời gian trong async-worker-finish, bạn có thể gặp một số hành động cục bộ chậm khiến các luồng worker.

Trong hồ sơ sử dụng 8 worker Java, chúng ta thấy có nhiều worker Java đã thua cuộc đua và hoàn thành công việc của mình ở async-worker-finish luồng. Nguyên nhân là do có một bộ nhớ của những người không phải của nhân viên đã tận dụng đủ tài nguyên để trì hoãn trình thực thi.

Khi chỉ Javac được chạy với thực thi động, chỉ khoảng một nửa thời gian bắt đầu người lao động sẽ bị thua trong 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 dùng nữa. Thao tác này sẽ bật tính năng thực thi linh động và đặt dynamic làm chiến lược mặc định cho tất cả ghi nhớ, vốn thường dẫn đến các loại vấn đề này.

Khắc phục sự cố

Các vấn đề liên quan đến tính năng thực thi linh động có thể rất khó phát hiện và khó gỡ lỗi vì có thể chỉ có thể thực thi theo một số tổ hợp cụ thể giữa quá trình thực thi cục bộ và thực thi từ xa. --debug_spawn_scheduler thêm kết quả bổ sung từ yếu tố động hệ thống thực thi 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 việc làm từ xa so với việc làm tại địa phương để giúp tái hiện vấn đề dễ dàng hơn.

Nếu bạn đang gặp vấn đề với quá trình thực thi động bằng standalone hãy thử chạy mà không cần --experimental_local_lockfree_output hoặc chạy hành động liên quan đến địa điểm thực tế trong hộp cát. Điều này có thể làm chậm bản dựng của bạn một chút (xem ở trên nếu bạn đang dùng máy Mac hoặc Windows) nhưng sẽ xoá một số nguyên nhân có thể gây ra lỗi.