使用SysOM定位容器内存问题_容器服务 Kubernetes 版 ACK(ACK)-阿里云帮助中心

为解决因容器引擎层的不透明性而导致的故障排查困难问题，阿里云容器服务 Kubernetes 版 ACK（Container Service for Kubernetes）团队推出操作系统内核层的容器监控可观测能力，为您提供更可靠、透明的容器引擎层，助力您更顺利地进行容器化迁移。本文介绍如何使用SysOM定位容器内存问题。

前提条件

已创建ACK托管集群，并确保集群版本为1.18.8及以上。具体操作，请参见创建Kubernetes托管版集群、升级ACK集群。
已开启阿里云Prometheus监控。具体操作，请参见阿里云Prometheus监控。
已开启ack-sysom-monitor监控功能。具体操作，请参见开启ack-sysom-monitor监控功能。

ack-sysom-monitor监控功能费用说明

启用ack-sysom-monitor监控功能后，相关组件会自动将监控指标发送至阿里云Prometheus服务，这些指标将被视为自定义指标。使用自定义指标会引起额外的费用。

为避免产生额外的费用，建议在启用此功能前，仔细阅读阿里云Prometheus的计费概述，了解自定义指标的收费策略。费用将根据您的集群规模和应用数量等因素产生变动。您可以通过资源消耗统计功能，监控和管理您的资源使用情况。

场景描述

容器化已经成为许多企业构建IT架构的最佳实践，因为它能够带来降低成本、提高效率的优点，并提供更大的灵活性和可扩展性。

但容器化在一定程度上引入了容器引擎层的不透明性，带来OOM（Out of Memory）等问题。可能会导致内存占用过高，甚至超出容器的内存限制，从而触发OOM问题。

为解决以上问题，阿里云容器服务 Kubernetes 版 ACK（Container Service for Kubernetes）团队与阿里云GuestOS操作系统团队合作，为您提供操作系统内核层的容器监控可观测能力，制性，从而更好地管理和优化容器的内存使用，避免因内存黑洞问题引起的OOM问题。

容器内存组成

容器的内存由应用程序内存、内核内存和空闲内存组成。

内存大类	内存小类	说明
应用程序内存（Application Memory）	应用程序内存由以下几个部分组成：匿名内存（Anon）：没有关联到文件的内存，例如进程的堆、栈、数据段等。通过BRK和MMAP分配的堆内存。文件缓存（FileCache）：用于缓存读取和写入的文件数据。其中，最近多次使用的缓存称为ActiveFileCache，通常不容易被系统回收。缓冲区（Buffers）：用于存储块设备或文件系统元数据的内存。大页面（HugeTLB）：使用大页面（HugePages）技术分配的内存。	应用程序运行时所使用的内存。
内核内存（Kernel Memory）	内核内存由以下几个部分组成： Slab：用于管理内核对象缓存的内存池。 Vmalloc：用于分配大块虚拟内存空间的机制。 allocpage：用于分配本地内存的机制。其他（Others）：包括内核栈（KernelStack）、页表（PageTables）、保留内存（Reserve）等。	操作系统内核使用的内存。
空闲内存（Free Memory）	不涉及。	未被使用的可用内存。

实现原理

Kubernetes采用内存工作集（Workingset）来监控和管理容器的内存使用。当容器内存使用量超过了设置的内存限制或者节点出现内存压力时，Kubernetes会根据Workingset来决定是否驱逐或者杀死容器。通过SysOM监控来排查Pod Workingset高的问题，可以提供更全面、精确的内存监控和分析能力，帮助运维和开发人员快速定位和解决Workingset过高的问题，从而提高容器的性能和稳定性。

其中，内存工作集（Workingset）是指在一定时间范围内，容器实际正在使用的内存部分，即容器当前运行所需的内存。Workingset = InactiveAnon + ActiveAnon + ActiveFile。其中，InactiveAnon和ActiveAnon是程序匿名内存总大小，ActiveFile是应用程序活跃文件缓存的大小。

使用SysOM功能

基于阿里云SysOM提供的操作系统内核层Pod、Node维度监控大盘，您可以实时监控内存、网络、存储等的系统层指标。SysOM功能的详细指标信息，请参见SysOM内核层容器监控。

登录容器服务管理控制台，在左侧导航栏选择集群。
在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择运维管理 > Prometheus监控。
在Prometheus 监控页面，单击其他页签，然后单击ACK Sysom Pod Kernel Resource Monitor页签，查看监控大盘的Pod内存数据。
根据计算公式Workingset = InactiveAnon + ActiveAnon + ActiveFile，分析如何定位内存黑洞问题。
1. 在Pod内存分布区域，SysOM提供Pod维度的操作系统内核层内存的成分监控。根据Workingset计算公式，在圆饼图中比较inactive_anon、active_anon和active_file三种类型内存的大小，找到占比最大的内存类型。
  如下图所示，inactive_anon内存大小占比最大。
2. 在Pod Resource Analysis区域，通过Top工具快速定位集群中InactiveAnon内存消耗最大的Pod。
  如下图所示，arms-prom的内存消耗最大。
3. 在Pod内存详情区域，查看Pod的详细内存组成。通过Pod Cache（缓存内存）、InactiveFile（非活跃文件内存占用）、InactiveAnon（非活跃匿名内存占用）、Dirty Memory（系统脏内存占用）等不同内存成分的监控展示，发现常见的Pod内存黑洞问题。
在Pod File Cache区域，查看产生较大缓存内存的原因。
若Pod的内存缓存较大，可能导致Pod工作内存占用升高，这部分缓存的内存会成为Pod工作内存的黑洞，最终影响Pod所在的业务体验。
修复内存黑洞问题。
通过观测发现容器内存黑洞问题，即可通过ACK精细化调度功能进行闭环修复。具体操作，请参见容器内存QoS。