pVisor 与 OpenSandbox：启动、磁盘与内存实测¶
固定版本部署对照摘要 汇总相同启动与内存批次，没有重新采样。
历史批次按各自固定的源码、制品与计时口径解释；当前活动实验和准备状态见 benchmark 注册表。
Motivation¶
pVisor 的原生 guest 后端缩短了本地沙箱等待，压缩镜像池降低了镜像库存，较小的服务固定开销有利于少量实例的独立部署。显式物理内存池还可以降低跨实例相同工作集的占用。每实例独立 VM 仍有内核与运行时成本，不能将服务总量的优势解释为每个 VM 都比容器省内存。
稳态 SDK 创建从 149.7 ms 降至 100.7 ms，创建到首条正确命令完成从 358.8 ms 降至 120.9 ms；四镜像库存从 363.16 MiB 降至 121.61 MiB。内存实验的服务加单实例计费为默认 pVisor 92.83 MiB、独立 OpenSandbox/Docker 278.29 MiB；四实例各持相同 64 MiB 数据时，显式物理池为 422.93 MiB，OpenSandbox/Docker 为 742.94 MiB。
另一个低内存十请求突发对照中，pVisor 整批创建约 286 ms、全部首命令完成约 307 ms，分别缩短 37% 和 54%；包含额外校验的完整流程内存峰值则高约 17%。该批次独立统计，不与上述单请求和四实例结果合并。
实验设计¶
测量 SDK 创建及首条正确命令完成的等待、镜像库存的分配块、完整产品组的 cgroup 内存计费，分别作为启动、磁盘和内存成本。这些指标反映本地服务的等待时间和资源预算。数值越低，短任务等待越短、所需资源越少。
单请求启动、镜像库存和四实例内存是三个独立批次，全部在 Linux x86_64/KVM 宿主进行；不合并样本，不计算综合分数。单请求启动与四实例内存使用同一冻结 pVisor performance/musl 制品及同源 Ubuntu 24.04，目标为官方 OpenSandbox server/SDK/execd 1.1.0。内存宿主为 Ryzen 7 9700X、内核 7.2.11-200.fc44.x86_64。双方每沙箱请求 1 CPU/512 MiB；pVisor 的限额覆盖 supervisor/VMM，Docker 的覆盖容器，不能解释为相同隔离或相同 guest 可用 RAM。另一个十请求突发批次使用不同制品与 128 MiB 限额，设计和结果在其小节单列。
启动对照使用既有 rootful Docker/runc 服务，镜像和 Docker 已准备，文件缓存保留，不计镜像拉取或 API 进程启动。API 重启后的首个请求和稳态请求各 20 个固定种子随机配对；每次创建新实例。80 个正式实例及两个稳态准备请求均校验命令输出、私有文件和 HTTP 404 删除确认，不剔除有效慢样本。区间为 10,000 次配对 bootstrap。此处 pVisor 使用默认未开启内存池的配置。
镜像库存另测 Alpine、Ubuntu 和两个 Python slim 的固定 linux/amd64 digest，每个库存三个全新导入。Docker 29/containerd overlayfs 和 pVisor 完整镜像内容及元数据均计入，扣除 Docker 空库存固定占用；分配块按 st_blocks × 512 统计，硬链接只计一次，实验目录关闭 Btrfs 透明压缩。源下载、工具、可执行文件及运行写层不计入，因此这不是整个 OpenSandbox 服务的磁盘总量。
内存对照使用独立 rootless Docker 29/containerd overlayfs 服务及 pasta/pesto 转发，API、dockerd、containerd、shim、转发辅助进程和容器均在同一个产品 slice 内；pVisor 组包含 API、supervisor、VMM 及可选池。各组四核配额、CPU 0–3、4 GiB 上限、零 swap，SDK 协调器和观察者在组外。完整预检独立保存，正式五轮按预先生成的随机顺序交替三种配置，每组新服务与四个新实例。
空服务与单实例各观察 3 秒，四实例空闲观察 5 秒。同一静态程序随后在每个实例保留 64 MiB 相同确定性数据，阻塞等待控制输入，观察 30 秒；完整读回后，每实例改写为独有数据，再观察 10 秒并逐字校验全部内容。私有文件、资源归属、OOM/swap、原生删除均校验。每 500 ms 采集，阶段读数取最后两秒的中位数，再汇总五个新组的中位数和范围；差异区间按轮配对 bootstrap 10,000 次。
内存主指标是完整产品组计费，包含计入该组的 anon/file/kernel；配置的 512 MiB 和 4 GiB 不是实际占用。预备镜像缓存可能计费在组外，Docker 每组使用私有存储副本，页缓存归属与复用也不同，因此组内计费不是整机新增物理内存。部分 rootless 辅助进程禁止读取 PSS，完整 Docker PSS 标为不可用，没有省略进程后作 PSS 对比。宿主后台任务保留且记录，KSM 为关闭状态；不改变全局 KSM、sysctl 或缓存策略。
实验数据和分析¶
创建与首条命令¶
单位 ms，P50；每个场景每臂 N=20，降低比例附配对 95% CI。
| 场景与指标 | OpenSandbox Docker/runc | pVisor 默认 | 延迟降低，95% CI |
|---|---|---|---|
| API 重启后首次：SDK 创建完成 | 388.6 | 101.1 | 74.0% [73.4%, 75.4%] |
| API 重启后首次：创建→首条正确命令完成 | 598.1 | 121.0 | 79.8% [78.8%, 80.6%] |
| 稳态新实例：SDK 创建完成 | 149.7 | 100.7 | 32.8% [30.5%, 36.7%] |
| 稳态新实例：创建→首条正确命令完成 | 358.8 | 120.9 | 66.3% [65.7%, 67.3%] |
每点为一个有效样本，细线连接同一随机轮次的两臂；箱体为四分位范围，须为 1.5 IQR 内的样本，所有点均保留。四个面板使用相同的零起点纵轴。所测场景中，pVisor 的全部创建样本均低于对应 Docker 样本，差异不由少数慢请求产生；20 对样本仍不足以给出生产 P99。
创建后的命令路径也是等待减少的来源。按每次样本的“首条命令完成 − 创建完成”单独计算，稳态追加等待的中位数为 pVisor 19.7 ms、Docker 208.9 ms，降低 90.6% [90.1%, 91.0%]。该值来自配对样本中的实际区间，不能以两项 P50 相减代替。首次与稳态的 pVisor 创建 P50 接近，约为 101 ms；这只说明已有镜像和缓存下的两种 API 请求场景。
在频繁创建、执行短命令的本地 Agent 流程中，原生 guest 路径缩短了可观察等待。首次请求是 API 重启后的首个请求，不能称为冷磁盘或首次下载。首条命令的优势包含命令协议和流结束行为，不能外推为编译、推理等长任务的同倍加速，也不覆盖其他 OpenSandbox 后端。
低内存十请求突发¶
2026-10-24 的独立对照中，pVisor 将十请求整批创建等待缩短约 37%，全部首命令完成缩短约 54%，400 个正式请求全部成功。完整流程内存峰值更高，不能据此宣称整体更省内存。
宿主为 Linux x86_64/KVM，内核 7.2.11-300.fc45.x86_64。pVisor 使用已接入 daemon FD 预扩容的冻结 performance 制品、默认 native guest 引擎，未开启物理内存池；官方 OpenSandbox server 1.1.0 配独立 rootless Docker 29.7.2、cgroup v2/overlayfs、私有 bridge 与 pasta/pesto，未请求网络策略或 egress sidecar。双方均用未修改的官方 Python SDK 1.1.0 和服务代理，模板来自同 digest Ubuntu，每实例请求 1 CPU/128 MiB，入口为 /bin/sleep infinity。关键文件 /bin/sh、/usr/bin/sleep、/etc/os-release 的内容摘要一致；模板整体字节与 VM/容器隔离契约不等价，VM 子限额包含 supervisor/VMM，容器子限额只覆盖容器。
每条件独立产品组限 4 CPU、memory.high=1.5 GiB、memory.max=2 GiB、swap=0，包含 SDK、观察者、API 及全部 VM 或 rootless Docker 进程树，服务和客户端绑定 CPU 0–3；实际子 cgroup 归属与限额逐一检查。一次只运行一个产品组，使用专属 Docker socket 和数据目录。镜像、服务与 SDK transport 预先准备，保留宿主页缓存，因此时钟不含服务启动、镜像导入或拉取。双方分别完成 1/2/10 请求预检，再做 3 对预热、20 对固定种子随机交替的正式批次；每条件新启服务进程、创建十个新实例。
同一异步 barrier 放行十个 SDK create，分别计至最后一个 create 返回和最后一条首命令完成；实际发起跨度中位数为 pVisor 2.89 ms、官方 3.53 ms。首命令检查私有文件不存在，再写入并读回实例独有 token，要求零退出且输出精确相等。两个主时钟结束后，才额外校验文件读取、关键文件摘要和资源配置；所有实例保持到共同完成点后删除。下表为每臂 20 个正式突发批次的中位数；差值为 pVisor − 官方，95% CI 按 20 对批次配对 bootstrap 10,000 次，不将 400 个请求当作独立样本。
| 指标 | 单位 | OpenSandbox＋rootless Docker | pVisor native VM | 差值，95% CI | 变化 |
|---|---|---|---|---|---|
| 十个全部创建完成 | ms | 453.70 | 286.00 | -167.70 [-176.29, -164.62] | -36.96% |
| 十个全部首命令完成，自同一放行点计时 | ms | 668.05 | 306.92 | -361.12 [-365.85, -355.15] | -54.06% |
| 突发窗口内存采样峰值，补充诊断 | MiB | 672.96 | 649.22 | -23.74 [-27.06, -19.89] | -3.53% |
| 完整流程内核内存峰值，含额外校验 | MiB | 693.85 | 810.22 | +116.37 [+114.18, +118.70] | +16.77% |
官方 19/20 批（95%）创建在 440.49–466.66 ms，另 1/20 批（5%）为 889.34 ms；该慢批全部首命令完成为 1098.75 ms，其余为 650.74–682.29 ms。慢批没有 OOM 或内存越界，原因未归因，样本完整保留。pVisor 创建范围为 272.24–294.82 ms，全部首命令完成为 298.15–320.74 ms。没有剔除、重试或混入预检；20 对批次不足以建立 P99 或稳定的第二分布模式。差异属于完整产品路径，不能归为 FD 预扩容的单独收益。
突发窗口峰值来自放行到全部首命令完成之间、目标间隔 20 ms 的 memory.current 采样，可能漏过短峰值。完整流程采用内核 memory.peak，包含服务准备及主时钟之后的额外摘要校验；pVisor 在此口径高约 16.8%，不能用窗口内约 24 MiB 的小差异推断容量优势。共享镜像与固件缓存可能计费在组外，组内峰值也不等于整机新增独占物理内存。
包括预热在内，完整组最高峰值为 812.68 MiB，宿主可用内存最低 16.60 GiB；high/max/oom/oom_kill 和 swap 均为零，未触发宿主低于 4 GiB 或组用量超过 1.75 GiB 的停止阈值。400 个正式、60 个预热和 26 个预检实例均通过正确性和删除确认（HTTP 404、空 inventory、实例 cgroup 消失）；含镜像准备的 53 个产品组全部回收。这支持所测轻量 shell 负载的突发等待比较，不建立持续吞吐、最大并发、真实 Agent 工作集或完整协议兼容结论。
本地证据为 benchmark/startup/.data/opensandbox-pvisor-burst-ab-20261024/，不随站点发布；summary.json SHA-256 为 54dd0f400c89f504f56aef7ea910ccf325dd4db272a497992b6c37381c114ccb，daemon 为 3a6cc2d6932c7411128f9ce64b54673ce4650e6bef8ee2a4750eeb69dae6b944。官方源码固定在 b1a29cf93a823a95913f7943010febb3f29de05c，按原始 server/uv.lock 安装；源码、输入、harness、逐批时钟、内存轨迹、慢批日志及清理记录均保留在该目录。目录归档与历史路径说明见启动实验手册。
镜像池磁盘占用¶
单位 MiB，三个同输入库存的中位数；比例相对所测 Docker 镜像存储。
| 库存 | Docker | pVisor 压缩池 | 磁盘节省 |
|---|---|---|---|
| alpine-3.20 | 12.53 | 4.62 | 63.1% |
| ubuntu-24.04 | 110.18 | 39.48 | 64.2% |
| python-3.12-slim-bookworm | 176.68 | 63.20 | 64.2% |
| python-3.13-slim-bookworm | 172.34 | 61.92 | 64.1% |
| combined | 363.16 | 121.61 | 66.5% |
左图比较四个独立的单镜像库存；右图比较真实四镜像集合，不能把左图直接相加作为 Docker 的组合占用。完整压缩池路径在四种镜像上都节省空间；共享一个池还使 pVisor 的四镜像库存比四个独立 store 少 47.60 MiB。相对 Docker 的真实组合库存少 241.55 MiB。后两项差值是所测中位库存的描述，不能推导为每增加一种镜像都节省同样的字节。
Docker 列已经包含正常的层共享。四个独立 pVisor store 合计 169.21 MiB，同一共享池为 121.61 MiB，再减少 28.1%。池中保留压缩内容与索引，创建无需再展开整份 rootfs；这项库存结果不回答 mmap 性能、冷读 CPU、导入峰值或删除 GC，也不代表所有镜像或所有 Docker 存储驱动都节省相同比例。
服务与实例内存¶
下表为完整产品组 cgroup 计费，单位 MiB；每格五个新组的中位数，方括号为最小–最大值；写后池模式另列四组与一组的读数。显式物理池不是默认配置，数据共享与镜像磁盘压缩是不同机制。
| 阶段 | OpenSandbox＋独立 Docker | pVisor 默认 | pVisor 显式物理池 |
|---|---|---|---|
| 空服务，无实例 | 177.90 [176.04–178.50] | 4.34 [3.91–4.50] | 4.21 [3.97–4.40] |
| 服务＋1 个空闲实例 | 278.29 [277.11–279.32] | 92.83 [92.41–93.09] | 83.39 [82.89–83.70] |
| 服务＋4 个空闲实例 | 399.65 [399.27–402.51] | 357.98 [357.61–358.36] | 278.02 [275.18–280.08] |
| 四实例，各持相同 64 MiB，30 秒 | 742.94 [742.32–744.55] | 631.51 [631.46–632.25] | 422.93 [419.99–426.77] |
| 四实例，各持独有 64 MiB，10 秒 | 748.71 [745.64–749.91] | 634.17 [633.76–634.80] | 4/5 组：631.08 [628.50–633.34]；1/5 组：646.11 |
柱为五个新组的中位数，误差线为最小–最大值，不是置信区间；所有配置含后台服务。写成独有内容后，物理池的一组读数较高，表中按事后 640 MiB 阈值分为四组与一组；全部五轮仍参与配对统计，不能凭小样本确认稳定多峰。相同数据是可共享的合成工作集，独有数据暴露私有写入后的退化，不能作为真实 Agent 工作集的平均收益。
每种颜色保留五组独立轨迹，直接连接约 500 ms 的原始观测，没有平滑或挑选代表轮次；浅黄色区域是汇总使用的最后两秒。左右面板分别从“相同数据已就绪”和“独有改写已完成”重新计时，分配、写入和校验间隔未画入，不能把两图拼成连续生命周期或用来估计写入峰值。物理池在共享窗口初段继续降低计费；改写为独有内容后占用回升，随后释放部分暂态成本。有限观察窗不建立长期收敛或稳定性保证。
以下差值为左侧配置减右侧，负数表示计费较少；降低比例为正表示节省。区间仅描述这五轮的变动，不代表生产分布。
| 同阶段对照 | 计费差值 MiB，95% CI | 降低比例，95% CI |
|---|---|---|
| 单实例部署：默认 − OpenSandbox | -185.46 [-186.24, -184.13] | 66.6% [66.4%, 66.8%] |
| 四空闲实例：默认 − OpenSandbox | -41.67 [-44.36, -41.30] | 10.4% [10.3%, 11.0%] |
| 相同工作集：默认 − OpenSandbox | -111.43 [-113.04, -110.06] | 15.0% [14.8%, 15.2%] |
| 相同工作集：物理池 − OpenSandbox | -320.01 [-322.95, -317.78] | 43.1% [42.7%, 43.5%] |
| 相同工作集：物理池 − 默认 | -208.58 [-211.48, -204.74] | 33.0% [32.4%, 33.5%] |
| 独有工作集：默认 − OpenSandbox | -114.54 [-116.15, -110.84] | 15.3% [14.9%, 15.5%] |
| 独有工作集：物理池 − OpenSandbox | -116.51 [-120.63, -103.80] | 15.6% [13.8%, 16.1%] |
默认四实例空闲计费的差值区间未包含零；差异仅适用于该独立服务配置。默认模式保留 VM 的完整生命周期和独立 guest kernel；物理池通过只读共享与写时复制降低相同驻留页的成本，写成独有内容后占用回升。读回、写入和再次读回全部通过，节省没有依赖丢弃应用数据。
下表是同一个新组内 (阶段总量 − 空服务基线) / 实例数 后再取五组中位数，单位 MiB/实例。
| 计量 | OpenSandbox＋独立 Docker | pVisor 默认 | pVisor 显式物理池 |
|---|---|---|---|
| 1 实例时，每实例平均部署增量 | 100.39 | 88.49 | 79.02 |
| 4 实例时，每实例平均部署增量 | 55.54 | 88.46 | 68.41 |
点为全部五组，柱为中位数，误差线为最小–最大值。左图只画实际测得的 0、1、4 实例，不连接成容量曲线；右图扣除同组空服务后再按实例数摊销。pVisor 默认服务的固定计费较低，单实例部署的总量优势明显；四实例时，Docker 的每实例摊销增量为 55.54 MiB，低于默认 VM 的 88.46 MiB。共享物理池使 VM 的该值降至 68.41 MiB，仍不能从四实例外推生产容量或盈亏平衡实例数。
这是摊销后的部署增量，包含首次使用初始化和缓存，不是单进程 RSS，也不是第 N+1 个实例的边际成本。VM 的增量可能高于容器；较小的后台服务和跨实例共享可以降低完整部署总量。独立 Docker daemon 的固定开销已经计入，不能将该比例外推到多人共用既有 Docker daemon 的部署。
相同工作集的 30 秒观察窗还记录了扫描成本及四实例完整读回的等待。下表为五组中位数和范围，CPU 单位为秒、读回单位为 ms。
| 配置 | 30 秒窗整组 CPU 秒 | 四实例完整读回 ms |
|---|---|---|
| OpenSandbox＋独立 Docker | 0.059 [0.054–0.061] | 899.3 [897.4–901.8] |
| pVisor 默认 | 0.162 [0.156–0.174] | 108.6 [106.1–117.7] |
| pVisor 显式物理池 | 2.861 [2.577–3.223] | 443.9 [419.4–445.8] |
两轴均从零开始，全部五组散点和最小–最大值保留。显式池在相同工作集上进一步降低内存，但 30 秒窗口的整组 CPU 从默认 0.162 秒升至 2.861 秒，全量读回从 108.6 ms 升至 443.9 ms。选择时应同时考虑可共享内容、驻留时间与读写频率；当前数据支持这一固定工作集的取舍，不给出真实 Agent 的净收益预测。
读回包含全量内容检查、SDK 与流完成，不是纯缺页或解压时间。物理池以扫描、哈希、映射管理及 COW 成本换取共享，当前只测固定窗口，不代表收敛、长期稳定性或容量上限。该池不压缩独有页；默认配置和开启池后的启动时间不能拼成同一个配置的综合成绩。
来源与适用范围¶
正式内存批次共 15 组、60 个新实例，全部内容、私有文件、资源和删除校验通过；没有丢弃组或拼接预检。准备及驱动预检失败保留在各自目录，没有计入正式比较。启动批次的长状态路径配置失败也单独保留；有效启动批次的 82 个实例全部删除。
启动、磁盘、内存的本地证据分别为 benchmark/.data/opensandbox-native-docker-20261024T020535Z/、benchmark/.data/image-storage-6mdz6ljh/、benchmark/.data/opensandbox-memory-formal-20261024/。这些目录不随站点发布。对应 summary SHA-256 依次为 8fc9fd74d6c4450dd9be07af58fbdc80156dbc6cacf4691c97daa416951b5e12、ed741f8c85bf14284e69c4f4a374baaea6a09d61461ce8ba78a0863e39be919b、13d437b59e56bc4534d48b24999ab44c1dd5ef562ea005a4f0a66664a9ebe067。
启动和内存使用的 daemon SHA-256 为 74461c7ad588633228d44a8ada5d8335de50ea55ca9c5c543886c6533540f575；磁盘实验使用独立冻结 CLI，SHA-256 为 14ab9917e2d9d9c8fad513b490d43646bce1978e6f25f98ac1f641c34b55b73e。源码、构建收据、输入 digest、资源配置、所有样本和日志留在各批次。复现见 OpenSandbox 实验手册及镜像库存手册。
新增五张图由 benchmark/opensandbox/plot_comparison.py 从上述原始批次生成，没有增加采样或修改原始结果。逐图数据、所有输入与 SVG 的 SHA-256、绘图代码和 Matplotlib 版本保存在本地 benchmark/.data/opensandbox-figures-20261024/，与原内存柱状图的来源收据分开。
结果支持所测本地配置的启动和库存优势，以及服务摊销与可选物理共享的内存收益；不建立完整 OpenSandbox/E2B 协议兼容、敌对用户安全、生产密度或 P99 保证。OpenSandbox 还可配置其他隔离运行时，参见官方安全运行时说明；这些路径未包含在该性能对照中。