近日，第四届中国云计算基础架构开发者大会（china cloud computing infrastructure developer conference – 简称 cid），秉持着纯技术、非商业化的原则，以「自由、协作、创新」为核心理念，在深圳与技术开发者们见面。本次大会聚焦于业界最前沿的云计算基础架构技术成果，涵盖主论坛及三大技术主题分论坛，围绕基础架构技术领域的技术交流，展示先进技术在行业中的典型应用，赋能行业客户实现业务变革。
在主论坛上，OpenCloudOS 社区成员、腾讯资深内核研发专家——曾敬翔，以《云原生场景下内存多级卸载落地实践》为主题，分享了腾讯在实施内存多级卸载方案过程中遇到的实际问题、对应的解决方案，以及在容器平台上的落地数据。以下是分享的重点内容。
一、产业背景内存需求成本不断上升，提升内存利用率成为关键问题：
1. 数据中心硬件采购成本中，服务器占比最高，其中 CPU、GPU 和 DRAM 是主要成本项；
2. 随着数据量和业务复杂度的增加，内存需求激增，应用程序为了提高性能，通常采用内存密集型策略，长时间运行或大量服务并存时会面临巨大的内存压力，如内存颠簸、OOM 等。云计算对内存需求也在持续增长。
3. 业务中不活跃的冷内存占有很大比例，比例值根据业务不同会有波动，比如我们在集群中抓取的一些典型 workload 的冷热内存占比如下图。
绿色线表示总的内存使用量，蓝色线是匿名页的冷内存占比，橙色线是文件页冷内存占比。可以看出，冷内存占集群的比例较高。
在这样的背景下，内存多级卸载应运而生。如下图，使用内存多级卸载后，每个 workload 可以节省出很多空闲资源。对于这些空闲资源，我们在PHP中文网应用中主要有三种使用场景。
第一种，业务超卖场景：对 workload 开启多级卸载后，增加单个 pod（CVM）的流量，提高 TPS、QPS。
第二种，负载降配
●降低业务成本：对 workload 开启内存多级卸载后，降低 workload resources 的 memory request 和 limit，降低平台业务的上云成本。
●提高集群装箱率：多数集群节点的 CPU/MEM 比例为 1:2，但现网上很多是大内存 workload（1:4，1:8），影响集群装箱率，将大内存 workload 降配后（1:8 -> 1:4），可以提高集群装箱率。
第三种，混部弹性内存超卖
提高内存混部率：把非内存敏感型 workload 开启内存多级卸载，节省出多余的空闲内存资源，可以调度更多的离线（低优先级）pod 上来，并且，在整机内存压力大又不能及时迁出的情况下，优先迁出、OOM 调离线（低优先级）pod。
二、整体解决方案在云原生场景中落地内存多级卸载时遇到的实际问题：
●回收路径难以确定：内存多级卸载的回收名单是 cgroup path list，但在云原生容器平台中，pod cgroup path 是一串哈希值，并且 pod 会在集群的 node 中间迁入迁出，实时调度，如何确定节点上哪些 pod 需要开启内存多级卸载，并且随着 pod 状态的改变，实时改变回收及更新名单？
●回收参数难以确定：在容器平台中，需要开启内存多级卸载的 workload 对内存回收的敏感程度是不一样的，如何判断 workload 类型，然后使用对应回收参数？
●主动回收也会导致一些问题：
(1)误回收“冷”文件页：主动回收额外的文件页面，由于当前 lru 精度比较单调，导致误回收一些将会访问的页面，导致 cache miss，造成读 IOPS 增加。
(2)过度压缩匿名页：在主备存储模型中，备份节点一直处于空闲状态，因为 PSI 一直表征空闲情况，内存多级卸载不断将其匿名页面压缩到 zram，突然的主备切换，导致备节点突增大量请求，所有在 zram 的页面基本都需要解压，造成颠簸的延迟反应。
●zram 的页面无法统计，这也是社区面临的问题：目前 workload 的 resources.limits.memory 是对 cgroup 的 memory.usage_in_bytes 做限制，但是压缩在 zram 的匿名页面无法被限制，会造成计数器泄露的问题，pod 可能无限制的利用 node 上的 zram 资源，而 k8s 感知不到。
●无法隔离非内存多级卸载 pod 的换出行为：当对 node 节点开启 zram 的时候，虽然不对非内存多级卸载 pod 做主动回收，但在非内存多级卸载 pod 容器内存紧缺的情况下、或者整机内存紧缺的情况下，依然有可能把非内存多级卸载 pod 的匿名页面压缩到 zram 中，改变客户原本的预期行为。
01
整体架构
针对以上问题，我们提出了一个整体解决方案，分为5个模块及各自功能。
● wujing-umrd daemonset：
○qos-agent container：在 node 上，找到哪些 pod 打开了多级卸载，并且把 pod cgroup 和回收参数发送到 umrd ds。
○umrd container：umrd 根据 qos-agent 传递过来的回收列表进行主动回收，并且根据回收参数、PSI、refault、cpu util 计算回收文件页、匿名页的数量。
● mglru 增强模块：
○拆分接口：文件页面、匿名页面独立扫描、回收。
○Workingset Evaluation：评估有效文件页回写数量。
○new workingset refault feature：优化 mglru workingset。
● swap 隔离模块：system disable、cgroup disable，可以隔离来自节点内存紧缺和容器内存紧缺对非开启内存多级卸载的 pod 换出行为。
● zram 增强模块：per-cgroup zram priority、per-cgroup zram counter（raw、limit、usage）每个 cgroup 可以独立设置 zram 压缩等级，对于 per-cgroup 也做到了每个 cgroup 都能独立计算出压缩前和压缩后的量，以及现在 cgroup zram 的用量。
● 现网集群中部署热度探测模块：可以做匿名段热度探测，pod 中总内存的容器总匿名页、文件页面热度探测，计算各自占比，我们根据占比评估出 workload 哪个集群适合开启多级卸载。
02
子模块介绍
wujing-umrd ds
我们在集群中部署 wujing-umrd ds，集群中每个 node 都会被调度上一个 wujing-umrd pod，其中，wujing-umrd ds 包含一个 qos-agent container 和 umrd container。
● qos-agent container：当 node 上 pod 状态发生变化的时候，根据 pod yaml 打的 QOS 标签，对 pod 开启多级卸载，并且启用 QOS 标签对应的压缩等级和回收参数。
● umrd container：接受 qos-agent container 传递的回收路径和回收参数，并且根据 PSI、refault 负反馈决定当前回收的页面数量，将这些页面数量下给内核。
mglru 增强
在内核中，我们更换了 LRU 算法。原本是两级 mglru，我们 backpod 上游多级
● 精度提升：传统 LRU 仅使用两个 lru list（Active/Inactive）来区分页面热度。而 MGLRU 中将 LRU 分成了四个世代（Gen），每个世代中又分为 4 个层级（Tier）。表征页面精度的提升，意味着误回收“冷”页的可能性下降。
● mglru 拆分接口：
○将 mglru 文件页、匿名页的扫描和回收过程隔离，并且给出统一的用户接口。
○使用方式，例如：
对于访问频繁的匿名页面，可以 10s 扫描一次，5s 回收一次。
对于慢盘并且访问少的文件页，可以 20s 扫描一次，2s 回收一次，实现有针对性的回收。
● Workingset Evaluation：
○可以获取一个 Cgroup 过去 1分钟/10分钟/30分钟 内平均 Refault 距离，以及预估有效文件页回写数量。
● workingset refault 重构与优化：
○对 Linux 内核中传统 LRU 长期使用的 Workingset Refault Distance 算法进行了重新优化设计，并成功将其与 MGLRU 中的 Refault PID 算法结合。
○改进后的算法可以辅助不同场景下进行更加有效的页面平衡，并能更加有效地防止 Thrashing。新算法在一些应用场景中有着非常显著的性能提升（5% – 400%）。即使是在传统 LRU 场景下，新算法也有可见性能提升（1 – 5%）。部分改进已发至上游。
swap 隔离
在集群原本没有开启 swap，在使用多级卸载后，将会把集群的 swap 打开，对于非多级卸载 pod，在整机、容器内存紧缺的情况下，会将匿名页面换出到 swap 设备，这是业务非预期行为，得支持 swap 的隔离。
● 整机内存紧缺：在整机内存紧缺的情况下，内核内存子系统会从 root memcg 开始遍历 memcg，并且回收其 lruvec，由于可能会对非多级卸载的 pod 做回收。
● 容器内存紧缺：在容器内存紧缺的情况下，内核内存子系统会从当前 memcg 开始遍历 memcg，并且回收其 lruvec，如果当前 memcg 没有开启多级卸载，那么会导致业务的匿名页面换出到 swap 上。
接口与解决办法：
● 内核接口：vm.force_swappiness、memory.swappiness
● qos-agent：qos-agent 对开启多级卸载的集群，设置 vm.force_swappiness=1，强制在整机、容器内存紧缺的情况下，强制对 swappiness==0 的容器不回收匿名页面；并且，在 node 上 pod 状态发生变化的时候，对非多级卸载 pod 设置 swappiness=0，多级卸载 pod 设置 swappiness=60。
zram 增强
ZRAM Enhance 基于上游 Object Cgroup API 实现，每个 Cgroup 提供了：
● 独立更改 ZRAM 压缩级别：
/memory.zram.priority：每个 Cgroup 可以选择压缩等级 1 – 4，默认分别对应算法 lz4，lzo-rle，lz4hc，zstd，压缩率由高到低，性能损失由小增大，进而对不同敏感程度的 pod 用不同的压缩等级。
● 独立统计 ZRAM 压缩数据：
/memory.zram.raw_in_bytes：以 Byte 为单位的换出到 zram 压缩前的数据大小/memory.zram.usage_in_bytes：以 Byte 为单位的换出到 zram 压缩后的总数据大小
● 限制 ZRAM 压缩量
/memory.zram.limit_in_bytes：以 Byte 为单位，限制本 memcg 换出到 zram 的总数据大小，超出这个限制后，匿名页面将无法换出到 zram 设备。
同时，zram 压缩后的数据大小会计算到 memory.usage_in_bytes 上，方便 k8s 感知和限制。
三、在腾讯的落地效果目前内存多级卸载在腾讯在线容器平台、离线容器平台、混部容器平台都已成熟应用，覆盖业务包括：键值存储、文件存储、聊天图片存储、聊天消息存储、AI 平台、游戏 AI 训练、转码、数据库等。主要收益场景：超卖、降配、混部。
超卖场景
内存节省：提升单机的内存售卖率，降低内存存储的成本。相同数据量情况下，开启多级卸载，内存用量降低 35%。
延迟情况：请求延时基本没有波动。
开启多级卸载后内存量的变化
benchmark 的请求延迟没有波动
降配场景
内存节省：对 workload 开启多级内存卸载，稳定降低内存用量后，降低 workload 的配置，节省业务上云成本。
性能：降低业务 workload 86% 的 OOM 数量。
混部场景
内存节省：在混部集群中，节点内存接近打满，但 CPU 利用率还有空闲，此时内存资源成为混部瓶颈。对非内存敏感型 workload 开启多级卸载后，节省出额外的内存资源，调度更多的离线 pod。
性能：无影响（出现影响优先 kill 离线 pod）。
以上就是OpenCloudOS 内存多级卸载落地实践分享的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/14396.html
微信扫一扫 
支付宝扫一扫 
