01背景
数字人程序运行在 K8s 集群中，核心渲染组件是 render-proxy-2d-meiyan（mfe-server），负责实时人像渲染。
存储差异：
- render-proxy-2d-meiyan 人像渲染引擎：使用本地存储（SSD），模型数据可快速加载。
- 云闪付等其他业务：使用分布式存储（Ceph 或其他网络存储），人像模型数据放在网络存储中。
02现状
K8s 集群中有节点会周期性挂掉。挂掉的节点与其他节点的不同之处：
- 跑着
render-proxy-2d-meiyan（mfe-server）程序，对存储性能要求高。 - 在本地可以看到数字人的模型相关数据。
挂掉之前的表现
- kubelet 的 CPU 利用率持续飙升：达到 700%~800%。
- mfe-server 的 CPU 利用率也会飙升。
- 系统的 Load Average 持续增长。
03问题分析与解决
1. 排查不可中断睡眠（D 状态）进程
通过 ps aux 没有发现任何不可中断睡眠（D 状态）的进程。
为了验证出现性能瓶颈的位置，使用 perf 抓取内核调用栈，并结合 FlameGraph 制作火焰图。
结论：发现一个 v 开头的函数调用存在性能问题（与磁盘 IO 相关）。但由于还未到完全响应不过来的地步，所以没有出现 D 状态的进程。
2. 为何 kubelet 的 CPU 利用率会飙升（K8s 1.20）
kubelet 负责三件事：
- 接收创建 Pod 的请求，负责创建 Pod。
- 定期将自己的节点状态信息上报给 apiserver — 上报信息包含文件系统的使用情况。上传数据做网络 IO 不会耗费 CPU，一定是采集时耗费了 CPU。
- 当节点资源压力达到预设阈值时，kubelet 会驱逐 Pod。
关键发现：K8s 1.20 中对文件系统使用情况的统计调用的是 du 命令，而 du 命令要耗费计算资源，尤其是在被统计的文件夹下文件大且多的场景。du 命令会长期停在原地，把 CPU 耗上去。
3. 为何 render-proxy-2d-meiyan 的 CPU 利用率会飙升
业务组件需要与研发一起核对，核对结果是该 Pod 内有一个 mfe-server 的容器负责做人像的渲染。对资源的要求：
- 默认 6 路人像：会消耗 GPU，也会消耗 CPU。每一路人像都会启动多线程，遇到 IO 瓶颈还会启动额外的线程任务。系统的 Load Average 会持续增长，压力变大导致机器整体运作速度变慢。
- 对磁盘性能有要求：数字人视频出图像慢。
优化方向：
- 依据现有资源使用情况进行限制：人像路数变少，每一路人像开启的线程数做限制。
04总结
- 存储换用本地存储，改用 SSD 固态硬盘。
- 对 render-proxy-2d-meiyan 的性能进行限制：人像路数变少，每一路人像开启的线程数做限制。
05未来的规划
K8s 新版本升级。升级后即使数据放在本地存储，kubelet 的文件系统统计方式也可能有所改进，减少 du 命令带来的 CPU 开销。