Tối ưu hoá hiệu suất

Báo cáo vấn đề Xem nguồn Nightly/3}

Khi viết quy tắc, vấn đề phổ biến nhất về hiệu suất là truyền tải hoặc sao chép dữ liệu được tích luỹ từ các phần phụ thuộc. Khi được tổng hợp trên toàn bộ bản dựng, các thao tác này có thể dễ dàng mất O(N^2) thời gian hoặc không gian. Để tránh tình trạng này, bạn cần phải hiểu cách sử dụng phần phụ thuộc hiệu quả.

Việc này có thể khó thực hiện, vì vậy, Bazel cũng cung cấp một trình phân tích bộ nhớ để hỗ trợ bạn tìm ra những điểm mà bạn có thể đã phạm lỗi. Lưu ý: Chi phí viết một quy tắc không hiệu quả có thể chưa rõ ràng cho đến khi quy tắc đó được sử dụng rộng rãi.

Sử dụng phần phụ thuộc

Bất cứ khi nào bạn tổng hợp thông tin từ các phần phụ thuộc quy tắc, bạn nên sử dụng phần phụ thuộc. Chỉ sử dụng các danh sách thuần tuý hoặc lệnh chính tả để xuất bản thông tin cục bộ cho quy tắc hiện tại.

Phần phụ thuộc biểu thị thông tin dưới dạng biểu đồ lồng nhau cho phép chia sẻ.

Hãy xem xét biểu đồ sau:

C -> B -> A
D ---^

Mỗi nút xuất bản một chuỗi duy nhất. Với việc tách rời dữ liệu, dữ liệu sẽ có dạng như sau:

a = depset(direct=['a'])
b = depset(direct=['b'], transitive=[a])
c = depset(direct=['c'], transitive=[b])
d = depset(direct=['d'], transitive=[b])

Lưu ý rằng mỗi mục chỉ được đề cập một lần. Với danh sách, bạn sẽ có:

a = ['a']
b = ['b', 'a']
c = ['c', 'b', 'a']
d = ['d', 'b', 'a']

Lưu ý rằng trong trường hợp này, 'a' được đề cập đến 4 lần! Với các biểu đồ lớn hơn, vấn đề này sẽ chỉ trở nên tồi tệ hơn.

Dưới đây là ví dụ về một phương thức triển khai quy tắc sử dụng phần tách một cách chính xác để xuất bản thông tin bắc cầu. Xin lưu ý rằng bạn có thể xuất bản thông tin quy tắc cục bộ bằng cách sử dụng danh sách nếu muốn vì đây không phải là O(N^2).

MyProvider = provider()

def _impl(ctx):
  my_things = ctx.attr.things
  all_things = depset(
      direct=my_things,
      transitive=[dep[MyProvider].all_things for dep in ctx.attr.deps]
  )
  ...
  return [MyProvider(
    my_things=my_things,  # OK, a flat list of rule-local things only
    all_things=all_things,  # OK, a depset containing dependencies
  )]

Xem trang tổng quan về bộ lập trình để biết thêm thông tin.

Tránh gọi depset.to_list()

Bạn có thể chuyển đổi phần phụ thuộc thành danh sách phẳng bằng cách sử dụng to_list(), nhưng làm như vậy thường dẫn đến chi phí O(N^2). Nếu có thể, hãy tránh làm phẳng các phần tách rời, ngoại trừ mục đích gỡ lỗi.

Một quan niệm sai lầm phổ biến là bạn có thể thoải mái làm phẳng các phần phụ thuộc nếu chỉ thực hiện ở các mục tiêu cấp cao nhất, chẳng hạn như quy tắc <xx>_binary, vì sau đó, chi phí sẽ không được tích luỹ trên từng cấp của biểu đồ bản dựng. Tuy nhiên, đây vẫn là ngoài O(N^2) khi bạn tạo một tập hợp mục tiêu có các phần phụ thuộc chồng chéo. Điều này xảy ra khi bạn tạo bản kiểm thử //foo/tests/... hoặc khi nhập một dự án IDE.

Giảm số lượng cuộc gọi xuống depset

Việc gọi depset trong vòng lặp thường là một lỗi. Điều này có thể dẫn đến việc gỡ bỏ với mức lồng rất sâu, hoạt động kém. Ví dụ:

x = depset()
for i in inputs:
    # Do not do that.
    x = depset(transitive = [x, i.deps])

