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