月度归档： 2022 年 7 月

nr_dying_descendants 引发的在线业务性能抖动

Posted on by remaper in 内存管理

最近发现一则比较奇怪的业务性能抖动问题

简单来说，就是离线作业频繁的触发oom，导致在线业务指标陡增。理论上来说，离线作业触发自身硬限，不应该导致其他容器出问题才是

先来说一下我们的 memory cgroup 层级结构，可以简单理解为如下：

/cgroups/v2/kubepods/

/cgroups/v2/kubepods/online/a -> a为在线服务

/cgroups/v2/kubepods/offline/job1 -> job1 为离线服务

通常来说，为了解决混部的内存争抢问题，我们会对整个 offline 大框设置一个内存上限，防止离线作业使用内存太多，导致在线服务出现内存压力。这看起来似乎没什么问题。

不过最近一个问题，发现离线 job1 频繁 oom，引发了在线的性能抖动

最后定位的结论如下：

  1. /cgroups/v2/kubepods/offline/cgroup.stat 下看到有大量的 nr_dying_descendants
  2. offline 大框频繁出发 oom
  3. oom 的回收过程有个效率不太好的地方，导致 oom 回收效率底下 -> 导致内核各种锁争抢严重 -> 进程sys高 -> cpu排队严重 -> 在线业务性能抖动

根因分析：nr_dying_descendants 的原因是由于容器被销毁时，容器内还有未完全回收干净的 page cache，所以内核不会立即释放这个 cgroup（用户态操作系统从 /cgroups 文件系统下已经看不到了，但是内核态的数据结构还在）

cat /cgroups/v2/kubepods/online/cgroup.stat

nr_descendants 10

nr_dying_descendants 4172

这就有一个问题，如果有大量的dying cgroups，内核在oom处理过程中：

  1. 如果是cgroup oom，会优先尝试从 dying cgroups 回收内存，但是最多只回收5个 -> 这个地方有效率问题
  2. 如果是整机回收，不处理dying cgroups内存

 

TMO – Transparent Memory Offloading in Datacenters

Posted on by remaper in 混部技术
论文：https://www.pdl.cmu.edu/ftp/NVM/tmo_asplos22.pdf
内存是数据中心最大的瓶颈。百度也是如此，因为内存不足，导致大量机器cpu空闲但是利用率无法提升的主要原因
这篇论文的思路和 google 的 software-defined far memory 思路几乎是一样的，都是把 colder memory 卸载到 cheaper memory 上
google 论文是19年发表的，实际上项目2016年就已经上线了
facebook 论文是22年发表的，线上已经运行一年多。另外，论文里也隐约的提了，facebook就是在google的基础上做的，但是发现效果和 google 说的不一样，于是做了很多改进。如果我们要落地，也会有类似的问题。

1. INTRODUCTION

下文所有对比的地方，我简称：
  1. google的方案，g-swap
  2. facebook的方案，tmo
现状：
cpu的发展速度比memory要快
随着AI算法的发展，业务对内存的需求正在快速膨胀
硬件上，nvm和nvme ssd等技术的出现，Non-dram cheaper memory 开始越来越多的被使用
还有 CXL 这种 non-DDR memory bus 技术，可以接近 DDR 的原生性能
方向：内存分层技术，不管是 google 的 software-defined far memory 也有还是 facebook 的 TMO（透明内存卸载），本质上都是将低频访问的内存卸载到低速设备上
With memory tiering, less frequently accessed data is migrated to slower memory.
g-swap的一些问题：
  1. 核心是压缩
  2. 非常简单
    1. 好处：不用解决异构这些复杂的问题（感觉解决了？做了负载分类）
    2. 坏处：不利于最大化的 memory-cost saving
  3. promotion rate 的设定依赖离线分析
  4. 所有应用的 promotion rate 是一样的。没有考虑不同业务对内存的敏感性，以及不同分层设备的 performance（后者其实有简单的考虑，具体的 P% 的设备就取决于 far memory 到 near memory 的性能表现）
    1. g-swap的观点：为了保证应用程序的性能，memory offloading 应该控制在一个预先配置好的比例下面
    2. tmo的观点：facebook 对它们部署规模最大的程序，发现，在一些高速设备上，提高 memory offloading 比例，可以提高性能。 –> 反人类假设？？
0
为了解决这些问题，facebook 提出了 tmo 方案，优点：
  1. 核心是卸载（但是卸载的backend 支持 compressed memory pool，也支持 NVMe SSDs）
  2. 不需要离线分析，依赖 PSI 的反馈，直接单机决定不同的 offloading 比例。不依赖app的任何先验知识（g-swap的方案就有一个冷启动问题，新app默认不回收任何内存）
  3. PSI accounts for application’s sensitivity to memory-access slowdown（这里其实是比较误导的，facebook认为psi观测出来的内存延迟一定是对业务敏感的，但是实际上不同的业务对延迟的敏感性是不一样的，简单来说这个是充分不必要条件）
收益空间：20-32% 收益，百万服务器，其中7-19%由应用贡献，13%由sidecar等基础服务贡献