解读 gVisor 性能数据从 website/performance 基准 CSV 到 runc/runsc 实测对比【免费下载链接】gvisorApplication Kernel for Containers项目地址: https://gitcode.com/GitHub_Trending/gv/gvisor导读本文以仓库中 website/performance 目录为核心完整解读 gVisor 官方保留的 14 份基准测试数据CSV带你逐项看懂 runc 与 runsc 在启动时间、内存密度、CPU、系统调用、网络、文件系统等维度上的真实差距。同时结合 性能指南 中的结构性成本structural cost与实现成本implementation cost分析框架以及仓库内 test/benchmarks 的现代基准工具链说明这些数字从何而来、如何解读以及如何在你自己的机器上复现同类测试。读完本文你将具备独立评估 gVisor 沙箱性能模型并设计可复现基准实验的能力。一、性能数据目录历史基准的官方存档website/performance/README.md 是对整个website/performance/目录的说明。其核心信息有三点该目录存放的是由 benchmark-tools 仓库生成的 CSV 文件原 Python 版 benchmark-tools 已被移除功能等价的替代实现在仓库内的 test/benchmarksGo 语言重写基于标准库testing.B未来这些数据会被自动发布到云存储桶并由网站动态加载届时该静态目录将被删除。也就是说这批 CSV 是 gVisor 在特定历史版本、特定测试环境下的基准快照具有官方参考数据的地位但也是静态存档。目录中共有 14 个 CSV 文件CSV 文件对应基准维度startup.csv容器启动时间启动density.csv容器内存占用密度内存sysbench-cpu.csvCPU 计算吞吐CPUsysbench-memory.csv内存访问带宽内存syscall.csv裸系统调用延迟系统调用redis.csvRedis 典型操作吞吐系统调用/应用iperf.csv原始网络吞吐网络applications.csvnode/ruby HTTP 服务网络/应用httpd100k.csvApache 服务 100k 静态文件文件系统/网络httpd10240k.csvApache 服务 10MB 静态文件文件系统/网络fio.csv磁盘顺序/随机 I/O文件系统fio-tmpfs.csvtmpfs 内存盘 I/O文件系统ffmpeg.csv视频转码耗时综合tensorflow.csvCNN 训练耗时综合/CPU二、CSV 数据格式与指标约定所有 CSV 均采用扁平的长表结构前三列语义如下runtime被测容器运行时。仓库数据中仅出现runc原生容器与runscgVisorsyscall.csv额外包含runsc-kvmKVM 平台method基准方法/场景名例如startup.empty、density.node、http.node、fio.randread、PING_INLINE等。httpd*.csv的首列是connections并发连接数metric指标名例如startup_time_ms毫秒、memory_usage字节、transfer_rate、latency毫秒、requests_per_second、bandwidth字节/秒、syscall_time_ns纳秒、run_time秒等result实测数值。以 startup.csv 为例runtime,method,metric,result runc,startup.empty,startup_time_ms,1193.10768 runc,startup.node,startup_time_ms,2557.95336 runsc,startup.empty,startup_time_ms,1144.1775可以理解为runc 启动一个空容器仅执行true耗时约 1193ms这样的句子。注意memory_usage单位为字节、bandwidth单位为字节/秒阅读时需自行换算。三、测试方法论数据是怎么测出来的解读这些数字前必须了解 性能指南 中记录的测试前提否则极易误读机器环境Google Compute Enginen1-standard-4Broadwell虚拟机镜像 Debian GNU/Linux 9stretch内核 4.19.0-02048GB SSD 持久化启动盘默认平台除特别说明外所有 runsc 测试均在ptrace 平台上进行。ptrace 无需硬件虚拟化、兼容性最好但结构性成本最高不代表理想场景指南明确指出大多数场景应使用 Systrap 以获得最佳性能对照组runc代表原生容器基线runsc是 gVisor 的 OCI 运行时入口数据生成由 benchmark-tools 仓库产出即现在仓库内的 test/benchmarks。指南提出了一个贯穿全文的两分类成本模型这是理解所有数据的关键结构性成本structural cost由 gVisor 架构决定、无法通过优化轻易消除的成本。例如 Sentry 本身需要额外内存、应用系统调用必须穿越额外的软件层以及出于安全设计选用 Go 语言实现 Sentry 而带来的取舍实现成本implementation costgVisor 作为系统调用面的独立实现某些子系统尚未优化到成熟实现如内核、runc的同等水平。典型例子是网络栈仍在演进中、CPU 效率相对较低。这类成本是持续改进的对象。四、逐项解读基准数据4.1 启动时间startup.csvruntime场景启动时间msruncstartup.empty1193.11runscstartup.empty1144.18runcstartup.node2557.95runscstartup.node2441.90runcstartup.ruby2530.13runscstartup.ruby2455.70三个场景分别是执行true的 Alpine 空容器、加载多个模块并绑定 HTTP 端口的 node 应用以端口收到首个成功请求计时、行为类似的 ruby 应用。有意思的是这份历史数据中runsc 的启动时间与 runc 基本持平甚至略快这是因为绝大部分开销来自 Docker 本身——空容器的 runc 基线就已高达约 1193ms。指南特别提示若要规避 Docker 开销可考虑使用runsc do模式或直接调用 OCI runtime。4.2 内存占用与密度density.csvruntime场景内存占用字节runcdensity.empty4,092,149.76≈3.9MBrunscdensity.empty23,695,032.32≈22.6MBruncdensity.node76,709,888≈73.2MBrunscdensity.node124,076,605.44≈118.3MBruncdensity.ruby45,737,000.96≈43.6MBrunscdensity.ruby106,141,777.92≈101.2MBruncdensity.redis1,055,323,750.4≈1GB 数据runscdensity.redis1,076,686,028.8≈1GB 数据测量方法运行大量容器实例一般 50 个redis 为 5 个统计主机内存前后差值再除以容器数而不是直接读取 cgroup 的usage_in_bytes——因为某些运行时非 runc/runsc不创建独立容器 cgroup。结论清晰Sentry 带来一个小且基本固定的内存增量空容器约 18.7MB 的差额但随应用规模增长相对占比快速下降redis 场景仅差约 2%。对于追求高密度的场景大量低流量容器这部分固定开销是评估时的首要考量。4.3 CPU 与内存访问sysbench-cpu / sysbench-memory / tensorflow基准runcrunsc解读sysbench CPUevents/s103.62103.21几乎无差异sysbench 内存ops/s13098.7313107.44几乎无差异TensorFlow CNN 训练s207.11244.47慢约 18%指南指出gVisor不模拟、不干扰应用原生执行 CPU 指令因此 CPU 密集型负载没有运行时开销——sysbench 的 CPU 事件率数据印证了这一点。内存访问上页错误等 OS 机制虽然经由 Sentry 翻译但映射一旦安装后续访问没有额外开销。TensorFlow 示例卷积神经网络训练的耗时差异主要来自容器整体启动与运行时间且该测试同样基于 ptrace 平台。对于数据处理、机器学习等 CPU 密集型负载runsc 通常只引入极小开销。4.4 系统调用延迟syscall.csvruntimesyscall_time_nsrunc1939runscptrace38219runsc-kvm763这是唯一包含 KVM 平台数据的 CSV测试由自定义二进制执行大量裸系统调用后取平均。ptrace 平台单次系统调用约 38.2μs是 runc 的约 20 倍而 KVM 平台仅约 763ns比 runc 原生还低。这直观展示了平台选择对结构性成本的巨大影响。系统调用开销主要冲击系统调用密集型应用如高性能数据存储、静态网络服务应用在用户态做的工作越多被摊薄的相对影响越小。4.5 Redis 基准redis.csv操作runcreq/srunscreq/s相对吞吐PING_INLINE30525.0314528.55≈47.6%PING_BULK30293.8515627.44≈51.6%SET30257.1915403.57≈50.9%GET30312.2115325.67≈50.6%INCR30525.0315269.51≈50.0%LPUSH30712.5315172.20≈49.4%RPUSH30459.9515117.16≈49.6%LPOP30367.4515257.86≈50.2%RPOP30665.4415188.33≈49.5%SADD30030.0315432.10≈51.4%HSET30656.0415163.00≈49.5%SPOP29940.1215561.78≈52.0%LRANGE_10024224.8113365.41≈55.2%LRANGE_30014302.069520.18≈66.6%LRANGE_50011728.838248.78≈70.3%LRANGE_6009900.996544.07≈66.1%MSET30120.4814367.82≈47.7%规律非常典型单次用户态工作量越小的操作PING/SET/GET相对损耗越大而LRANGE这类在应用内部做更多工作的操作相对损耗更小。Redis 在用户态几乎不做事读 socket→改数据→写回 socket是系统调用结构性成本最吃亏的场景指南坦言 redis 很可能是长期具有挑战性的性能场景但优化平台选择也会有显著改观。4.6 网络iperf.csv / applications.csv / httpd*.csviperf 原始吞吐方向runcMB/srunscMB/sdownload≈711.9≈610.6upload≈677.0≈459.9测试中指定的运行时作为 iperf 客户端upload或服务端download另一端始终用原生运行时。HTTP 应用applications.csv25 并发模板渲染应用指标runcrunscnodetransfer_rate3814.851615.54nodelatencyms1127noderequests_per_second885.81375.13rubytransfer_rate2874.381382.71rubylatencyms1838rubyrequests_per_second539.97259.75Apache 静态文件服务httpd100k.csv单文件 100khttpd10240k.csv单文件 10MBApacheBench 驱动指标为 transfer_rate 与 latency(ms)并发连接runtime100k 吞吐KB/s100k 延迟10MB 吞吐KB/s10MB 延迟1runc565.351ms674.051ms1runsc282.842ms243.352ms5runc3260.571ms3089.831ms5runsc832.693ms981.912ms10runc4672.011ms4701.201ms10runsc1095.474ms1135.084ms25runc4964.142ms5021.362ms25runsc961.0312ms963.2612ms指南明确说明网络性能绝大部分受实现成本约束且 gVisor 的网络栈正在快速改进httpd这种在热路径上执行大量文件操作且所有请求读同一文件、存在内部串行点的基准同时叠加了 VFS 实现成本与网络栈问题结果predictably poor可预期的差属于最能体现当前实现瓶颈的极端场景。4.7 文件系统fio.csv / fio-tmpfs.csv / ffmpeg.csvfiosync 引擎磁盘场景runcMB/srunscMB/sread≈240.6≈240.7write≈436.6≈411.8randread≈5.0≈4.2randwrite≈102.8≈65.9fiosync 引擎tmpfs场景runcMB/srunscMB/sread≈4044.1≈2416.3write≈2889.2≈1151.5randread≈1164.8≈65.7randwrite≈997.6≈64.2ffmpeg 转码 27MB 视频总耗时runc 82.00s vs runsc 88.24s。解读要点原始磁盘 I/O 上 gVisor 无显著结构性开销fio.csv 中顺序读写与 runc 几乎持平因为磁盘本身成为瓶颈tmpfs 场景放大了 VFS 实现成本sandbox 内部的 tmpfs 不受磁盘瓶颈约束操作成本主要由内存拷贝与 VFS 层决定顺序读写约慢 40%60%随机读写差距更大约 6%16% 的吞吐保留指南指出文件系统方面同样实现成本占主导内部 VFS 实现需要改进属于快速改进中的领域ffmpeg 这类磁盘 I/O 为主 混合计算的负载中文件系统开销被摊薄整体仅慢约 7.6%。五、在源码中印证基准的实现数据与结论在仓库源码中有对应实现可查证基准工具本身test/benchmarks/README.md 说明了 Go 版基准的编写范式——使用testing.B、通过 dockerutil 启动容器、用harness.GetMachine()声明所需机器数、以b.ReportMetric()上报自定义指标fio 基准test/benchmarks/fs/fio_test.go 中可见BenchmarkFioWrite/Read/RandWrite/RandRead覆盖多种块大小4KB/64KB/1024KB、I/O 引擎sync/libaio、深度与多 job并在 bind/tmpfs/rootfs 三类挂载上重复测试测试要求 root 权限用于harness.DropCaches()清理页缓存ffmpeg 基准test/benchmarks/media/ffmpeg_test.go 展示了尊重b.N的典型写法——每次迭代新建容器执行ffmpeg -i video.mp4 -c:v libx264 -preset veryslow output.mp4计时只覆盖容器运行段其他基准目录networkhttpd/iperf/nginx/node/ruby、databaseredis、tcp含 nsjoin/tcp_proxy/xdp 等基准镜像Dockerfile 统一存放在 images/benchmarks 下约定使用显式版本化的包且不在镜像内写 ENV/CMD由 API 层dockerutil.RunOpts传入。六、在本机复现基准测试结合 Makefile 与 test/benchmarks/README.md可按下述步骤复现前提Docker 17.09.0、仓库构建环境、root 权限安装 runsc 作为 Docker runtimemake dev会将多个 runsc 配置写入/etc/docker/daemon.json请选择不带 debug 的配置运行单个基准make run-benchmark RUNTIME[RUNTIME_FROM_DAEMON.JSON/runc] BENCHMARKS_TARGETSpath/to/target一键多平台对比systrap、kvm 与原生 runc 同跑make benchmark-platforms BENCHMARKS_TARGETpath/to/target列出全部可用基准bazel query attr(tags, .*gvisor_benchmark.*, //test/benchmarks/...)Makefile 中可调的关键变量Makefile变量默认值作用BENCHMARKS_TARGETS//test/benchmarks/media:ffmpeg_test基准目标BENCHMARKS_FILTER.测试套件过滤正则BENCHMARKS_OPTIONS-test.benchtime30s传给go test的基准参数如-test.benchtime1m或-test.benchtime10xBENCHMARKS_RUNCtrue是否同时跑 runc 对照BENCHMARKS_PLATFORMS空只针对指定平台列表运行BENCHMARKS_UPLOADfalse是否将结果解析并上传 BigQuery配合BENCHMARKS_PROJECT/DATASET/TABLE/SUITE/OFFICIALBENCHMARKS_PROFILE空性能剖析选项如-pprof-dir/tmp/profile -pprof-cpu -pprof-heap关于性能剖析注意两点运行时需以--profile标志启用该标志会放宽 seccomp 过滤器以便写盘不建议用于生产剖析输出位于/tmp/profile且 runc 不支持剖析。Go 基准的基本骨架摘自 test/benchmarks/README.mdfunc BenchmarkMyCoolOne(b *testing.B) { machine, err : harness.GetMachine() // check err defer machine.CleanUp() ctx : context.Background() container : machine.GetContainer(ctx, b) defer container.CleanUp(ctx) b.ResetTimer() // Respect b.N. for i : 0; i b.N; i { out, err : container.Run(ctx, dockerutil.RunOpts{ Image: benchmarks/my-cool-image, Env: []string{MY_VARawesome}, }, sh, -c, echo MY_VAR) // check err... b.StopTimer() // Do parsing and reporting outside of the timer. number : parseMyMetric(out) b.ReportMetric(number, my-cool-custom-metric) b.StartTimer() } } func TestMain(m *testing.M) { harness.Init() os.Exit(m.Run()) }写作基准时需遵守三条约定尊重并随b.N线性扩展用户可用--benchtime10x或--benchtime1m控制迭代用b.ReportMetric()上报自定义指标客户端-服务端型基准如 httpd把b.N作为客户端容器发起请求数的参数。七、阅读这些数据的注意事项平台前提绝大多数 runsc 数据基于 ptrace 平台这是结构性成本最高的平台。从 syscall.csv 可见KVM 平台系统调用延迟比 runc 还低指南建议大多数场景使用 Systrap 以获得最佳性能。因此这批数据不能代表 runsc 在最优平台上的表现版本与时效CSV 是历史快照对应已移除的 Python benchmark-tools 时代机器为 n1-standard-4/Debian 9 内核 4.19不代表当前版本性能网络栈与 VFS 等实现成本正在持续改进负载匹配沙箱并非对所有负载都适用——例如可信数据库本就把用户数据置于沙箱内攻破沙箱并无额外收益这类场景沙箱价值有限成本归属系统调用、内存、密度数据主要体现结构性成本长期存在但可因平台优化而改善网络、VFS、tmpfs 随机 I/O 主要体现实现成本正在被持续优化。区分二者有助于判断该不该投入优化、优化空间在哪。总结website/performance 目录的 14 份 CSV 是理解 gVisor 性能模型的一手素材CPU 与内存访问几乎无开销、密度成本小且固定、系统调用与网络/文件系统是实现改进的主战场、平台选择ptrace/KVM/Systrap对结构性成本影响巨大。结合 性能指南 的成本分析框架与 test/benchmarks 的 Go 基准工具链你既可以读懂官方历史数据也可以按本文给出的 Makefile 命令在目标硬件上复现并评估适合自身负载的性能结论。【免费下载链接】gvisorApplication Kernel for Containers项目地址: https://gitcode.com/GitHub_Trending/gv/gvisor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考