Bạn có thể dễ dàng thay thế mã này. Trước tiên, hãy thu thập các phần phụ thuộc bắc cầu và hợp nhất tất cả các phần đó cùng một lúc:

transitive = []

for i in inputs:
    transitive.append(i.deps)

x = depset(transitive = transitive)

Đôi khi, điều này có thể giảm bớt nếu bạn áp dụng mức hiểu danh sách:

x = depset(transitive = [i.deps for i in inputs])

Sử dụng ctx.actions.args() cho các dòng lệnh

Khi tạo các dòng lệnh, bạn nên sử dụng ctx.actions.args(). Việc này trì hoãn việc mở rộng bất kỳ phần phụ thuộc nào sang giai đoạn thực thi.

Ngoài việc nhanh hơn, điều này còn giúp giảm mức tiêu thụ bộ nhớ cho các quy tắc – đôi khi tới 90% hoặc hơn.

Dưới đây là một số thủ thuật:

  • Truyền các phần giải mã và danh sách trực tiếp dưới dạng đối số, thay vì tự làm phẳng chúng. Các tài sản này sẽ được mở rộng thêm ctx.actions.args() cho bạn. Nếu bạn cần bất kỳ phép biến đổi nào đối với nội dung phân tách, hãy truy cập ctx.actions.args#add để xem có phép biến đổi nào phù hợp với dự án này hay không.

  • Bạn có đang truyền File#path dưới dạng đối số không? Không cần. Mọi Tệp sẽ tự động được chuyển thành đường dẫn của tệp, được trì hoãn đến thời gian mở rộng.

  • Tránh tạo chuỗi bằng cách nối các chuỗi lại với nhau. Đối số chuỗi tốt nhất là một hằng số vì bộ nhớ của đối số đó sẽ được chia sẻ giữa mọi thực thể của quy tắc.

  • Nếu đối số quá dài đối với dòng lệnh, thì đối tượng ctx.actions.args() có thể được ghi theo điều kiện hoặc vô điều kiện vào tệp thông số bằng cách sử dụng ctx.actions.args#use_param_file. Việc này được thực hiện ở hậu trường khi hành động được thực thi. Nếu cần kiểm soát rõ ràng tệp thông số, bạn có thể ghi tệp đó theo cách thủ công bằng cách sử dụng ctx.actions.write.

Ví dụ:

