专栏名称: 阿里开发者
阿里巴巴官方技术号,关于阿里的技术创新均将呈现于此
目录
相关文章推荐
阿里开发者  ·  如何监控vLLM等大模型推理性能? ·  2 天前  
百度智能云  ·  两连发!文心大模型4.5及X1,上线千帆! ·  4 天前  
阿里开发者  ·  阿里云资深架构师经验分享——DevSecOp ... ·  2 天前  
51好读  ›  专栏  ›  阿里开发者

如何解决隐式内存占用难题?

阿里开发者  · 公众号  · 科技公司  · 2025-03-18 18:00

主要观点总结

文章详细介绍了在云原生和容器化部署环境中,内存管理和性能优化所面临的挑战及相应的解决方案,主要介绍了隐式内存占用及其痛点,包括文件缓存高、SReclaimable高、memory group残留和驱动内存消耗等问题。同时,文章还介绍了操作系统控制台的功能和优势,以及如何通过操作系统控制台解决业务中的内存占用高的问题。

关键观点总结

关键观点1: 隐式内存占用的挑战

介绍了隐式内存占用的概念和在高负载环境和复杂系统中的挑战,如文件缓存、SReclaimable内存等问题,以及这些问题对系统性能和稳定性的影响。

关键观点2: 操作系统控制台的功能和优势

详细说明了操作系统控制台的一站式运维管理平台的特点,包括监控、诊断、持续追踪、AI可观测等核心功能,并介绍了其应对云端高负载、内存泄漏等问题的能力。

关键观点3: 文件缓存高的解决方案

以文件缓存高为例,介绍了如何通过操作系统控制台探索并解决业务痛点,包括使用kcore方案解析系统filecache对应的文件,解决kcore面临的问题等。

关键观点4: 操作系统控制台的应用实例

通过两个实例展示了操作系统控制台在K8s中的实际应用,包括通过内存全景分析诊断定位文件缓存占用高和共享内存泄露等问题。

关键观点5: 下一步规划

介绍了操作系统控制台的未来发展规划,包括提升AI运维能力、跨平台兼容性、监控告警能力等。


正文

阿里妹导读


本文详细介绍了在云原生和容器化部署环境中,内存管理和性能优化所面临的挑战及相应的解决方案。


什么是 隐式内存占用

隐式内存占用 是指在业务运行过程中引起的系统内存消耗,这些消耗未直接统计或反馈到业务进程中。由于这种内存占用通常不会被业务及时检测到,因此容易被忽略,导致内存的过度消耗。这种现象在高负载环境和复杂系统中尤为显著,可能严重影响系统性能和稳定性。


痛点一:文件缓存(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 不足,运维人员也难以判断问题原因。这不仅延长了问题排查时间,还可能导致故障蔓延,最终影响系统的稳定性和可靠性。

解决方案:用操作系统控制台诊断隐式内存


操作系统控制台

操作系统控制台是阿里云操作系统团队最新推出的一站式运维管理平台,充分结合了阿里云在百万服务器运维领域的丰富经验。该控制台集成了监控、诊断、持续追踪、AI 可观测、集群健康度和 OS Copilot 等核心功能,专门应对云端高负载、宕机、网络延迟抖动、内存泄漏、OOM(内存溢出)、I/O 毛刺、I/O 流量过大及性能异常等各种复杂问题。操作系统控制台为用户提供全面的系统资源监控、问题分析和故障解决能力,旨在优化系统性能,显著提升运维效率和业务稳定性。


控制 台地址:https://alinux.console.aliyun.com/


总体架构如下:


方案介绍

上述四种场景中,最为常见的是文件缓存(filecache)占用高。我们以这个场景为例,详细介绍操作系统控制台如何探索并成功解决业务痛点。

从一个内存页解析出文件名,大致需要以下几个步骤,其中最为关键的是从 page 到 inode,以及从 inode 到文件名,这里就需要具备两个循环能力:

  1. 能够循环扫描系统全部的文件缓存页。

  2. 能够根据 inode 循环解析出对应文件名。

我们也调研分析了多种方案的优缺点:

最终,操作系统控制台选择 基于 kcore 来解析系统 filecache 对应的文件 ,但也需要解决几个问题:
  1. kcore 读的是 raw 内存,没有数据结构信息。

  2. kcore 需要遍历全量内存,在大内存系统下,CPU 消耗大,时间长。

  3. 需要支持整机和容器级的文件缓存扫描。







请到「今天看啥」查看全文