容器 34：冷启动时间花在哪一段
拿一条从 docker run 到终端提示的总耗时，无法推断是拉取慢、快照准备慢、进程启动慢还是应用就绪慢。先定义测量的边界与可关联的对象，然后谈数值。
先写实验设计，后写结论
同一 probe-app 固定 image digest、节点 CPU 架构、内核与运行时版本，在专用 VM 上分冷缓存与热缓存两组。时间戳分别落在开始拉取、manifest/layer 验证结束、本机解包与 snapshot 准备结束、OCI create/start、进程首条日志、/ready=200。对同一 ID 记录事件时钟来源，跨组件不能把不同机器的墙钟未经校准就做相减。预先确定预热次数、重复次数、并发、输入大小和失败率，报告每段延迟分布而不是一次的总值；把镜像缓存和应用缓存状态同时记录。
边界例是第二轮 pull 因内容已在本地而很快，服务却因独立的就绪延迟仍返回 503。把这两段之和直接叫“镜像启动慢”会误判优化目标。一次用户请求成功还可能发生在 ready 之前或之后，需用相同 readiness 条件比较。实验变量表和有界探针保证输入一致；本机无构建器、运行时或集群，所有时间分段、重复数据、性能结论 NOT_RUN，不填估算数字。
| 现象 | 测量对象 | 前提 |
|---|---|---|
| 冷启动慢 | 下载字节、解包与启动分段 | 先锁定缓存状态 |
| 第二次快 | 相同 digest 的本地 content | 不能推断另一节点也快 |
| Running 但 Ready 慢 | 进程/就绪计时 | 与镜像传输分开 |
练习
- 先预测镜像已在节点 content store、应用
ready-delay=10时哪个阶段占主导，分别保存每段真实起止时间。 - 预测网络缓存已热但 snapshot 尚未准备时总时延能否靠减少镜像大小改善，按事件区间取证，不凭最终总和猜因。
系列总目录：从进程隔离到运行时与编排。
参考资料
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-10-01
容器 09：组合隔离机制时启动和清理的顺序
前八篇分别讨论进程、namespace、身份、资源和权限。如果只把它们列在命令行上，很容易遗漏“父进程何时写映射”“谁等待子进程”“初始化失败后对象如何退出”。这篇用一个受限教学启动器展示顺序，并明确它没有实现的隔离，避免误当成生产容器。 一个可核查的局部链路 源码共用源码包内的 teaching_launcher.c 固定执行同目录内自编译的 process_probe，没有接受用户指定的命令行、镜像或任意路径。启动器记录外侧 UID/GID，先 unshare(CLONE_NEWUSER)，将内部 UID/GID 0 映射到原外侧身份；在写 GID 映射之前向 setgroups 写 deny。随后建立新的 UTS、IPC namespace，在私有 UTS 中设置测试 hostname。fork 后只有子进程 exec 自编程序，父进程 waitpid 并返回子进程状态。设置顺序的核心是写映射时“当前进程处于哪个 namespace”，而不是把一串 unshare 选项当成 magic flag。 从当前源码画出真实的控制流 第一步在外侧读取实际 UID/GID；这两个数字...
2026-10-01
容器 E07：镜像按需读取是否真的缩短首个请求
34 的冷启动时间分为下载、快照准备、进程和就绪；远程 snapshotter 可能避免在进程启动前取回整份镜像，但把部分内容读取成本移到了首次访问文件时。不能只比较 `create` 的返回速度，就说一次 HTTP 请求更快。 两类成本都算入请求链 固定一个支持按需读取的 snapshotter 与镜像格式，记录启动前实际传输字节、读取文件时额外传输字节、首个请求的耗时、后续请求命中缓存情况。stargz-snapshotter 文档描述了远程按需读取与 eStargz 相关机制；具体实现是否选用了该插件、如何缓存，以及失败后如何回退，必须按实际节点版本和源码路径核对。正例预先设计“启动后只访问镜像中少数文件”的探针；边界例第一次访问未预取的大文件或在受控实验网络中断开远端，可能使首请求变慢/失败。断网仅作用于独立 VM 内的自建网络。 实验矩阵与恢复、统一探针源码允许对照常规 snapshotter；云端没有 containerd/snapshotter、没有真正的镜像按需网络路径，下载字节、缺页、首请求数据一律 `NOT_RUN`。不能把 10 的本地 OCI 布局静态校验...
2026-10-01
容器 35：性能差异来自隔离层还是实验条件
“容器性能损耗多少”缺少测量对象和实验条件。应用计算、内存申请、文件系统 copy-up、网络封装都在不同路径上。34只评估启动，不把 steady-state 性能一起平均。本篇先设定可以证伪的对照，再决定哪些数字能归因于容器边界。 逐项只改变一个条件 同一内核、架构、节点、二进制和输入，先在普通进程跑 bounded_load 的有界计算/内存路径，再在专用容器内跑同样命令；分别记录用户态时间、CPU/内存控制器、可运行 CPU 集与真实的 cgroup 限制。文件系统实验区分宿主相同盘的普通写入、容器可写层首次写入与同一镜像的重复写入；网络实验区分 loopback、veth、bridge 与跨主机封装，应用请求也要用相同连接/大小分布。每组预设预热、次数、并发、成功与失败计数，报告吞吐与分位数及原始数据，不可只挑最快一轮。 失败或反例是把一个组放在远端存储、另一个组放在本地盘，却将延迟差归因于 OverlayFS；或让一组命中页缓存、另一组做冷读取，还声称 cgroup 导致 I/O 变慢。必须逐项记录存储设备、缓存条件、CPU 亲和性、流量路径、镜像 digest 和安...
2026-10-01
容器 18：containerd 管的是镜像、任务还是进程
17 的 OCI runtime关注单个 bundle 的 create/start/delete；更上一层还要保存镜像内容、展开快照、管理任务生命周期。containerd 的 content store、snapshotter、container metadata、task 和 shim 并不是五个同义词。它们各自关联不同对象，故一个动作“删镜像”与“停 task”不应被写成相同效果。 内容引用与进程引用分开 按 containerd 的 Runtime V2 文档，运行时 shim 承担与任务相关的运行时集成，OCI runtime 可用于创建实际进程。content store 保存内容寻址的字节；snapshotter 为运行准备文件系统视图；task 对应运行中的进程生命周期。containerd 的 namespace 是其 API/元数据隔离维度，不能拿它代替 Linux namespace inode，更不能把它当 Kubernetes Namespace 的定义。一个镜像引用可以消失而正在运行的进程仍存在；停止任务也不会自动清空 registry 的原始镜像。...
2026-10-01
容器 19：一次 run 在哪一步变成 exec
“docker run 成功了”最多说明某条客户端请求获得了响应，不保证 probe-app 能够接收真实业务请求。先把13 的镜像制品、18 的 content/task和17 的 create/start沿时间摆成一条链，再讨论不同故障落在哪一层。 一次请求的可能路径 用户端请求 daemon 创建或启动容器；daemon 对镜像引用做解析或拉取，准备快照与运行配置；下游运行时创建对应 Linux 进程并执行入口。是否通过 containerd、shim、哪一种 OCI runtime 由本机版本与配置决定，不能给出未经版本验证的唯一函数调用栈。进程 exec 成功之后，应用还可能解析参数失败、只监听 loopback 或尚未就绪。把“客户端返回”、“daemon 对象创建”、“宿主进程执行”、“HTTP /ready=200”各自作为检查点，才能说清哪个阶段失败。 正常案例要求同一次构建的 image digest 贯穿 docker inspect、runtime ID、宿主 PID、namespace inode 和请求日志，按时间排序保存不同组件的...
2026-10-01
容器 39：CPU weight 在竞争下是否才起作用
独立研究要回答一个可以被实际结果推翻的问题，而不是重新打包35 的性能清单。选用 Linux kernel cgroup v2 官方技术文档中 cpu.weight 的语义作原始来源，提出命题：同一父 cgroup 的两个有界计算负载同时争用相同 CPU 集时，改变其相对 weight 会影响所得 CPU 时间份额；若只有一个任务运行且 CPU 足够空闲，改变 weight 不应当被写成“硬配额”。 将文档语义变成可证伪实验 实验前固定专用 Linux VM、内核/cgroup v2 版本、物理或虚拟 CPU 数、cpuset、频率与可用邻居负载，两个探针用同一 bounded_load.py 代码但以较长的有界窗口重复。各组预设至少十次，交叉调换两个子 cgroup 的 weight 与运行顺序，保存 cpu.stat、调度相关计数、每次工作量、总耗时和错误数；以相同父组和相同配额条件比较。另运行“只有一个子组工作”的反例组，排除把权重理解成任何时候都有的硬限速。若 CPU 饱和条件不成立，即使观察不到差异也不能归因于权重规则失效。 实际文件写入只允许在专用 VM 管理员委派的...