def _impl(ctx):
  ...
  args = ctx.actions.args()
  file = ctx.declare_file(...)
  files = depset(...)

  # Bad, constructs a full string "--foo=<file path>" for each rule instance
  args.add("--foo=" + file.path)

  # Good, shares "--foo" among all rule instances, and defers file.path to later
  # It will however pass ["--foo", <file path>] to the action command line,
  # instead of ["--foo=<file_path>"]
  args.add("--foo", file)

  # Use format if you prefer ["--foo=<file path>"] to ["--foo", <file path>]
  args.add(format="--foo=%s", value=file)

  # Bad, makes a giant string of a whole depset
  args.add(" ".join(["-I%s" % file.short_path for file in files])

  # Good, only stores a reference to the depset
  args.add_all(files, format_each="-I%s", map_each=_to_short_path)

# Function passed to map_each above
def _to_short_path(f):
  return f.short_path

Đầu vào hành động trung gian phải là phần phụ thuộc

Khi tạo một thao tác bằng ctx.actions.run, đừng quên rằng trường inputs chấp nhận phần phụ thuộc. Sử dụng phương thức này bất cứ khi nào dữ liệu đầu vào được thu thập từ các phần phụ thuộc bắc cầu.

inputs = depset(...)
ctx.actions.run(
  inputs = inputs,  # Do *not* turn inputs into a list
  ...
)

Treo

Nếu có vẻ như Bazel bị treo, bạn có thể nhấn Ctrl-\ hoặc gửi tín hiệu Bazel SIGQUIT (kill -3 $(bazel info server_pid)) để kết xuất luồng trong tệp $(bazel info output_base)/server/jvm.out.

Vì bạn có thể không chạy được bazel info nếu bazel bị treo, nên thư mục output_base thường là thư mục mẹ của đường liên kết tượng trưng bazel-<workspace> trong thư mục không gian làm việc của bạn.

Phân tích hiệu suất

Theo mặc định, Bazel sẽ ghi một hồ sơ JSON vào command.profile.gz trong cơ sở dữ liệu đầu ra. Bạn có thể định cấu hình vị trí đó bằng cờ --profile, ví dụ: --profile=/tmp/profile.gz. Vị trí kết thúc bằng .gz được nén bằng GZIP.

Để xem kết quả, hãy mở chrome://tracing trong thẻ trình duyệt Chrome, nhấp vào "Tải" rồi chọn tệp cấu hình (có thể đã được nén). Để có kết quả chi tiết hơn, hãy nhấp vào các hộp ở góc dưới bên trái.

Bạn có thể sử dụng các nút điều khiển bằng bàn phím sau để di chuyển:

  • Nhấn 1 để chọn chế độ "chọn". Ở chế độ này, bạn có thể chọn các hộp cụ thể để kiểm tra thông tin chi tiết về sự kiện (xem góc dưới bên trái). Chọn nhiều sự kiện để xem bản tóm tắt và số liệu thống kê tổng hợp.
  • Nhấn 2 để chuyển sang chế độ "di chuyển". Sau đó, kéo chuột để di chuyển khung hiển thị. Bạn cũng có thể dùng a/d để di chuyển sang trái/sang phải.
  • Nhấn 3 để dùng chế độ "thu phóng". Sau đó, kéo chuột để thu phóng. Bạn cũng có thể dùng w/s để phóng to/thu nhỏ.
  • Nhấn 4 để xem chế độ "thời gian", trong đó bạn có thể đo khoảng cách giữa hai sự kiện.
  • Nhấn ? để tìm hiểu về mọi chế độ điều khiển.

Thông tin hồ sơ

Hồ sơ mẫu:

Hồ sơ mẫu

Hình 1. Hồ sơ mẫu.

Có một số hàng đặc biệt:

  • action counters: Hiển thị số lượng hành động đồng thời đang diễn ra. Hãy nhấp vào đó để xem giá trị thực tế. Sẽ tăng lên giá trị của --jobs trong các bản dựng sạch.
  • cpu counters: Đối với mỗi giây của bản dựng, hiển thị lượng CPU mà Bazel sử dụng (giá trị 1 bằng 1 lõi sẽ bận 100%).
  • Critical Path: Hiển thị một khối cho mỗi hành động trên đường dẫn quan trọng.
  • grpc-command-1: Luồng chính của Bazel. Hữu ích khi muốn nắm bắt thông tin tổng quan về những gì Bazel đang làm, chẳng hạn như "Launch Bazel", "measuringTargetPatterns" và "runAnalysisPhase".
  • Service Thread: Hiển thị các lần tạm dừng thu gom rác (GC) nhỏ và chính.

Các hàng khác đại diện cho các luồng Bazel và hiển thị tất cả sự kiện trên chuỗi đó.

Các vấn đề thường gặp về hiệu suất

Khi phân tích hồ sơ hiệu suất, hãy tìm kiếm:

  • Chậm hơn giai đoạn phân tích dự kiến (runAnalysisPhase), đặc biệt là trên các bản dựng gia tăng. Đây có thể là dấu hiệu cho thấy bạn đã triển khai quy tắc kém hiệu quả, chẳng hạn như quy tắc làm phẳng phần phân tách. Quá trình tải gói có thể bị chậm do có quá nhiều mục tiêu, macro phức tạp hoặc khối cầu đệ quy.
  • Từng hành động chậm, đặc biệt là những hành động trên lộ trình quan trọng. Bạn có thể chia các thao tác lớn thành nhiều thao tác nhỏ hơn hoặc giảm tập hợp các phần phụ thuộc (có tính chất bắc cầu) để tăng tốc độ của các thao tác đó. Ngoài ra, hãy kiểm tra để tìm giá trị cao bất thường không phải PROCESS_TIME (chẳng hạn như REMOTE_SETUP hoặc FETCH).
  • Điểm tắc nghẽn, tức là một số lượng nhỏ các luồng bận trong khi tất cả những luồng khác đang chạy không hoạt động / chờ kết quả (xem khoảng 15 giây – 30 giây trong ảnh chụp màn hình bên trên). Để tối ưu hoá quá trình này, rất có thể bạn sẽ phải chạm vào các hoạt động triển khai quy tắc hoặc chính Bazel để tăng cường tính song song. Điều này cũng có thể xảy ra khi có một lượng GC bất thường.

Định dạng tệp cấu hình

Đối tượng cấp cao nhất chứa siêu dữ liệu (otherData) và dữ liệu theo dõi thực tế (traceEvents). Siêu dữ liệu chứa thông tin bổ sung, ví dụ như mã nhận dạng lệnh gọi và ngày thực hiện lệnh gọi Bazel.

Ví dụ:

{
  "otherData": {
    "build_id": "101bff9a-7243-4c1a-8503-9dc6ae4c3b05",
    "date": "Tue Jun 16 08:30:21 CEST 2020",
    "profile_finish_ts": "1677666095162000",
    "output_base": "/usr/local/google/_bazel_johndoe/573d4be77eaa72b91a3dfaa497bf8cd0"
  },
  "traceEvents": [
    {"name":"thread_name","ph":"M","pid":1,"tid":0,"args":{"name":"Critical Path"}},
    {"cat":"build phase marker","name":"Launch Bazel","ph":"X","ts":-1824000,"dur":1824000,"pid":1,"tid":60},
    ...
    {"cat":"general information","name":"NoSpawnCacheModule.beforeCommand","ph":"X","ts":116461,"dur":419,"pid":1,"tid":60},
    ...
    {"cat":"package creation","name":"src","ph":"X","ts":279844,"dur":15479,"pid":1,"tid":838},
    ...
    {"name":"thread_name","ph":"M","pid":1,"tid":11,"args":{"name":"Service Thread"}},
    {"cat":"gc notification","name":"minor GC","ph":"X","ts":334626,"dur":13000,"pid":1,"tid":11},

    ...
    {"cat":"action processing","name":"Compiling third_party/grpc/src/core/lib/transport/status_conversion.cc","ph":"X","ts":12630845,"dur":136644,"pid":1,"tid":1546}
 ]
}

Dấu thời gian (ts) và thời lượng (dur) trong các sự kiện theo dõi được cung cấp tính bằng micrô giây. Danh mục (cat) là một trong các giá trị enum của ProfilerTask. Xin lưu ý rằng một số sự kiện được hợp nhất với nhau nếu chúng rất ngắn và gần nhau; hãy truyền --noslim_json_profile nếu bạn muốn ngăn sự kiện hợp nhất.

Hãy xem thêm Thông số kỹ thuật về định dạng sự kiện theo dõi của Chrome.

phân tích hồ sơ

Phương thức phân tích tài nguyên này bao gồm 2 bước, trước tiên, bạn phải thực thi bản dựng/kiểm thử bằng cờ --profile, ví dụ:

$ bazel build --profile=/tmp/prof //path/to:target

Tệp được tạo (trong trường hợp này là /tmp/prof) là một tệp nhị phân, có thể được xử lý hậu kỳ và phân tích bằng lệnh analyze-profile:

$ bazel analyze-profile /tmp/prof

Theo mặc định, thao tác này sẽ in thông tin phân tích tóm tắt cho tệp dữ liệu hồ sơ đã chỉ định. Dữ liệu này bao gồm số liệu thống kê tích luỹ cho các loại tác vụ khác nhau trong từng giai đoạn xây dựng và bản phân tích đường dẫn quan trọng.

Phần đầu tiên của kết quả mặc định là thông tin tổng quan về thời gian dành cho nhiều giai đoạn tạo bản dựng:

INFO: Profile created on Tue Jun 16 08:59:40 CEST 2020, build ID: 0589419c-738b-4676-a374-18f7bbc7ac23, output base: /home/johndoe/.cache/bazel/_bazel_johndoe/d8eb7a85967b22409442664d380222c0

=== PHASE SUMMARY INFORMATION ===

Total launch phase time         1.070 s   12.95%
Total init phase time           0.299 s    3.62%
Total loading phase time        0.878 s   10.64%
Total analysis phase time       1.319 s   15.98%
Total preparation phase time    0.047 s    0.57%
Total execution phase time      4.629 s   56.05%
Total finish phase time         0.014 s    0.18%
------------------------------------------------
Total run time                  8.260 s  100.00%

Critical path (4.245 s):
       Time Percentage   Description
    8.85 ms    0.21%   _Ccompiler_Udeps for @local_config_cc// compiler_deps
    3.839 s   90.44%   action 'Compiling external/com_google_protobuf/src/google/protobuf/compiler/php/php_generator.cc [for host]'
     270 ms    6.36%   action 'Linking external/com_google_protobuf/protoc [for host]'
    0.25 ms    0.01%   runfiles for @com_google_protobuf// protoc
     126 ms    2.97%   action 'ProtoCompile external/com_google_protobuf/python/google/protobuf/compiler/plugin_pb2.py'
    0.96 ms    0.02%   runfiles for //tools/aquery_differ aquery_differ

Phân tích bộ nhớ

Bazel đi kèm với một trình phân tích bộ nhớ tích hợp có thể giúp bạn kiểm tra mức sử dụng bộ nhớ của quy tắc. Nếu có sự cố, bạn có thể kết xuất vùng nhớ khối xếp để tìm chính xác dòng mã gây ra sự cố.

Bật tính năng theo dõi bộ nhớ

Bạn phải truyền hai cờ khởi động này đến mọi lệnh gọi Bazel:

  STARTUP_FLAGS=\
  --host_jvm_args=-javaagent:$(BAZEL)/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
  --host_jvm_args=-DRULE_MEMORY_TRACKER=1

Thao tác này sẽ khởi động máy chủ ở chế độ theo dõi bộ nhớ. Nếu bạn quên các thông tin này cho dù chỉ với một lệnh gọi Bazel, máy chủ sẽ khởi động lại và bạn sẽ phải bắt đầu lại.

Sử dụng Trình theo dõi bộ nhớ

Ví dụ: hãy xem foo mục tiêu và xem chức năng của nó. Để chỉ chạy bản phân tích và không chạy giai đoạn thực thi bản dựng, hãy thêm cờ --nobuild.

$ bazel $(STARTUP_FLAGS) build --nobuild //foo:foo

Tiếp theo, hãy xem mức tiêu thụ bộ nhớ của toàn bộ thực thể Bazel:

$ bazel $(STARTUP_FLAGS) info used-heap-size-after-gc
> 2594MB

Hãy chia nhỏ quy tắc theo lớp quy tắc bằng cách sử dụng bazel dump --rules:

$ bazel $(STARTUP_FLAGS) dump --rules
>

RULE                                 COUNT     ACTIONS          BYTES         EACH
genrule                             33,762      33,801    291,538,824        8,635
config_setting                      25,374           0     24,897,336          981
filegroup                           25,369      25,369     97,496,272        3,843
cc_library                           5,372      73,235    182,214,456       33,919
proto_library                        4,140     110,409    186,776,864       45,115
android_library                      2,621      36,921    218,504,848       83,366
java_library                         2,371      12,459     38,841,000       16,381
_gen_source                            719       2,157      9,195,312       12,789
_check_proto_library_deps              719         668      1,835,288        2,552
... (more output)

Hãy xem vị trí bộ nhớ sẽ chuyển đến bằng cách tạo một tệp pprof sử dụng bazel dump --skylark_memory:

$ bazel $(STARTUP_FLAGS) dump --skylark_memory=$HOME/prof.gz
> Dumping Starlark heap to: /usr/local/google/home/$USER/prof.gz

Dùng công cụ pprof để điều tra vùng nhớ khối xếp. Bạn nên bắt đầu bằng cách sử dụng pprof -flame $HOME/prof.gz để tạo biểu đồ ngọn lửa.

Tải pprof qua https://github.com/google/pprof.

Nhận kết xuất văn bản của các trang web cuộc gọi phổ biến nhất được chú thích bằng các dòng:

$ pprof -text -lines $HOME/prof.gz
>
      flat  flat%   sum%        cum   cum%
  146.11MB 19.64% 19.64%   146.11MB 19.64%  android_library <native>:-1
  113.02MB 15.19% 34.83%   113.02MB 15.19%  genrule <native>:-1
   74.11MB  9.96% 44.80%    74.11MB  9.96%  glob <native>:-1
   55.98MB  7.53% 52.32%    55.98MB  7.53%  filegroup <native>:-1
   53.44MB  7.18% 59.51%    53.44MB  7.18%  sh_test <native>:-1
   26.55MB  3.57% 63.07%    26.55MB  3.57%  _generate_foo_files /foo/tc/tc.bzl:491
   26.01MB  3.50% 66.57%    26.01MB  3.50%  _build_foo_impl /foo/build_test.bzl:78
   22.01MB  2.96% 69.53%    22.01MB  2.96%  _build_foo_impl /foo/build_test.bzl:73
   ... (more output)