跳转至

本地 OpenSandbox 接口要等多久、占多少内存?

2026-10-24 固定版本的工程对照证据;本摘要不代表此 PR 的新测量。

Motivation

pVisor 原生 guest 后端适合频繁创建并执行短命令的本地 SDK 流程,较低的服务固定计费也有利于少量实例部署。每实例 VM 仍有内核与运行时成本;显式物理池可减少相同工作集的计费,但会增加扫描 CPU 和读回等待。

稳态创建中位数为 pVisor 100.7 ms、OpenSandbox/Docker 149.7 ms,创建至首条正确命令完成为 120.9 ms、358.8 ms。服务加单实例内存计费为 92.83 MiB、278.29 MiB;四实例摊销增量则为 88.46 MiB、55.54 MiB,不能将较小的服务总量解释为每个 VM 都更省内存。

实验设计

测量 SDK 创建至返回及首条正确命令完成的时间,称为可用等待;测量完整产品组的 cgroup 内存计费,称为部署内存成本。两者反映短任务开始前的等待和本地服务预算。数值越低,等待越短、所需计费预算越少。

对照为同源 Ubuntu 24.04 的 pVisor native guest 与官方 OpenSandbox server/SDK/execd 1.1.0,Linux x86_64/KVM,每实例请求 1 CPU/512 MiB。pVisor 使用冻结 performance/musl 制品,单请求测试关闭物理池;VM 限额覆盖 supervisor/VMM,Docker 限额覆盖容器,隔离及可用 guest RAM 不等价。镜像与服务预准备、宿主页缓存保留,排除拉取和 API 进程启动。

启动使用既有 rootful Docker/runc。API 重启后的首请求与稳态新实例各 20 个固定种子随机配对;80 个正式实例和两个准备实例均检查 stdout、私有文件及 HTTP 404 删除确认。有效慢样本全部保留,区间为 10,000 次配对 bootstrap,N=20 不建立 P99。

内存使用另一个独立批次:默认 pVisor、同制品显式物理池、官方服务加私有 rootless Docker/containerd overlayfs。三种配置随机交替五轮,每组新服务和四实例;产品组含 API、VMM/supervisor/池,或 dockerd/containerd/shim/容器与转发进程。每组四核配额、CPU 0–3、4 GiB、零 swap,SDK 协调器和观察者在组外。空服务、1/4 空闲实例分别观察,再使四实例各持相同 64 MiB 数据 30 秒、完整改写为独有数据 10 秒;全部内容、私有文件、资源归属、OOM/swap 和删除均校验。

每 500 ms 采样,阶段取最后两秒的中位数,再对五个新组取中位数与范围;差异使用按轮配对的 10,000 次 bootstrap。预备缓存可能计费在组外,组内 anon/file/kernel 计费不等于整机新增物理内存;Docker 完整 PSS 不可读,不用部分进程求和代替。后台任务保留并记录。启动与内存批次独立,不能把物理池内存与默认配置启动拼成综合成绩。

实验数据和分析

创建与首条命令

场景与指标 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%]

单位 ms、P50,每场景每臂 N=20;百分比附配对 95% CI。首次指 API 重启后的首请求,镜像和服务已准备,不是首次下载或冷磁盘。

全部创建与首命令配对样本

固定版本的小任务流程中,创建和命令协议共同缩短等待。所有点均保留,不能将创建到首命令的优势外推为编译或推理的同倍加速,也不覆盖其他 OpenSandbox 后端。

部署内存与实例摊销

阶段 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

单位 MiB,完整产品组计费;各配置 N=5,中位数 [最小–最大]。独有工作集的池读数分列 4/5 与 1/5,所有样本均保留,不把五组结果解释为稳定双峰。

默认服务加单实例相对所测独立 OpenSandbox/Docker 降低 66.6% [66.4%, 66.8%];这是服务、初始化和缓存一并计费的部署结果。共享既有 Docker daemon 时不能给每个新容器再摊入完整服务基线。

五个新产品组的各阶段内存与范围

服务基线、实例增量与全部组读数
计量 OpenSandbox+独立 Docker pVisor 默认 pVisor 显式物理池
1 实例时,每实例平均部署增量 100.39 88.49 79.02
4 实例时,每实例平均部署增量 55.54 88.46 68.41

单位 MiB/实例;在同一组内先算 (阶段总量 − 空服务基线) / 实例数,再取五组中位数,不能相减表格中的两个中位数代替。该值含初始化与缓存,是摊销部署增量,不是单进程 RSS 或下一实例边际成本。

完整部署与扣基线后的实例增量

四实例下容器的摊销增量低于默认 VM;仅测 0、1、4 实例,不连接成容量曲线,也不推断最大密度或盈亏平衡规模。

是否启用物理池

相同工作集下,显式池相对默认 pVisor 再减少 208.58 MiB [204.74, 211.48],降低 33.0% [32.4%, 33.5%];改写为独有数据后不再保留同等收益。物理共享与镜像磁盘压缩是不同机制,池也不是默认配置。

配置 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]

每格 N=5 中位数 [最小–最大]。30 秒窗的整组 CPU 为秒,四实例全量读回为 ms,包含 SDK、内容检查及流结束,不是纯缺页时间。

物理共享的 CPU 与读回代价

选择池应看内容是否相同、保留多久、读写多频繁;相同内容的内存收益伴随额外 CPU 与读回等待。这一固定负载不预测真实 Agent 的净收益,长期稳定性及生产容量仍需独立测试。

镜像磁盘与复现

镜像库存属于独立存储实验,见惰性镜像的磁盘数据。它不含 API、运行写层及整个 OpenSandbox 服务目录,不能当作相同 SDK 配置的完整部署磁盘对比。

上述启动和内存是 2026-10-24 的固定版本历史证据,本次为文档迁移,没有重新采样,也不代表当前 main 的性能复测。daemon SHA-256 为 74461c7ad588633228d44a8ada5d8335de50ea55ca9c5c543886c6533540f575;内存宿主为 Ryzen 7 9700X / 内核 7.2.11-200.fc44。

证据 样本与校验 summary SHA-256
SDK 首次/稳态 40 对、80 正式实例;零失败、零剔除 8fc9fd74d6c4450dd9be07af58fbdc80156dbc6cacf4691c97daa416951b5e12
完整内存组 15 组、60 实例;零失败、零剔除 13d437b59e56bc4534d48b24999ab44c1dd5ef562ea005a4f0a66664a9ebe067

原始记录、冻结源码、构建和输入收据留在本地 benchmark/.data/opensandbox-native-docker-20261024T020535Z/ 与 benchmark/.data/opensandbox-memory-formal-20261024/。证据与复测入口 · 突发与内存池诊断。这些结果不证明完整协议兼容、安全等级等价、持续吞吐或生产密度。