# Git Clone 并发极限与调优区间

- 生成时间（UTC）：`2026-09-11T05:37:49Z`
- 种子：`20260911`
- 网卡采样：`enp5s0f1`
- 样本：上一轮 API 抽样中尚未 clone 的 **L + XL**（10–200 MiB GitHub size）
- 分配：按 size 排序后 round-robin，各并发档体积分布接近
- 仓库互斥，随机打乱档位顺序

## 1. 结论

这轮专门回答两件事：**下载能被并发推到多快**，以及 **生产流水线该用几路**。

自动 peak-picker 会报「全面 12」，那是被体积组成和超大仓拖尾放大的点估计，**不能当调优区间**。下面用网卡 RX、去最大仓后的墙钟吞吐、jobs/s 一起看。

### 生产流水线（clone + 内存 tar.gz 落盘）

| 口径 | 结果 |
|---|---|
| 单路基线墙钟吞吐 | 7.6 MiB/s（网卡 RX 2.9 MiB/s） |
| 4 路 | 15.7 MiB/s 墙钟 · RX 8.8 · jobs 约 3.1× |
| 8 路 | 16.0 MiB/s 墙钟 · RX 5.6 · jobs 仍约 3.0× |
| 12 路（样本峰值） | 25.3 MiB/s 墙钟 · RX 9.5 · jobs 4.7× |
| 去掉每档最大仓后 | **4 / 8 / 12 路都在 17–18 MiB/s**，16+ 掉到 12–16 |
| 16–20 路 | 墙钟回落到 19 MiB/s，并行效率 0.18–0.23，单连接变慢 |
| CPU | 全程均值 6–18%，峰值 36%，**不是 CPU 打满** |
| 失败 | 1–20 路全部 0 失败 |

**合理区间：4–8 路。默认 6。** 想压极限、并且按体积分了队列，可以上到 **8–12**。不要用 16+。

### 纯 clone（下载天花板，不打包）

clone-only 四档体积没对齐（4 路还混着 L，8/12/16 几乎全是更大的 XL），所以 **54 MiB/s 不是可比的极限带宽**。那是 6 个大仓并行时的工作树字节/墙钟。网卡真实 RX：

- 4 路：11.5 MiB/s
- 8 路：11.2 MiB/s
- 12 路：20.6 MiB/s（样本最大、仓也最大）
- 16 路：15.5 MiB/s

单仓 clone 吞吐中位在大仓上大约 **10–13 MiB/s**。本机到 GitHub 这条路径的 **git 协议聚合上限大约 20 MiB/s 量级（网卡）**，对应更大工作树吞吐。打包一开，gzip 和 git 解包抢 CPU/磁盘，流水线墙钟大约只能吃到这个上限的一半。

## 2. 方法

上一轮 1/4/8 不能当极限：8 路被 1.97 GiB 的 XXL 拖死，且小仓握手开销会压低平均值。本轮：

1. 只用 L/XL，让测量进入带宽区而不是 RTT 区。
2. 每档固定 8 个仓（clone-only 每档 6 个），体积 round-robin 对齐。
3. 两套轨道：只 clone（下载天花板）vs clone+内存打包落盘（真实流水线）。
4. 记录 CPU%、网卡 RX、并行效率 = Σ任务时间 / (墙钟 × 并发)。

## 3. 各档体积对齐

| 轨道 | 并发 | n | size 中位 KiB | size 均 KiB | L/XL |
|---|---:|---:|---:|---:|---|
| e2e | 6 | 8 | 20262 | 24704 | 8/0 |
| e2e | 12 | 8 | 21042 | 26296 | 8/0 |
| e2e | 4 | 8 | 20092 | 24406 | 8/0 |
| e2e | 1 | 8 | 19204 | 22419 | 8/0 |
| e2e | 20 | 8 | 21402 | 26869 | 8/0 |
| e2e | 2 | 8 | 19700 | 22945 | 8/0 |
| e2e | 16 | 8 | 21162 | 26727 | 8/0 |
| e2e | 8 | 8 | 20681 | 25574 | 8/0 |
| clone-only | 4 | 6 | 56697 | 72786 | 3/3 |
| clone-only | 8 | 6 | 88078 | 89311 | 0/6 |
| clone-only | 16 | 6 | 113122 | 115135 | 0/6 |
| clone-only | 12 | 6 | 109974 | 105372 | 0/6 |

## 4. 纯 clone（下载极限）

