背景
在云计算和容器化部署环境中，云原生容器化已成为行业标准，带来高效部署和成本控制优势的同时，也伴随新的挑战：
- 资源管理复杂：动态环境使传统排查方法难以应对。
- 透明度不足：容器引擎层不透明导致内存问题难以定位，如内存泄漏。
- 性能问题：高负载场景下内存占用高、抖动等问题影响系统稳定性。
- 传统方法局限：监控排查耗时低效，隐性问题难以发现，增加运维成本。
为提升云原生场景下的系统运维效率，龙蜥社区理事长单位阿里云推出一站式 OS 服务平台——阿里云操作系统控制台（以下简称“控制台”）。控制台旨在为用户提供便捷易用、高效、专业的操作系统生命周期管理的能力。致力于提供卓越的操作系统能力，提升操作系统的使用效率，并为用户带来全新的操作系统体验。目前，该控制台与龙蜥操作系统进行了深度集成，已支持 Anolis OS 7.9 和 Anolis OS 8.8，广大社区用户通过操作系统内存全景功能，可一键扫描诊断，快速定位和解决龙蜥操作系统中的问题，提升运维效率、降低成本，并显著提高系统稳定性。
业务痛点解析
隐式内存占用是指在业务运行过程中引起的系统内存消耗，这些消耗未直接统计或反馈到业务进程中。由于这种内存占用通常不会被业务及时检测到，因此容易被忽略，导致内存的过度消耗。这种现象在高负载环境和复杂系统中尤为显著，可能严重影响系统性能和稳定性。
痛点 1：文件缓存(filecache)高
filecache 用来提升文件访问性能，并且理论上可以在内存不足时被回收，但高 filecache 在生产环境中也引发了诸多问题：
- filecache 回收时，直接影响业务响应时间（RT），在高并发环境中，这种延时尤为显著，可能导致用户体验急剧下降。例如，在电商网站的高峰购物时段，filecache 的回收延时可能会引起用户购物和付款卡顿，直接影响用户体验。
- 在 Kubernetes（k8s）环境中，workingset 包含活跃的文件缓存，如果这些活跃缓存过高，会直接影响 k8s 的调度决策，导致容器无法被高效调度到合适的节点，从而影响应用的可用性和整体的资源利用率。在 Redis 缓存系统中，高 filecache 可能影响缓存查询速度，尤其在高并发读写操作时，容易出现性能瓶颈。
痛点 2：SReclaimable 高
SReclaimable 内存是操作系统为了实现自身功能而缓存的内核对象，虽然不计入应用内存，但应用的行为却影响 SReclaimable 的高低。在内存不足时，SReclaimable 内存虽然可以回收，但回收过程中的抖动会导致业务性能下降，尤其是在高负载情况下，这种抖动可能导致系统不稳定。例如在金融交易系统中，内存抖动可能导致交易处理延迟，影响交易速度和准确性。此外，高 SReclaimable 内存还可能掩盖实际的内存消耗，给运维监控带来困扰。
痛点 3：memory group 残留
cgroup 和 namespace 是支撑容器技术的关键组件。业务频繁的容器创建和销毁经常会引起 cgroup 残留，容易造成统计不准确和系统抖动。cgroup 泄漏不仅使得资源监控数据失真，还可能引发系统性能问题，甚至导致资源浪费和系统不可预测性。在大规模集群中，这类问题尤为突出，严重威胁集群的稳定运行。例如，在广告投放系统中，频繁创建和销毁大规模容器可能导致 cgroup 泄漏，引发系统抖动，从而影响广告投放精度和用户点击率。
痛点 4：内存不足，却找不到去哪儿了
内存不足时，通过 top 等常用指令通常无法准确定位内存消耗原因。这通常是由驱动（如 GPU/NIC 等）引起的内存消耗，但常见的可观测工具无法覆盖这类内存区域。例如，在AI模型训练过程中，GPU 内存消耗巨大，但监控工具可能无法显示具体的内存去向，只能监控到 free 不足，运维人员也难以判断问题原因。这不仅延长了问题排查时间，还可能导致故障蔓延，最终影响系统的稳定性和可靠性。
解决方案：用操作系统控制台诊断隐式内存
方案介绍
四种隐式场景中，最为常见的是文件缓存(filecache)占用高。我们以这个场景为例，详细介绍如何探索并成功解决业务痛点。
当文件缓存高时，我们最想知道的是 cache 是哪些进程读写哪些文件引起的？
从一个内存页解析出文件名，大致需要以下几个步骤，其中最为关键的是从 page 到 inode，以及从 inode 到文件名，这里就需要具备两个循环能力：
- 能够循环扫描系统全部的文件缓存页。
- 能够根据 inode 循环解析出对应文件名。
我们也调研分析了多种方案的优缺点：
| 方案 | 优点 | 缺点 |
| 驱动模块(ko) | 实现简单 | 侵入性强，存在宕机风险，且内核版本繁多，适配难度大 |
| eBPF | 无宕机风险，兼容性好 | 循环能力不足 |
| mincore 系统调用 | 基于系统调用 | 关闭的文件无法扫描 |
| kcore | 具备全量扫描能力 | CPU 消耗大 |
最终我们选择基于 kcore 来解析系统 filecache 对应的文件，但也需要解决几个问题：
1. kcore 读的是 raw 内存，没有数据结构信息。
2. kcore 需要遍历全量内存，在大内存系统下，CPU 消耗大，时间长。
3. 需要支持整机和容器级的文件缓存扫描。
方案实施
kcore 方案面临的问题，我们针对性地进行攻克，最终顺利实现文件缓存的解析：
- 结合 ebpf btf 文件中存储的数据结构大小和偏移量信息，实现 raw 内存解析能力。
- filecache 内存页是离散存在系统中的，所以我们利用采样，只要采中一个文件页，就能顺利解析出文件名和对应的缓存量。
- 内核导出了文件/proc/kpageflags和/proc/kpagecgroup用于判断页面属性和对应的 cgroup。
阿里云操作系统控制台介绍
操作系统控制台是阿里云最新推出的一站式运维管理平台，充分结合了阿里云在百万服务器运维领域的丰富经验。该控制台集成了监控、诊断、持续追踪、AI 可观测、集群健康度和 OS Copilot 等核心功能，专门应对云端高负载、宕机、网络延迟抖动、内存泄漏、OOM（内存溢出）、I/O 毛刺、I/O 流量过大及性能异常等各种复杂问题。操作系统控制台为用户提供全面的系统资源监控、问题分析和故障解决能力，旨在优化系统性能，显著提升运维效率和业务稳定性。
总体架构如下：
教育行业某客户通过控制台解决内存高问题
K8s 是一个开源的容器编排平台，主要用于自动化部署、扩展和管理容器化应用。它提供一个强大的、灵活的架构来支持大规模的应用服务，从而简化了应用的运维管理，企业在享受 K8s 在容器编排和部署所带来的便利时，同时也面临新的问题。
阿里云操作系统控制台PC端链接：https://alinux.console.aliyun.com/
案例 1. 通过操作系统控制台分析容器内存工作集高
Kubernetes 采用内存工作集(workingset)来监控和管理容器的内存使用，当容器内存使用量超过了设置的内存限制或者节点出现内存压力时，kubernetes 会根据 workingset 来决定是否驱逐或者杀死容器。
- 内存工作集计算公式：
Workingset = 匿名内存 + active_file。匿名内存一般是程序通过 new/malloc/mmap 方式分配，而 active_file 是进程读写文件引入，程序一般对这类内存使用存在不透明情况，经常容易出问题。
客户通过容器监控发现其 K8s 集群中某个 pod 的 Workingset 内存持续走高，无法进一步定位究竟是什么原因导致的 Workingset 内存使用高。
针对上述场景，先找到 Pod 所在的 ECS 节点，通过使用操作系统控制台使用内存全景分析诊断，选择目标 ECS 节点后，再选择目标 Pod，发起诊断，诊断结果如下：
具体的文件路径和占用缓存大小：
- 首先，诊断结论中直接给出了简明的分析结论 “容器 xxx 内存使用率过高，存在内存不足风险，容器 xxx 内存中文件缓存占用较大”。
- 其次，根据诊断建议的引导，通过查看容器文件缓存占用排序部分的表格，可以看到共享内存缓存占用最大的前 30 个文件，从该表格中可以看到，前两个容器内的日志文件（名称显示的是容器内文件在宿主机中的路径，容器内文件目录从/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/3604/fs/后开始）占用了接近 228MB 的文件缓存 。
根据上述分析过程，基本可以确定是客户业务程序主动在这个容器 /var/log 目录下创建并读写了日志文件产生的文件缓存。结合业务需要，可以采取以下方式避免 Pod 内 Workingset 内存过高导致 Pod 内存达到限制从而引发直接内存回收，造成业务进程阻塞，产生延时：
- 通过手动执行 echo 1 > /proc/sys/vm/drop_caches 来主动释放缓存。
- 如产生文件缓存的文件是非必要文件，可以通过手动删除文件释放缓存。
- 使用 ack 集群的内存 QoS 功能：https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/memory-qos-for-containers?spm=a2c4g.11186623.0.0.58fa162eSqDX9Q
案例 2. 通过操作系统控制台分析共享内存高
某行业客户发现，在运行较久的机器上，通过 free -h 看到的剩余内存较少，buff/cache 比较多，客户通过分析和查阅资料，通过执行 echo 3 > /proc/sys/vm/drop_caches 来主动释放缓存。客户发现，使用该方法可以回收部分缓存，但是仍然还有大量的 cache 占用没有释放：
针对上述场景，通过使用操作系统控制台对目标 ECS 进行内存全景分析诊断，诊断的结果如下：
- 首先，诊断结论中直接给出了简明的分析结论 “共享内存占用过多（34.35 GB），并且小文件居多，疑似存在共享内存泄露”。
- 其次，根据诊断建议的引导，通过查看共享内存缓存占用排序部分的表格，可以看到共享内存缓存占用最大的前 30 个文件，从该表格中可以看到，最大的前几个共享内存文件都只有 160KB，因此可以证明诊断结论中给出的系统中存在大量小的共享内存文件泄漏的论点。同时，通过文件名称这一列，可以看到这些小文件基本都是 /dev/shm/ganglia/* 这个目录下的。
根据上述分析过程，基本可以确定是客户业务程序主动在这个目录下创建了共享内存文件，并且没有及时释放导致的，结合业务的需求，可以评估是否存在泄露，删除泄露的共享内存文件即可释放占用的 cache 内存。
客户收益
通过控制台产品来解决业务中内存占用高的问题，客户可以获得以下收益：
- 提高资源利用率：通过准确监控和管理内存使用，能够有效避免内存浪费，提高整体资源利用率。
- 避免内存不足带来的性能抖动：通过及时发现和解决内存占用过高的问题，避免了内存不足可能导致的性能抖动，从而保证了业务的稳定运行。
- 简化故障排除过程：通过诊断工具提供的简明结论和建议，客户能够更快速地找到问题根源，缩短故障排除时间。
- 优化业务性能：通过管理和释放不必要的文件缓存，避免 Pod 内存达到限制从而引发直接内存回收，减少业务进程阻塞和延时。
总而言之，操作系统控制台给云计算和容器化运维带来新的可能，能够提高系统性能与运维效率，同时为企业减少了系统相关问题带来的困扰。
下一步规划，我们将继续演进控制台能力：
- 提升 AI 运维能力：结合 AI 大模型和小模型，提升对系统异常事件的预测与诊断能力，提供更智能的运维建议。
- 跨平台兼容性：优化操作系统控制台与更多云产品兼容性，以及更多的操作系统版本支持，使其能广泛地应用于不同的 IT 环境。
- 监控告警能力：开放更全面的操作系统监控指标，支持发现更多异常事件，并接入告警机制，帮助业务及时发现并解决潜在问题。
在下一期文章中，我们将分享更多实际案例，进一步深入探讨操作系统控制台在不同场景中的应用及其为客户带来的切实收益。敬请期待！
活动体验
欢迎大家参加操作系统控制台云产品评测活动。在 2 月 28 日前，按照要求深度体验控制台功能，最后提交评测报告，有机会获得奖励。欢迎大家体验大模型时代的操作系统服务。
活动链接：https://developer.aliyun.com/topic/osconsole
使用 OS 控制台的过程中，有任何疑问和建议，您可以扫描下方二维码或搜索群号：94405014449 加入钉钉群反馈，欢迎大家扫码加入交流。
OS控制台 钉钉交流群
—— 完 ——
