部署
English version: deployment.md
rust-bench 的部署模型，源自仓库中的构建与运行产物。按步骤的操作手册见 deploying-site 指南 与 deploying-collector 指南。
需部署的组件
| 组件 | 位置 | 后端 | 来源 |
|---|---|---|---|
| Site（Web 服务器 + 任务队列 tick + 平台 API） | Docker 镜像或裸进程 | Postgres | Dockerfile、site/src/main.rs |
| Collector(s)（基准测试执行器） | 裸金属基准测试机器，collect-job-queue.sh 循环 |
Postgres | collector/collect-job-queue.sh、collector/src/bin/collector.rs |
| 数据库 | Postgres 16 | — | docker-compose.yml（测试实例） |
SQLite 仅支持本地单机运行（bench_runtime_local）；分布式队列必须 Postgres。
Site
Site 二进制为 target/release/site。在端口 2346（PORT）提供 HTTP，webhook 端点为 /perf/webhook（site/src/server.rs:343）。
Docker
Dockerfile 为多阶段构建（前端 → site 二进制 → 最小运行镜像）：
node:18（构建前端） → ubuntu:20.04 base（Rust + cargo-chef） → build → ubuntu:20.04 binary
- 阶段 1 用
npm ci && npm run build构建 TypeScript 前端（site/frontend）。 - 阶段 2 安装构建依赖与 Rust（stable，经 rustup，使用 USTC/TUNA 镜像，适配中国网络）。
- 阶段 3 用
cargo-chef缓存依赖，再构建site与postgres-to-sqlite。 - 最终镜像拷贝
site与postgres-to-sqlite二进制；CMD ./rustc-perf-site。
运行：
docker build -t rust-bench-site .
docker run -p 2346:2346 -e DATABASE_URL=postgres://... -v $(pwd)/site-config.toml:/app/site-config.toml rust-bench-site
测试用 Postgres
docker-compose.yml 提供一次性 Postgres 16：
docker compose up # 启动 pg_test，端口 :5432（user=postgres, pass=testpass, db=postgres）
环境变量
| 环境变量 | 默认 | 用途 | 来源 |
|---|---|---|---|
DATABASE_URL |
results.db |
DB 连接 URL。 | main.rs:24-30 |
PORT |
2346 |
HTTP 端口。 | main.rs:31-34 |
QUEUE_UPDATE_INTERVAL_SECONDS |
30 |
任务队列 tick 间隔。 | main.rs:35-38 |
SELF_PROFILE_STORAGE_S3 |
未设 | 设置则从 S3 取 self-profile；否则本地。 | main.rs:39-49 |
site-config.toml 不存在时还有平台环境变量（见 configuration_CN.md §7）。
启动流程
启动时（site/src/main.rs:16），Site：
- 加载
site-config.toml（或环境变量），校验[keys]（缺省则降级，空值则硬失败）——load.rs:299-349, 478-496。 - 连接 DB，加载索引（制品、commit、指标）。
- 为每个已配置仓库键创建一个
PlatformApi客户端。 - 启动 HTTP 服务器与任务队列 tick 任务（panic 有界：tick panic 会重启）。
- 按仓库为最近 30 天合并 commit 播种
benchmark_request行（seed_master_commits，load.rs:541-613）。
Collector
每个 collector 运行在专用基准测试机器上，通过 collector/collect-job-queue.sh（非 Docker——需直接硬件访问与 perf_event）。
运行循环
collector/collect-job-queue.sh（37 行）需要 DATABASE 与 COLLECTOR_NAME 环境变量，永久循环：
git pull && git reset --hard @{upstream}——更新 rust-bench 自身。rustup update stable，然后cargo +stable build --release -p collector --features s3-sdk。target/release/collector benchmark_job_queue --db $DATABASE --check_git_sha --git_sha $(git rev-parse HEAD) --collector_name $COLLECTOR_NAME。- 非零退出：
sleep 60后重试；成功：立即循环。
注册
首次运行前在 Postgres 注册 collector 名称（见 job-queue_CN.md）：
./target/release/collector add_collector --db "postgres://..." --collector_name "Kunpeng 920B" --is_active
collector_name 必须匹配 site-config.toml 中 [collectors].tags 的某项。
机器准备
基准测试保真度要求安静的机器。必需设置（见 benchlib/src/measure/perf_counter/linux.rs:84-100 与 README 清单）：
| 项 | 设置 | 原因 |
|---|---|---|
perf_event_paranoid |
sudo bash -c 'echo -1 > /proc/sys/kernel/perf_event_paranoid' |
允许用户态 perf_event_open 获取硬件计数。失败时库会给出此提示。 |
| CPU 频率 | 固定频率（禁用动态调频） | 降低墙钟噪声。 |
| ASLR | sudo bash -c 'echo 0 > /proc/sys/kernel/randomize_va_space' |
可选；collector 还经 setarch -R 按进程禁用 ASLR（runtime/mod.rs:215）。 |
| Turbo / SMT | 禁用 | 降低运行间方差。 |
Collector tag 示例（多架构）
仓库 site-config.toml 自带两个 collector tag，代表两种架构：
[collectors]
tags = ["Kunpeng 920B", "AMD EPYC 9654"]
Kunpeng 920B——ARM（aarch64）服务器。AMD EPYC 9654——x86_64 服务器。
每台机器各部署一个 collect-job-queue.sh 循环，各设自身 COLLECTOR_NAME。Site 会按 (benchmark_group, collector_tag) 分发任务，两种架构并行基准测试，比较评论含按 tag 链接与跨机（<tag_i> vs <tag_j>）链接（site/src/github/comparison_summary.rs:26-134）。
实际硬件规格（CPU 型号、内存、内核）因运维而异，仓库不编码。请在内部运维手册记录机器细节；框架仅要求上述四项机器准备与匹配的
COLLECTOR_NAME。
运维要点
- collector 停止则队列停滞。 collector tag 静态分配——无工作窃取。若持 in-progress 任务的 collector 停止，整个系统等待该任务重试/完成。见 job-queue_CN.md。
- 状态页。 collector 心跳（
collector_config.last_heartbeat_at）可见于状态页；心跳过旧（>~1 小时）通常表示 collector 宕机。 - self-profile 存储。 以
--features s3-sdk构建 collector，并在 Site 设SELF_PROFILE_STORAGE_S3，将 self-profile 归档存入 S3；否则存本地目录。