云原生下，TencentOS“如意”内存QoS之“pagecache隔离”

见贤思齐

架构鹅结合TencentOS团队在混部方面的落地实战经验，重点推送了TencentOSServer大规模容器集群混部服务器QoS产品“如意”相关内容。TencentOS“如意”产品主要应用在离、在线混部场景，目标是为了提高服务器的资源利用率，进而降低业务及客户的服务器成本。“如意”作为一套OS侧的资源隔离方案，主要包括CPU、IO、内存和网络四大离模块。针对这四种服务器资源进行QoS（QualityofService，服务质量），能够将用户的在线、离线业务部署到同一台服务器上，既能保证在线业务的服务质量，又能有效提升资源利用率。针对“如意”特性中CPUQoS模块、网络资源隔离及IO隔离分别推出深度技术解析文章，本篇，架构鹅重点介绍如意内存隔离方案的应用和实践效果。1.内存隔离应用背景随着容器的大量使用，资源隔离的需求越来越强烈，每个容器的内存使用都会有一定的限额，不能超过这个限制。Linux的设计哲学是尽量充分利用系统内存。比如：将被访问过的硬盘数据加载到内存(pagecache)，PageCache以Page为单位，缓存文件内容。缓存在PageCache中的文件数据，能够更快的被用户读取。同时对于带buffer的写入操作，数据在写入到PageCache中即可立即返回，而不需等待数据被实际持久化到磁盘，进而提高了上层应用读写文件的整体性能。由于Linux的设计哲学，这个内存占用（pagecache）是没有限制的，即只要有空闲内存，就可以占用。但是这也带来一个问题，pagecache占用过多，导致系统内存不足时，会影响业务正常内存分配（内存不足时，内存分配要先回收，再分配），使得业务内存分配延时增大。因此，容器时代，限制pagecache的占用，有着非常重要的意义。2.解决方案2.1.社区解决方案那社区中针对这个问题有解决方案么？答案是有，而且很早就有了，看社区中的讨论：https://lwn.net/Articles/602424/这个patch是要限制pagecache，使得pagecache占用的内存保持在一定比例。这个patch在社区中讨论了很久，但是最终也没能进入社区，争论的主要焦点是：目前已有的回收逻辑是否已经足够？社区希望通过已有方式，比如提高内存low、min水位线使得kswapd尽早开始回收内存以及通过调节脏页回写比例来限制pagecache。通过memorycgroup来限制内存占用，但是这个只能限制总的内存占用，不能精确的控制pagecache的占用。而且在cgroupv2上，kernelmemory的限制功能已经被删掉，不能通过限制kernelmemory的方式来限制pagecache了。针对dentrycache的限制，社区中也有相应的实现：https://lkml.org/lkml/2018/7/12/586这个patch可以限制negativedentry的内存占比，记录、显示系统中negativedentry的功能已经合入到社区5.0版本中，限制功能则未能进入社区。至于未能进入的原因同样是不想把内核搞得更复杂，能否用已有功能实现。Redhat在RHEL7中加入了这个功能，但是在RHEL8中又删除了该功能，原因说是这个功能会导致系统崩溃，还说RHEL8中的upstream代码已经可以处理negativedentry，但是，社区中目前并没有针对negativedentry的限制。后面TencentOS“如意”会继续调研、完善这个功能，并将其合入，实现对negativedentry的限制，提高系统性能。接下来，我们重点看下pagecache的限制。虽然pagecachelimit的功能没能进入upstream，但是，有些厂商还是合入了pagecachelimit功能，比如SUSE：https://www.suse.com/support/kb/doc/?id=000019008TencentOS也加入了自己的全局pagecachelimit的实现。全局pagecachelimit使得pagecache的占用限制在一定比例，保证了系统空闲内存，降低内存分配延时，同时使得一些不能进入回收的场景（比如中断上下文）的内存分配得以成功。但是随着容器以及混部的流行，全局pagecache限制还能满足业务需求么？容器场景下，每个容器的可用内存都是有限的，超过这个限额就会发生OOM，这会严重的影响业务性能。而其中经常出现由于pagecache占用了大量内存，导致发生OOM的情况。因此限制cgroup内pagecache占用具有重要意义。2.2.“如意”内存QoS隔离方案TencentOS“如意”调研了限制容器pagecache占用的几种实现。下面我们分别看一下。2.2.1.方案1实现一个cgroup级别的dirty_background_ratio/dirty_ratio。首先看下第一个方案，目前系统中有一个全局的dirty_background_ratio和dirty_ratio来控制脏页的内存占比，当脏页比例高于dirty_background_ratio设定的值后，唤醒后台flush进程写回磁盘。但这是个全局的值，所有优先级的容器共享同一个值，如果实现cgroup级别的dirty_background_ratio/dirty_ratio，每个容器可以有自己的脏页回刷比例，超过这个比例就回刷，使得各自pagecache占用保持在一定比例。但是，这个功能会导致TencentOS“如意”的另一个特性IOQoS控制不准。另外，对于非脏页占用的pagecache，可能需要单独的统计。因此，我们暂时没有实现这个方案。2.2.2.方案2扩展TencentOS原有的全局pagecachelimit功能，使其支持cgroup级别的pagecache限制。目前TencentOS已经支持全局的pagecachelimit功能，进一步扩展使之支持基于cgroup级别的限制，看起来是个可行的方案。memorycgroup打开的情况下，cgroup内每一次内存申请/释放（包括用户空间申请的内存、内核空间申请的内存，pagecache，slab等等）都会被记录下来，我们为每个memorycgroup新增一个pagecounter来专门记录该cgroup内pagecache的占用，如果本次内存更新的类型为pagecache，则更新该pagecounter。非directIO模式下读写一个文件的时候，首先会到pagecache中查找，看看要读的内容是否已经在pagecache中了，即调用pagecache_get_page函数用来查找一个pagecache页，如果发现没有，就会新分配一页并且加入到pagecacheslot中，我们在此加入限制检查功能，检查当前分配的页所在的memorycgroup，如果其pagecache占用已经超过了限额，则先尝试回收，回收多少可以配置，回收成功后，进程就可以继续使用pagecache了，这样操作后，可以使得cgroup内pagecache占用的内存保持在一定范围内，不至于占用太多内存，影响业务内存分配性能：看到这里，有同学可能会问，那如果一直回收不回来怎么办？理论上来说，pagecache占用的内存都是可以回收的，如果万一回收不了，比如，多线程程序疯狂的读写文件，pagecache占用一直超额，那么我们还有终极处理方法：OOM，我们支持设置重试次数，如果这么多次的回收还是不能达到要求的话，就会OOM，因为这个程序可能出问题了。用户可以查看当前pagecache占用了多少内存：如果想一次清掉本cgroup的pagecache占用的内存，而不影响其它cgroup，该怎么做？有办法，执行一个本cgroup的pagecache清除操作即可：memory.pagecache.reclaim_ratio设置pagecache超额后，回收的比例，当该比例设置成100后，表示马上清除该cgroup的pagecache占用。我们同时加入了pagecache超过限额以及被OOM的统计计数，业务可以查看memorycgroup下的memory.events文件查看：我们新增了sysctl参数：vm.pagecache_limit_global来控制使用全局pagecache限制功能，还是基于cgroup的限制。同时支持原来的vm.pagecache_limit_ignore_dirty以及vm.pagecache_limit_ignore_slab来决定回收时是否回收脏页以及是否回收slab。该功能在cgroupv1和v2下都支持。3.pagecache限制效果没有限制的时候，pagecache的内存占用一直在增加，直到占满所有内存，pagecache限制后，可以看到，pagecache占用最后会达到一个稳定值。4.问题有的同学可能会说，这不是违反了Linux的设计哲学了么？没有充分利用内存。是的，用户需要自己权衡利弊，打开pagecache限制，可以预留一些内存给业务使用，不至于在分配内存的时候没有内存，而要先回收，增大了内存分配延时。但是，限制pagecache使用也会降低文件的读写效率。