共计 10900 个字符，预计需要花费 28 分钟才能阅读完成。
编者按：目前的平安容器软件栈 — 包含 host 操作系统中的 cgroup、guest 操作系统和用于函数工作负载的容器 rootfs，都会导致低部署密度和在低并发能力。为此，RunD 作为一种轻量级平安容器运行时，提出了 host-to-guest 的全栈优化计划来解决上述问题。本文整顿自龙蜥大讲堂第 38 期，精彩分享视频回放已上传至龙蜥官网（首页 - 动静 - 视频），欢送查看！
摘要
在轻量级虚拟机 (MicroVM) 中托管单个容器的平安容器当初曾经广泛应用于无服务器计算。因为其中的用户函数大多为细粒度形象，因而为了进步资源利用率和用户体验，Serverless 须要反对高密度的容器部署和高并发的容器启动。咱们的考察显示，目前的平安容器软件栈 — 包含 host 操作系统中的 cgroup、guest 操作系统和用于函数工作负载的容器 rootfs，都会导致低部署密度和在低并发能力。为此，RunD 作为一种轻量级平安容器运行时，提出了 host-to-guest 的全栈优化计划来解决上述问题。应用 RunD 运行时，能够做到在一秒钟内启动超过 200 个 平安容器，并且能够在一个 384GB 内存的节点上部署超过 2500 个平安容器。
一、介绍
函数计算作为无服务器计算（或者服务器无感知计算，Serverless）中的次要实现，通过隔离开发人员提供的细粒度函数并弹性治理应用资源，做到了更精细化的按量付费和更高的数据中心资源利用率。随着云原生技术的倒退和微服务架构的风行，利用被越来越多的拆分成更细粒度的函数并部署为 Serverless 模式。
但基于传统容器技术隔离的函数计算因为其较低的隔离性和安全性，曾经逐渐被替换成联合 MicroVM 和容器的平安容器技术为利用提供强隔离性和低提早响应。平安容器通常会在一个一般的容器外额定嵌套一层轻量级的 microVM 中，如下图 1 (a)所示。通过这种形式，用户能够基于现有的容器基础设施和生态系统构建 Serverless 服务。平安容器可能确保与 MicroVM 中的容器运行时兼容。Kata Containers 和 FireCracker 都提供了实现这种平安容器的实践经验。
(图 1 / 目前支流的平安容器模型，以及对应的软件栈架构)
在 Serverless 场景下，函数的轻量级和短期运行的个性使得高密度容器部署和高并发容器启动对于无服务器计算至关重要。例如，47% 的 Lambdas 在 AWS 上运行的最小内存规格是 128MB，在 Microsoft Azure 中，大概 90% 的应用程序的内存耗费从未超过 400MB。因为一个物理节点通常有很大的内存空间(如 384GB)，它按理应该可能部署大量的容器设计。同时，大量的函数调用可能会在短时间内达到。然而，平安容器的额定开销大大降低了函数的部署密度和启动容器的并发性。
图 1(b)显示了平安容器的软件栈层次结构。个别状况下，MicroVM 中的 guest 操作系统 (GuestOS) 和 host 上的资源调度都被转交给云提供商负责。rootfs 是一个文件系统，充当用户代码的执行环境。它是由 host 创立的，并传递给 microVM 中的容器运行时。在 host 端，cgroup 用于为平安容器分配资源，CPU 调度器负责管理资源分配。由此可见，平安容器的简单层次结构必定会带来了简单、高额的额定开销。
本文以 SOTA 的开源平安容器技术 Kata-containers 为出发点，通过深入分析从 host-to-guest 架构栈中的瓶颈点，提出了函数计算场景下平安容器高密高部署的 3 个要害察看和挑战：
- 容器的文件系统能够依据用户镜像只读和不须要长久化的特点进行定制；
- 客户机中的操作系统根底映像等能够在多个平安容器间共享和按需压缩以升高内存开销；
- 高并发创立 cgroup 会导致高同步时延，尤其在高密场景下带来的高调度开销。
为此咱们提出了 RunD — 超轻量级平安容器运行时，通过全栈的 host-to-guest 解决方案以提供高密度部署和高并发能力的反对。RunD 通过引入读写拆散的高效文件系统、预补丁和精简的 guest 内核以及一个全局可供保护的 lightweight cgroup 池以解决上述的三个高密高并发挑战。
依据咱们的评估，RunD 启动到利用程序代码只需 88ms，并且每秒能够在一个节点上启动 200 个平安容器。在一个领有 384GB 内存的节点上，能够应用 RunD 部署超过 2500 个平安容器。目前 RunD 曾经作为 Alibaba 的 Serverless 容器运行时，服务超过 100 万个函数，每天调用近 40 亿次。在线统计数据表明，RunD 使得每个节点的最大部署密度曾经超过 2000 个容器，并反对超过 200 个容器创立的疾速端到端响应。
二、背景
通过以上介绍，咱们理解了 RunD。那么在本节中，咱们将首先探讨以后平安容器的设计，以及为何须要引入 RunD 的需要。
2.1 平安容器模型
依据不同级别的平安 / 隔离需要，目前 Serverless 的生产环境中通常有两类支流的平安容器模型。图 2(a)显示了”单虚拟机多容器“的平安容器模型。在该模型中，一个虚拟机 (VM) 承载着雷同函数调用的容器，同一虚拟机中的容器共享虚拟机的 guest 操作系统。在这种状况下，对不同函数采纳 VM 级别的隔离，但对同一函数的不同调用为 container 级别隔离。因为每个函数所创立和所须要的容器数量不同，该模型会导致潜在的内存碎片。尽管咱们能够在运行时回收内存碎片，但这可能会重大影响函数性能，甚至在虚拟机内存热拔失败时导致程序解体。
（图 2 / 两种支流的平安容器模型隔离）
图 2(b)显示了隔离每个函数调用的“单虚拟机单容器”的平安容器模型。目前的无服务器计算提供商次要应用这种平安容器模型。在此模型中，每个调用都在一个 microVM 中的容器中隔离并执行函数。这个模型没有引入内存碎片，然而虚拟机自身的内存开销很大。很显著，每个 microVM 都须要运行其专用的客户操作系统，从而减少了内存占用。平安容器依赖于硬件虚拟化和 VMM 的平安模型，通过零碎调用查看显式地将 guest 内核视为不可信环境。在这种隔离和安全性的前提下，RunD 次要针对“单虚拟机单容器”的平安容器模型。
2.2 Serverless 场景下的需要
在 Serverless 场景下如果利用平安容器进行隔离，人造的细粒度隔离带来了新的简单场景，咱们须要满足一个硬性需要和两个衍生需要：
- 高速：无服务器计算的极致的主动扩大能力容许实例数量依据负载个性动静横向扩大，创立速度要快，E2E 启动工夫达到百毫秒级。已有大部分工作致力于解决相干问题。然而还须要保障启动时延的鲁棒性，使得其不会显著受到运行时烦扰，比方以后并发数和部署密度的影响。
- 高频：每天上百万的实例创立量，上亿次的函数调用，须要撑持每秒内容器的高并发创立。与此同时，新兴的互联网服务往往出现稳定的负载模式（如外卖软件在中午和早晨负载高，其余时间段负载低），并呈现突发负载。当负载暴发时，须要创立大量的容器。尽管目前能够通过一些技术，如预热容器来缓解容器冷启动，但爆发性负载依旧会非常容易的击穿预热容器池。对于无服务器平台来说，反对高并发启动的能力至关重要。
- 高密：大量容器共存于工作节点中，为保障极致弹性和资源利用率，须要思考内存和 CPU 资源占用问题。如果一个平安容器没有工作隔离开销，领有 256GB 内存的节点能够托管 8×256 = 2048 个容器。如果没有特地的优化，平安容器会明显降低无服务器计算中的部署密度。在雷同的基础设施下，减少部署密度能够极大地提高资源利用率和多租户服务效率。
三、问题剖析和见解
在本节中，咱们将剖析应用平安容器实现高并发启动和高密度部署的问题。
应用 Kata 容器作为平安容器运行时的代表来执行以下钻研。
图 3 / 并发启动 Kata 容器的步骤。并发瓶颈点在于创立 rootfs（红色块步骤 1）和创立 cgroups（红色线步骤 3）密度瓶颈点在于 MicroVM 的高额内存开销（蓝色块步骤 2）和大量 cgroups 的调度保护开销（蓝色块步骤 3）
图 3 显示了启动 Kata 容器的步骤。首先，containerd 并发地创立容器运行时 Kata-runtime 并筹备 runc 容器的 rootfs。其次，hypervisor 加载 GuestOS 和筹备好的 rootfs，在 microVM 中启动 runc 容器。第三，函数工作负载被下载到容器中，而后开始运行。
与启动传统容器相比，在启动平安容器时，咱们有两个察看后果。
- 当并发启动 100 个或更多 Kata 容器时，在筹备 Kata 运行时创立 rootfs 和 cgroup 会有显著的性能降落。这种升高导致启动容器的并发性较低。
- 当在一个 384GB 内存和 104 个核的节点上部署超过 1000 个 128MB 内存规格的 Kata 容器时，虚拟机的内存占用 (guest 内核和 rootfs) 曾经占据了大部分内存空间。同时，容器的 I/O 性能也会重大降落。
图 3 还显示了咱们发现的导致上述两个后果的三个瓶颈。一般来说，创立 rootfs 和 cgroup 的低效会导致低容器启动并发。较高的内存占用和调度开销导致较低的容器部署密度。咱们将在上面的大节中剖析各个瓶颈点。
3.1 容器的 rootfs 的高时空开销
在 kata-runtime 中，容器的 rootfs 次要能够抉择 9pfs、devicemapper、virtio-fs 三种计划。9pfs 和 virtio-fs 属于文件级别的计划，devicemapper、属于块设施层计划。
为了抉择适合的高并发场景下的容器 rootfs 计划，咱们首先须要比照 9p、devicemapper 和 virtio-fs 计划之间的性能，次要分为 buffer I/O 和 direct I/O 在程序读、程序写、随机读、随机写和随机读写几个方面，关注 IOPS 和带宽数据。另外也测试了 runc 在 host 上应用 ext4+overlayfs 存储环境的数据作为比照。
（图 4 / 应用不同 rootfs 实现的随机和程序读、写的 IOPS 和带宽性能）
比照上述三种计划，咱们首先摒弃基于 9p 计划的高密高并发容器架构，起因是因为其 mmap 操作上 POSIX 语义兼容性问题和性能较差。而后，咱们别离测试了基于 devicemapper 和 virtio-fs 的计划性能，并发现两种计划各自的问题：
- 在默认配置下(即 writeback)，devicemapper 的随机 / 程序 写 性能较好。然而在高并发场景下创立、删除慢。在没有 I/O 压力状况下，创立一个 device mapper thin-lv 须要 30-40ms 的工夫，在大 I/O 压力下，创立工夫可能会到秒级甚至 10s 级，造成创立 snapshot 失败和容器创立失败。高密场景下内存开销高。devicemapper 须要为每一个 microvm 筹备 rootfs.img，但同时又不反对 host/guest 共享 volume 性能，于是 virtio-blk backend 读取 host 上 rootfs image 文件会产生这个文件的 host pagecache；在 guest 里再读取这个 block 设施内容时，在 guest 外部也会产生一次同样内容的 pagecache，就造成了 double pagecache。
- virtio-fs 是专门为 KATA 场景设计的计划，有着良好的性能和欠缺的 POSIX 语义兼容性。virtio-fs 在应用 DAX 的状况下，dax+virtio-fs 各项随机 / 程序读性能指标都很好，然而在高密高并发场景下写性能很差，同时 virtiofsd 承载容器读写的压力时，会造成 virtiofsd 在 host 上过高的 CPU 使用率。所以不适宜大 I/O 压力场景，和大量小文件或者 metadata 操作的场景。
总结下来，咱们能够得出这样的见解：在现有 kata 架构和存储计划下，任何繁多存储计划不适用于高密高并发的场景。须要将容器 rootfs 的存储变为读写拆散模式，其中：读方面，能够应用 dax+virtio-fs 计划可能在保障性能的前提下，共享 host/guest 之间 page cache，升高内存开销。写方面，利用现有基于 device mapper 的高开销计划须要升高可写层设施的创立工夫，以及解决 double pagecache 的问题。基于 virtio-fs 的低性能计划须要演进至扩大到满足大 I/O 压力场景的前提，以及升高 host 上的 CPU 开销。因而现有计划都不实用，须要寻找替换计划。
3.2 单 MicroVM 的高内存空间开销
在高密下单个实例资源间接影响部署容器数量。高密部署下单个实例的除了提供给用户须要的内存规格大小以外，其余组件的资源占用往往是一个高额开销。firecracker 在公布时将内存占用缩小到 5MB，但这个仅仅是 firecracker VMM 的占用，运行内核包含代码段、数据段等，以及内核治理内存的 struct page，启动的 rootfs 等内存资源，不能只从 VMM 的内存占用来评估实例的额定占用。比方，通过启动数个 AWS 128MB 的 lambda 函数理论的均匀内存开销是 71MB，传统的 QEMU 带来的内存开销则更大，达到了 145MB。
（图 5 /Kata 平安容器应用不同 hypervisor 的均匀内存开销）
目前 state-of-the-art 的形式是应用模版来解决 double page cache 以实现高密部署。个别状况下同一台物理机上每一个平安容器实例的 guest 内核都是雷同的，模版利用 mmap 技术代替文件 IO 操作，将内核文件间接映射到 guest 内存中。这样，guest 内核就能够按需载入内存，并且其 text/rodata segment 能够在多个 kata 实例中共享，并且模板中没有被拜访到的内容也不会被载入到物理内存中，平安容器实例的均匀内存的耗费天然就会大大减少。
然而，因为操作系统内核中的自批改代码，模板技术并没有咱们设想的那么高效。自批改代码技术在运行时按需批改指令，Linux 内核在很大水平上依赖于自批改代码来进步启动和运行时的性能，因而这样会导致有许多本应是只读的内存仍旧被 guest 内核批改。咱们从一个模板启动一个带有 CentOS 4.19 内核的虚拟机，来钻研自批改代码的影响。当通过模版启动一个 128mb 实例后，发现 17M（18432K）的 geust kernel 代码和只读数据，启动过程中理论只拜访了不到 10M（10012K），然而在被拜访的 10M 数据中竟然有 7M（7928K）多的数据被批改了。这个例子表明，当应用 mmap 来缩小内核映像文件的内存耗费时，自批改代码升高了共享效率。
因而，咱们的第二个见解是因为 kernel 的自批改个性导致利用模版技术时，可供共享的内存数量有所缩小。如果能解决利用模版时创立过程中 guest 内核启动时自批改代码，咱们还能节俭更多内存以笼罩大部分动态内存耗费。
3.3 cgroup 的高 CPU 工夫开销
Cgroup 是为资源管制和流程形象而设计的。在 Serverless 场景下，函数调用的频率显示出很大的变动。在这种状况下，平台会频繁创立并回收相应的平安容器。例如，在咱们的无服务器平台中，在一秒钟内最多能够在一个物理节点上同时创立和回收 200 个容器。频繁地创立和回收对主机的 cgroup 机制提出了挑战。
当并发创立 2000 个容器时，咱们测量 cgroup 操作的相干指标和性能图如图 6 所示。在试验中，咱们应用不同数量的线程来执行 cgroup 操作。图 6(a)显示了容器创立提早的累积散布。单线程场景中，容器启动时创立 cgroup 并初始化所用的耗时约为 1ms，在总创立的 cgroup 数量雷同，多线程并行的场景下，低并发启动场景下可能取得少许性能晋升。但在高并发场景下，与咱们的直觉相同，只管每个线程创立的 cgroup 变少了，但总耗时反而减少了，甚至不如单线程的间断操作的成果。
（图 6 / 并发创立 2000 个容器时的 cgroup 性能）
其中的起因是：cgroup 实现非常复杂，波及 10 多类资源管制（cgroup subsys），内核为了简化 cgroup 的设计引入了 cgroup_mutex，css_set_lock、freezer_mutex、freezer_lock 等大锁，使得 cgroup 相干的操作都是串行化的；在高并发场景下，导致了整个创立链路上的串行执行会拖慢并发创立的效率，减少长尾提早。图 6(b)显示了同时应用 10 个线程创立 2000 个 cgroup 的火焰图。在图中，红色局部显示“互斥锁”被激活。当 mutex 中默认应用了 osq_lock 乐观锁优化，在 cgroup 抢不到锁的状况下会自旋一会儿，导致多线程场景大量耗费 CPU 资源，不能及时退出临界区，从而影响正在运行的函数实例。
除此之外，cgroup 机制是为通用业务场景设计的，设计之初并没有思考到云原生场景会如此大规模的应用它们。在一个上千容器共存的 faas 节点中，cgroup 总数轻松冲破 1 万。在 CFS 调度器中，有遍历各自 cgroup subsys 所有对象的行为。在高密场景下，零碎中 cgroup 数量很多时，导致调度器中的热点函数变为瓶颈，导致高 CPU 调度开销。（占整机的均匀调度开销的 7.6%）
针对上述发现，咱们的第三个见解是，Serverless 场景下 host 上的 cgroup 存在高密高并发的瓶颈，须要：
1）升高 cgroup 中因为 mutex 锁引入的“临界区”大小，最好是打消；
2）同时精简 cgroup 的性能，同时升高 cgroup 设计的复杂度。
四、RunD 设计和实现
上述剖析揭示了在 host、MicroVM、guest 三层架构栈中实现高并发启动和高密度部署的瓶颈。为此，咱们提出了 RunD，一个整体的平安容器解决方案，解决了跨容器的反复数据、每个虚拟机的高内存占用和 host 端 cgroup 的高开销问题。在本节中，咱们首先展现 RunD 的总体设计，而后介绍每个组件的细节，以解决相应的问题。
4.1 总体架构及流程
在设计 RunD 时，咱们失去了对于无服务器运行时的一个要害启发。在高密度和高并发的 Serverless 场景中，传统 VM 中微不足道的 host 端开销可能会造成放大效应，任何微不足道的优化都能够带来显著的益处。
（图 7 / 轻量级 Serverless 运行时 RunD 架构图）
图 7 显示了 RunD 设计并总结了 host-to-guest 的全栈解决方案。RunD 运行时通过 virtio-fs 提供只读层，应用 built-in storage 为 virtio-blk 创立一个非长久的读写层，并应用 overlayfs 将前者和后者挂载为最终的容器 rootfs，从而进行读 / 写拆散。RunD 利用集成了精简内核的 microVM 模板，并采纳预处理的镜像创立一个新的 microVM，进一步摊派了不同的 microVM 的开销。在创立平安容器时，RunD 从 cgroup 池绑定一个轻量级的 cgroup 进行资源管理。
基于上述优化，当应用 RunD 作为平安容器运行时，平安容器将依照以下步骤启动：
第一步：一旦 containerd 接管到用户调用，它将申请转发给 RunD 运行时。
第二步：RunD 为虚拟机 hypervisor 筹备 runc 容器的 rootfs。rootfs 被分为只读层和可写层。
第三步：hypervisor 应用 microVM 模板创立所需的沙箱，并通过 overlayfs 将 rootfs 挂载到沙箱中。
最初一个轻量级的 cgroup 从 cgroup 池中被重命名，而后绑定到沙箱上，治理资源应用。
4.2 高效 rootfs 读写拆散
咱们剖析了容器 rootfs 中的高密高并发场景下各种计划的长处与毛病。microvm 中 container rootfs 所面临的基本问题，其实都是数据长久化需要所带来的问题。传统存储需要和场景须要十分高的稳定性和数据一致性，也就是在任何状况下都不能丢数据，但数据长久化在函数计算这个场景下齐全是不须要的，咱们须要的只是一个长期存储，host 节点宕机重启咱们只须要从新初始化并拉起新的容器，之前的数据都不再须要了。所以，咱们齐全能够放下这个累赘，并且充分利用好不须要长久化的长期存储这个个性。
为此咱们把容器镜像分成只读和可写两层，那么 containerd 的 snapshotter 应该只负责提供镜像的只读内容，可写层资源应该属于具备长期存储个性的 sandbox，把容器创立和可写层设施创立解耦开来。为了让可写层设施后端文件和 sandbox 也就是 rund 的生命周期绑定到一起，并且尽可能防止 double pagecache 的问题，咱们应用了 xfs 文件系统的 reflink 性能实现可写层文件的 CoW，同时利用了 open-but-unlinked 文件的个性，在创立 sandbox 的时候只须要做一次 reflink copy，关上文件之后 rund unlink 文件，不须要做其余生命周期治理了，实现了 sandbox 退出后文件会主动删除。咱们引入了的架构如下图 8 所示：
（图 8 / 容器 rootfs 的读写拆散实现）
- 应用 overlay snapshotter，创立容器镜像 rootfs，并通过 virtiofs 透传给 VM，作为容器 rootfs 的只读层。
- 将把 reflink copy 后的文件作为 virtio-blk 设施的后端，将 reflink copy 后的可写层文件作为 block 设施内置在 microvm 中作为长期存储，作为容器 rootfs 的可写层。
- 在 VM 内应用 overlayfs，virtiofs 作为 lower layer，reflink 文件的挂载点作为 upper layer，挂载成 overlayfs，作为容器最终的 rootfs。
通过 reflink 形式实现可写层文件的 CoW，并且因为是实质上是 block 设施的计划，在读写性能上和 devicemapper 根本持平。与传统基于块设施的 rootfs 实现形式比照，在 200 容器并发创立的场景下，reflink 形式的磁盘使用率显著降落 (60% (4500 iops, 100MB/s) -> 20% (1500 iops, 8MB/s))，创立可写层设施的均匀工夫从 207ms 降落到了 0.2ms，足足降落了 4 个数量级！
4.3 内核精简和代码自批改补丁
在 Serverless 的场景下，guest 内核中的许多性能是不必要且占用内存的，因而咱们能够在编译的时候敞开这些选项。精简 guest 内核时，咱们遵从以下准则：
- 尽量升高内存耗费
- 不损失 faas 场景须要的性能
- 根本不影响运行时性能
通过 case by case 的精简，使得内存开销降落了约 16MB，内核文件体积降落了约 4MB。咱们首先将精简过的 kernel 和上节介绍的 container rootfs 存储利用在模板技术中，而后再解决从模版启动容器后内核自批改的问题。
咱们发现内核代码段的自批改只存在于启动时，在启动后，这些代码段将不再会被批改，并且同一物理机中的所有 rund 实例个别都应用同一内核，它们初始化过程是完全相同的，因而它们批改后的代码段也是雷同的。于是，咱们便能够事后生成一个自批改代码段后的内核文件（pre-patched kernel image），并且应用其替换原来的内核文件，这样，咱们就可能尽可能多地在不同平安容器的实例间共享内核文件了。为了适配这种模式，咱们也对内核进行了大量 hack 工作，修复了一些应用 pre-patched kernel image 时可能导致 kernel panic 的问题。
应用模版技术不仅能够升高单个实力的内存占用实现高密部署，还非常适合利用于平安容器的高并发场景。因为它能够在某个特定时刻对一个曾经启动的平安容器创立快照，并将其作为其它平安容器的启动模板，这样咱们就能够通过这个模板疾速拉起多个平安容器。实质就是将每个平安容器启动过程中的雷同步骤的后果进行记录，而后间接跳过雷同步骤，间接基于该两头后果启动平安容器。
4.4 轻量级 cgroup 和池化
在之前的大节中咱们剖析了在 host 中 cgroup 成为了容器在高密高并发下的瓶颈之一，天然的想法就是缩小 cgroup 的数量和相干操作。咱们的进一步钻研揭示了两个方面的优化机会：
- cgroup 的创立和销毁比拟耗时（临界区很大），且不能并行化。然而 cgroup 重命名是一个十分轻量化的操作，且不波及全局锁。
- Serverless 高密场景下，所须要的 cgroup subsys 的层次结构是确定的，同时一个单机上所能创立的最大函数实例数量是能够事后定义的。
为此，咱们应用轻量级 cgroup (lightweight cgroup)治理每个 RunD 实例。如图 9 所示，咱们使 mount cgroup 时将所有的 cgroup subsys（cpu, cpuacct, cpuset, blkio, memory, freezer））聚合到一个 lightweight cgroup 上，这帮忙 RunD 缩小容器启动时冗余的 cgroup 操作，显著缩小了 cgroup 和零碎调用的总数。
（图 9 / 轻量级 cgroup 和池化设计）
同时咱们保护一个 cgroup 资源池，将所有初始创立的 cgroup 标记为闲暇；通过一个 mutex 爱护闲暇链表，创立一个函数实例时，从闲暇链表中获取 cgroup，并标记为应用；当容器启动时将线程 attach 到对应调配的 cgroup 即可。当销毁一个函数计算实例时，只须要 kill 对应的实例过程，不须要删除 cgroup；将 cgroup 还会资源池，标记为闲暇。须要留神的是 cgroup 资源池治理波及同步和互斥问题，必须要保障这个临界区很小，否则不能达到进步并行度的成果。
Lightweight cgroup 池去除了 cgroup 的创立和初始化操作，同时利用 cgroup rename 机制为新的实例调配 cgroup，极大的放大了临界区，进步并行性。通过这一简略思维，cgroup 操作耗时大幅度降低，创立速度晋升了 15 倍，达到了近 94% 的性能优化。
五、性能测试
5.1 并发度指标测试
(图 10/ 高并发创立场景下端到端时延、散布、和 CPU 开销)
并发性能总结：RunD 可能在 88ms 内启动一个独自沙盒，并具备在 1 秒内同时启动 200 个沙箱的并发能力，与现有技术相比，具备最小的提早稳定和 CPU 开销。
5.2 单实例开销和部署密度测试
（图 11/ 不同运行时的沙箱内存开销（100 密度下））
（图 12/ 不同密度下的均匀内存摊销（缺失点示意已达到最大部署密度））
高密部署总结：RunD 反对在内存为 384GB 的节点上部署超过 2500 个 128MB 内存规格的沙盒。且每个沙盒的均匀内存占用小于 20MB。
5.3 部署密度对并发度的影响测试
（图 13/ 在不同密度下的并发性能（10c/200c 示意 10 并发 /200 并发，Delta 代表更高密度带来的开销增量））
高密下高并发能力总结：在高密度部署下，RunD 在反对高并发创立方面体现出了更好的性能和稳定性。
总结
依据试验评估，RunD 能够在 88 毫秒内启动，并且在 104 核 384GB 内存的单节点上每秒启动超过 200 个平安容器，高密部署超过 2500 个函数实例。RunD 作为阿里云的 Serverless 运行时曾经部署上线，每天为超过 100 万个函数和近 40 亿的调用提供服务，并踊跃推动 Kata 社区 3.0 架构的演变。
—— 完 ——
