Bazel项目CI环境下bazel fetch性能缓慢问题求助

这种情况我在几个中型Bazel项目里都碰到过——既然本地镜像所有依赖后速度没明显提升，说明瓶颈根本不在网络下载，得从Bazel的本地处理流程、CI环境的硬件限制或者依赖配置本身找问题。下面是一步步的排查和优化方案：

第一步：先定位时间到底花在哪了 #

首先得搞清楚bazel fetch的5分钟里，哪些步骤占了大头，别瞎优化。可以用Bazel的日志参数输出详细时间线：

bazel fetch //... --verbose_failures --subcommands --timing

这个命令会输出每个子步骤的耗时，比如：

• 校验SHA256的时间
• 解压归档文件的时间
• 执行repo规则的post-fetch操作（比如strip_prefix、打补丁）
• 写入磁盘的时间

另外，你还可以逐个测试单个依赖的fetch耗时：

bazel fetch @your_dep_name//...

如果某个依赖单独fetch就花了几十秒，那大概率是这个依赖的处理逻辑有问题。

同时，在CI环境里跑个简单的IO测试，确认是不是磁盘拖后腿：

# 测试写入速度
dd if=/dev/zero of=test_io bs=1G count=1 oflag=direct
# 测试解压速度（找个3G左右的tar包试试）
time tar xf large_dep.tar

如果IO速度明显慢于本地机器（比如写入速度只有几十MB/s），那CI的磁盘性能就是核心瓶颈。

第二步：针对性优化方案 #

1. 减少Bazel的本地处理开销 #

既然网络不是问题，那就要减少Bazel在本地对依赖的处理工作：

• 跳过校验（仅限内部可信环境）：如果你的本地镜像完全可信，可以在http_archive里添加skip_checksum = True，省去SHA256校验的CPU和IO开销：

  http_archive(
      name = "some_dep",
      url = "http://local-mirror/some_dep.tar.gz",
      skip_checksum = True,
      # 其他参数...
  )
  

• 用预解压的本地仓库代替归档：把所有依赖提前解压到CI的高速存储里，用local_repository代替http_archive，这样Bazel不用再做解压操作：

  local_repository(
      name = "some_dep",
      path = "/ci-cache/pre-extracted/some_dep",
      build_file = "@//third_party:some_dep.BUILD",
  )
  

• 提前处理依赖的post-fetch操作：如果有些依赖需要strip_prefix、打补丁，你可以在本地镜像时就完成这些操作，把处理好的包放到镜像服务器，这样Bazel fetch后直接就能用，不用再做额外处理。

2. 优化CI环境的IO与缓存 #

CI环境的临时磁盘往往是性能短板，这部分可以这么优化：

• 复用Bazel缓存：配置CI的远程缓存或者本地缓存，把fetch后的依赖缓存起来，下次CI job直接复用。比如在CI脚本里设置：

  bazel fetch //... --remote_cache=grpc://your-cache-server
  # 或者用CI自带的目录缓存，比如GitHub Actions的cache动作
  

  注意：要确保缓存的key包含依赖的版本信息，避免缓存失效。
• 使用高速存储：如果CI支持，把Bazel的输出目录（bazel-out、bazel-cache）挂载到SSD或者本地磁盘，而不是网络存储。比如在GitLab CI里可以配置cache用高速存储，或者指定BAZEL_DIR到本地SSD路径。
• 并行提升fetch效率：调整Bazel的并行任务数，比如根据CI的CPU核心数设置--jobs=16（默认是CPU核心数，你可以适当调高）：

  bazel fetch //... --jobs=16
  

3. 清理依赖的冗余与嵌套 #

有时候依赖本身的结构会拖慢fetch：

• 检查冗余依赖：用bazel query 'deps(//...)' --output=package输出所有依赖，看看有没有重复声明或者不需要的依赖，把它们从WORKSPACE里移除。
• 合并小依赖：如果有很多小的归档文件（比如几十KB到几百MB的），可以把相关的小依赖打包成一个大归档，减少Bazel需要处理的文件数量，降低IO开销。

4. 升级Bazel版本 #

新版本的Bazel在fetch阶段有不少性能优化，比如更快的校验逻辑、更高效的解压算法。试试升级到最新的稳定版，说不定能直接解决问题。

内容的提问来源于stack exchange，提问作者marczych