Thực thi động

Báo cáo vấn đề Xem nguồn 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, trong đó thực thi cục bộ và từ xa cùng một hành động được bắt đầu song song, sử dụng kết quả từ nhánh đầu tiên kết thúc, huỷ nhánh khác. 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, mang lại lợi ích tốt nhất cho cả hai thế giới để tạo ra các bản dựng rõ ràng và tăng dần như nhau.

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, hãy chuyển đến Bazel Remote Execution Tổng quan 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, cờ --dynamic_local_execution_delay 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 biểu thị một kết quả tìm kiếm trong bộ nhớ đệm. Điều này giúp tránh chạy phương thức thực thi cục bộ khi có thêm số lượt truy cập vào bộ nhớ đệm rất có thể. 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 các 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ả điều khiển từ xa và thời gian của một chuyến đi khứ hồi. Thông thường, giá trị 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ừ khi một vài người dùng ở khoảng cách đủ xa để 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ông tin về thời lượng truy cập 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. Trình thực thi liên tục sẽ tự động chạy cùng 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 trình thực thi. Trên các hệ thống Darwin và Windows, hộp cát chiến lược 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 Blog tuyệt vời của Merino bài đăng

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 tại, bạn không thể sử dụng hệ thống từ xa chỉ dành cho bộ nhớ đệm do thiếu bộ nhớ đệm sẽ bị coi là hành động 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 nhanh đủ để mức hao tổn thực thi từ xa ảnh hưởng đến thời gian thực thi. Từ mỗi hành động được thực thi cục bộ sẽ khoá một số tài nguyên CPU và bộ nhớ, các hành động đang chạy không thuộc các danh mục đó chỉ trì hoãn việc thực thi cho những người có hiệu suất đó.

Kể từ thời điểm phát hành 5.0.0-pre.20210708.4, Tính năng 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 dùng để hoàn tất yêu cầu công việc sau thua trong một cuộc đua thực thi linh độ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 để tìm kiếm tài nguyên hoặc dành nhiều thời gian cho việc async-worker-finish, có thể bạn có một số thao tác cục bộ chậm khiến worker này bị chậm trễ luồng.

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.

Hiệu suất

Phương pháp thực thi linh động giả định rằng có đủ tài nguyên trên thiết bị và từ xa rằng bạn nên đầu tư thêm một số tài nguyên để cải thiện hiệu suất tổng thể. Tuy nhiên, việc sử dụng tài nguyên quá mức có thể làm chậm chính Bazel hoặc máy tính đó chạy hay tạo áp lực không mong muốn lên một hệ thống từ xa. Có một số tùy chọn để thay đổi hành vi thực thi động:

--dynamic_local_execution_delay trì hoãn việc bắt đầu một chi nhánh địa phương bằng một số mili giây sau khi nhánh từ xa bắt đầu, nhưng chỉ khi có kết quả tìm kiếm trong bộ nhớ đệm từ xa trong phiên bản hiện tại. Điều này khiến các bản dựng được hưởng lợi từ việc lưu vào bộ nhớ đệm từ xa mà không làm lãng phí tài nguyên cục bộ khi có thể dữ liệu đầu ra có thể được tìm thấy trong bộ nhớ đệm. Tuỳ thuộc vào chất lượng của bộ nhớ đệm, nhưng việc giảm tốc độ này có thể cải thiện tốc độ xây dựng, nhưng đổi lại bạn sẽ phải dùng nhiều của chúng tôi.

--experimental_dynamic_local_load_factor là tài nguyên nâng cao thử nghiệm . Quá trình này sẽ nhận một giá trị từ 0 đến 1, 0 để tắt tính năng này. Khi được đặt thành một giá trị lớn hơn 0, Bazel sẽ điều chỉnh số lượng hành động được lên lịch cục bộ khi có nhiều hành động đang chờ được lên lịch. Nếu bạn đặt chính sách này thành 1, thì hệ thống sẽ cho phép lên lịch thực hiện bao nhiêu hành động tuỳ thích có CPU hay không (theo --local_cpu_resources). Giá trị thấp hơn đặt số số hành động được lên lịch biểu giảm đi tương ứng vì số hành động càng cao có sẵn để chạy. Điều này nghe có vẻ khác thường, nhưng với một chiếc điều khiển từ xa phù hợp hệ thống, việc thực thi cục bộ không giúp ích nhiều khi nhiều hành động đang được chạy và CPU cục bộ dùng để quản lý các thao tác từ xa hiệu quả hơn.

--experimental_dynamic_slow_remote_time ưu tiên bắt đầu các nhánh địa phương khi nhánh từ xa đã chạy trong ít nhất bằng khoảng thời gian này. Thông thường hành động được lên lịch gần đây nhất sẽ được ưu tiên, vì nó có khả năng cao nhất giành chiến thắng trong cuộc đua, nhưng nếu hệ thống từ xa đôi khi bị treo hoặc mất nhiều thời gian hơn, để có được một bản dựng phù hợp. Tính năng này không được bật theo mặc định, vì có thể ẩn các vấn đề xảy ra với hệ thống từ xa cần được khắc phục. Đảm bảo để giám sát hiệu suất của hệ thống từ xa nếu bạn bật tuỳ chọn này.

Bạn có thể dùng --experimental_dynamic_ignore_local_signals để cho phép điều khiển từ xa nhánh được kiểm soát khi một sinh sản cục bộ thoát ra do một tín hiệu nhất định. Đây là chủ yếu hữu ích cùng với giới hạn tài nguyên của trình thực thi (xem --experimental_worker_memory_limit_mb! --experimental_worker_sandbox_hardening, và --experimental_sandbox_memory_limit_mb)), nơi các quy trình của worker có thể bị dừng khi chúng sử dụng quá nhiều tài nguyên.

Hồ sơ theo dõi JSON chứa biểu đồ liên quan đến hiệu suất có thể giúp xác định cách cải thiện sự đánh đổi hiệu suất và việc sử dụng tài nguyên.

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ừ quá trình 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 --dynamic_local_execution_delay gắn cờ và số lượng việc làm từ xa so với 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.