| 并发 | 成功 | 墙钟 | 墙钟吞吐 | 聚合 clone 吞吐 | 单仓吞吐中位 | clone 并行效率 | CPU均/峰值 | 网卡 RX 均 |
|---:|---:|---:|---:|---:|---:|---:|---:|---:|
| 4 | 6/6 | 10.18 s | 29.77 MiB/s | 10.03 MiB/s | 10.01 MiB/s | 0.74 | 10% / 21% | 11.52 MiB/s |
| 8 | 6/6 | 18.77 s | 29.13 MiB/s | 10.66 MiB/s | 9.25 MiB/s | 0.34 | 10% / 16% | 11.20 MiB/s |
| 12 | 6/6 | 18.64 s | 54.01 MiB/s | 13.54 MiB/s | 13.04 MiB/s | 0.33 | 16% / 27% | 20.62 MiB/s |
| 16 | 6/6 | 29.15 s | 31.54 MiB/s | 12.90 MiB/s | 13.14 MiB/s | 0.15 | 11% / 24% | 15.53 MiB/s |

## 5. clone + 内存 tar.gz 落盘（生产流水线）

| 并发 | 成功 | 墙钟 | 墙钟吞吐 | 聚合 clone 吞吐 | 单仓吞吐中位 | e2e 并行效率 | 打包中位 | CPU均/峰值 | 网卡 RX 均 |
|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
| 1 | 8/8 | 1m 7.6s | 7.63 MiB/s | 15.09 MiB/s | 11.28 MiB/s | 1.00 | 2.25 s | 6% / 12% | 2.91 MiB/s |
| 2 | 8/8 | 43.63 s | 11.06 MiB/s | 11.77 MiB/s | 8.92 MiB/s | 0.85 | 2.14 s | 8% / 19% | 4.38 MiB/s |
| 4 | 8/8 | 22.07 s | 15.71 MiB/s | 8.66 MiB/s | 8.39 MiB/s | 0.73 | 2.53 s | 13% / 27% | 8.83 MiB/s |
| 6 | 8/8 | 21.75 s | 14.99 MiB/s | 10.43 MiB/s | 5.63 MiB/s | 0.44 | 1.13 s | 12% / 21% | 5.96 MiB/s |
| 8 | 8/8 | 22.50 s | 15.96 MiB/s | 11.27 MiB/s | 5.73 MiB/s | 0.35 | 1.70 s | 13% / 36% | 5.63 MiB/s |
| 12 | 8/8 | 14.53 s | 25.30 MiB/s | 9.75 MiB/s | 7.65 MiB/s | 0.36 | 2.45 s | 18% / 35% | 9.52 MiB/s |
| 16 | 8/8 | 16.33 s | 19.45 MiB/s | 8.73 MiB/s | 8.64 MiB/s | 0.23 | 1.83 s | 15% / 27% | 9.07 MiB/s |
| 20 | 8/8 | 17.26 s | 19.00 MiB/s | 9.49 MiB/s | 5.47 MiB/s | 0.18 | 1.67 s | 15% / 30% | 8.49 MiB/s |

墙钟吞吐 = Σ clone_bytes / 阶段墙钟，这才是「开 N 路时机器实际搬数据的速度」。
单仓吞吐中位下降 = 连接开始互相抢带宽或 CPU。并行效率 1.0 表示 N 路没有互相等待。

## 6. 调优区间怎么落地

e2e 各档 GitHub `size` 中位都在 19–21 MiB，对齐是成功的；但 shallow 工作树仍可能从 0.4 MiB 到 199 MiB。所以 **墙钟峰值不能单独用**：8 路被一个 189 MiB 仓的 13 s 打包拖满整个阶段。去最大仓之后，4/8/12 几乎一样快。

| 队列 | 建议并发 | 原因 |
|---|---:|---|
| XS / S（<1 MiB） | 12–16 | 几乎全是握手，带宽用不满，高并发提高 jobs/s |
| M / L（1–50 MiB） | **6–8** | 本轮 L 档的稳定区 |
| XL（50–200 MiB） | 4–6 | 单仓已能跑到 10+ MiB/s，再堆连接收益小 |
| XXL / ≥1 GiB | 1–2 | 打包和 clone 都会变成长尾，必须隔离 |

推荐生产默认：

1. **全局 worker = 6**（clone + 内存 tar.gz 同一池）
2. 硬顶 **12**，超过本测 16/20 只降效率不涨网卡
3. XXL 单独串行或 2 路，禁止和中小仓抢同一线程池
4. 先 API 探活再 clone，14% 的 404 不必占并发槽
5. 保持 `GIT_LFS_SKIP_SMUDGE=1` 和 shallow `--depth 1`

上一轮「8 路比 4 路慢」是 XXL straggler，不是 8 路本身不行。本轮在 L 档上 4 和 8 的去尾吞吐几乎相同；8 路的价值是消化长尾，不是提高单连接速度。

## 7. 产物

- 报告：`/www/wwwroot/dataset/github_clone/speed_test/reports/concurrency_sweep_report.md`
- JSON：`/www/wwwroot/dataset/github_clone/speed_test/reports/concurrency_summary.json`
- 每仓指标：`/www/wwwroot/dataset/github_clone/speed_test/reports/concurrency_metrics.jsonl`
- 归档（仅 e2e）：`/www/wwwroot/dataset/github_clone/speed_test/concurrency_archives`