内存全景分析功能适用于内存占用较高但无法明确识别具体内存占用情况的场景。通过使用内存全景分析诊断功能，可以扫描当前系统的内存占用状态，详细拆解内存使用情况。生成的报告将以饼状图的形式呈现系统内存与应用内存的分布，并列出当前Top 30的应用内存使用、文件缓存、共享内存缓存占用情况的排序。本文介绍了内存全景分析功能的使用说明。
使用限制
地域限制
本功能目前仅支持中国内地与中国香港。
操作系统限制
架构
操作系统
x86架构
Alibaba Cloud Linux 2/3
CentOS 7.6及以上版本
Anolis 8.4以上版本
ARM架构
Alibaba Cloud Linux 3
前提条件
如果您使用RAM用户，请确保阿里云账号（主账号）已将系统策略
AliyunECSReadOnlyAccess和AliyunSysomFullAccess授予RAM用户。具体操作，请参见为RAM用户授权。已开通控制台权限。
首次登录操作系统控制台时，单击开通服务以开通控制台服务。
操作步骤
诊断报告
基础信息
基础信息部分包含单次诊断的基本信息，包括诊断实例ID（资源ID）、诊断项、诊断报告ID及诊断发起时间。
诊断结论
若诊断到内存使用异常，将会把异常信息显示在本章节。
诊断建议
如果当前系统的内存使用异常，会给出进一步排查问题的建议。
诊断详情
内存占用分析
通过三个饼状图展示了内存使用分布、内核态内存使用分布和用户态内存使用分布。
应用内存使用排序
列出当前系统占用内存最多的30个任务，包含任务名称、内存总用量、用户态内存用量（Anon）和文件内存用量（File）。
文件缓存占用排序
列出当前系统文件缓存占用最多的30个文件，包含文件的名称、文件被缓存大小（Cached）、文件关联的任务（若当前文件有关联任务则列出，没有则显示为空）。
共享内存缓存占用排序
列出当前系统共享内存缓存占用最多的30个文件。包含文件的名称、文件被缓存大小（Cached）、共享内存类型以及文件关联的任务（若当前文件有关联任务则列出，没有则显示为空）。
实践案例
容器化在现阶段已成为构建企业IT架构的最佳实践。云原生容器化部署架构已成为兼具高效运维及成本控制的行业标准。容器化屏蔽了IDC基础设施和云资源，但同时也带来了容器引擎层的不透明性，常常出现内存黑洞、内存占用高、内存泄漏、抖动延时和cgroup泄露等问题。通过使用内存全景分析，可以使系统内存变得可维护、可测试和可追踪，从而将系统及容器内的缓存和共享内存归属到具体的文件名。
Kubernetes环境中容器Working Set较高的问题
Kubernetes采用内存工作集（Working Set）对容器的内存使用进行监控和管理。当容器的内存使用量超过设定的内存限制或节点出现内存压力时，Kubernetes将依据工作集的情况决定是否驱逐或终止相应的容器。
Working Set = 匿名内存 + active_file
匿名内存通常是通过new、malloc或mmap等方式进行分配，而active_file则是由进程在读写文件时引入的。程序对于这类内存的使用往往存在不透明的情况，容易发生问题。
问题现象
容器监控系统发现其Kubernetes集群中某个Pod的工作集内存持续增加，但应用所使用的内存并未显著上升，因此无法准确定位导致工作集内存使用增加的具体原因。
诊断分析
针对上述场景，使用Alibaba Cloud Linux控制台内存全景分析功能诊断Pod所在的ECS节点，诊断结果如下图所示。
根据诊断建议，可以确定问题源于业务程序在容器的/var/log目录下创建并读写日志文件，从而产生了文件缓存。由于Pod内的工作集（Workingset）内存过高，导致Pod的内存达到限制，进而触发了直接内存回收，造成了业务进程的阻塞。
解决方案
根据诊断结论，可通过以下方式解决内存过高的问题。
执行以下命令来主动释放缓存。
sudo sh -c 'echo 1 > /proc/sys/vm/drop_caches'如果缓存文件不是必需的，可以手动删除以释放缓存空间。
使用ack集群的内存QoS功能，具体操作，请参见启用容器内存QoS。
共享内存较高的问题
问题现象
用户在运行时间较长的机器上执行free -h命令时剩余内存较少，buff/cache占用较多，执行sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'命令主动释放内存。使用该方法可以回收部分缓存，但仍有大量的cache占用没有释放。
诊断分析
针对上述场景，使用Alibaba Cloud Linux控制台内存全景分析功能诊断目标ECS实例，诊断结果如下图所示。
诊断结论给出了简明的分析结论。
根据诊断建议的引导，通过查看共享内存缓存占用排序可以看到共享内存缓存占用最大的前30个文件，且前几个共享内存的文件只有160 KB，因此可以证明诊断结论中给出的系统中存在大量小的共享内存文件的泄露点。
解决方案
根据上述分析过程，可以确认用户在该目录下创建了共享内存文件，且未及时释放所致。结合实际业务需求，需要评估是否存在内存泄漏，并对泄漏的共享内存文件进行删除，以释放占用的内存。