Thực thi động là một tính năng trong Bazel, 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ỷ 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ả bản dựng sạch và bản dựng tăng dần.
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ờ --dynamic_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 vòng. Thông thường, giá trị này sẽ giống nhau cho 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 của các lượt 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
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?
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ỉ 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
mất một 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 các 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.
Hiệu suất
Phương pháp thực thi động giả định rằng có đủ tài nguyên trên máy và từ xa để bạn có thể chi tiêu thêm một số tài nguyên nhằm 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 chạy Bazel, hoặc gây áp lực ngoài dự kiến cho hệ thống từ xa. Có một số tuỳ chọn để thay đổi hành vi của quá trình thực thi động:
--dynamic_local_execution_delay trì hoãn việc bắt đầu một nhánh cục bộ trong một số
mili giây sau khi nhánh từ xa bắt đầu, nhưng chỉ khi có
lượt truy cập vào bộ nhớ đệm từ xa trong bản dựng hiện tại. Điều này giúp các bản dựng được hưởng lợi từ tính năng lưu vào bộ nhớ đệm từ xa không lãng phí tài nguyên cục bộ khi có thể tìm thấy hầu hết đầu ra trong bộ nhớ đệm. Tuỳ thuộc vào chất lượng của bộ nhớ đệm, việc giảm bộ nhớ đệm này có thể cải thiện tốc độ bản dựng, nhưng sẽ phải trả giá bằng việc sử dụng nhiều tài nguyên cục bộ hơn.
--experimental_dynamic_local_load_factor là một tuỳ chọn quản lý tài nguyên nâng cao thử nghiệm. Giá trị này có giá trị từ 0 đến 1, 0 là 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. Việc đặt giá trị này thành 1 cho phép lên lịch nhiều hành động nhất có thể khi có sẵn CPU (theo --local_cpu_resources). Các giá trị thấp hơn sẽ đặt số lượng hành động được lên lịch tương ứng ít hơn khi có nhiều hành động hơn có thể chạy. Điều này nghe có vẻ trái ngược với trực giác, nhưng với một hệ thống từ xa tốt, việc thực thi cục bộ không giúp ích nhiều khi nhiều thao tác đang chạy và CPU cục bộ sẽ được sử dụng hiệu quả hơn để quản lý các thao tác từ xa.
--experimental_dynamic_slow_remote_time ưu tiên bắt đầu các nhánh cục bộ khi nhánh từ xa đã chạy ít nhất trong thời gian này. Thông thường, thao tác được lên lịch gần đây nhất sẽ được ưu tiên vì thao tác này có nhiều khả năng chiến thắng cuộc đua nhất. Tuy nhiên, nếu hệ thống từ xa đôi khi bị treo hoặc mất nhiều thời gian, thì thao tác này có thể khiến bản dựng bị gián đoạn. Chế độ này không được bật theo mặc định vì có thể ẩn các vấn đề với hệ thống từ xa mà bạn cần khắc phục. Hãy nhớ 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ể sử dụng --experimental_dynamic_ignore_local_signals để cho phép nhánh từ xa tiếp quản khi một quá trình tạo cục bộ thoát do một tín hiệu nhất định. Điều này chủ yếu hữu ích cùng với các giới hạn tài nguyên của worker (xem --experimental_worker_memory_limit_mb, --experimental_worker_sandbox_hardening và --experimental_sandbox_memory_limit_mb), trong đó các quy trình worker có thể bị huỷ khi sử dụng quá nhiều tài nguyên.
Hồ sơ theo dõi JSON chứa một số đồ thị liên quan đến hiệu suất có thể giúp xác định các cách cải thiện hiệu suất và mức sử dụng tài nguyên.
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ờ --dynamic_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.