【银河麒麟操作系统真实案例分享】内存黑洞导致服务器卡死分析全过程

了解更多银河麒麟操作系统全新产品，请点击访问

麒麟软件产品专区：https://product.kylinos.cn

开发者专区：https://developer.kylinos.cn

文档中心：https://documentkylinos.cn

---

现象描述

机房显示器连接服务器后黑屏，重启服务器后，系统正常运行。

现象分析

sa日志分析

查看问题时间点前后的sa日志，发现在凌晨、，系统可用内存已降至0，memused为100G+，但cached只有1G，active+inactive也只有33.4G。

这样来看问题时间点服务器可以ping通但无法连接的原因为系统内存耗尽，free只剩下7G内存，在min_free_kbytes为6534528的情况下，考虑到DMA/DMA32区域的预留内存后，系统已无法为用户态进程分配内存，available因此显示为0。但同时我们发现一个异常的地方，问题时间点available为0主要是memused占据了大量内存，但系统的active+inactive之和与memused的对比却十分悬殊，有大量内存被使用却未被统计监控到。

为此我们翻看了前几天的sa日志监控情况，发现问题出现在28号下午。查看28号的sa日志，可以看到28号上午时系统内存使用十分平稳各项内存统计指标都没有较大变化，free和available也一直保持在60G以上。

但到了28号下午的15:00后情况发生了变化，可以看到从这时起系统的free和available不断减少，空闲内存减少说明内存被缓存、进程亦或是内核所使用，但我们观察cached、anonpg、slab、pgtbl等参数基本都没变化，同时used却又不断增加了。

系统可用内存free不断减少，used上升，但各项统计数据却显示各个内存监控指标没有发生变动，这一般就说我们所说的内存黑洞或者幽灵内存问题。

内存黑洞问题介绍

追踪Linux系统的内存使用一直是个难题，人们试着把能想到的各种内存消耗都加在一起，kernel text、kernel modules、buffer、cache、slab、page table、process RSS…等等，却总是与物理内存的大小对不上，这是因为Linux kernel并没有滴水不漏地统计所有的内存分配，kernel动态分配的内存中就有一部分没有计入/proc/meminfo中。

Kernel的动态内存分配通过以下几种接口：

1. alloc_pages/__get_free_page: 以页为单位分配
2. vmalloc: 以字节为单位分配虚拟地址连续的内存块
3. slab allocator：kmalloc以字节为单位分配物理地址连续的内存块，它是以slab为基础的，使用slab层的general caches — 大小为2^n，名称是kmalloc-32、kmalloc-64等（在老kernel上的名称是size-32、size-64等）。

通过slab层分配的内存会被精确统计，可以参见/proc/meminfo中的slab/SReclaimable/SUnreclaim；通过vmalloc分配的内存也有统计，参见/proc/meminfo中的VmallocUsed 和 /proc/vmallocinfo；而通过alloc_pages分配的内存不会自动统计，除非调用alloc_pages的内核模块或驱动程序主动进行统计，否则我们只能看到free memory减少了，但从/proc/meminfo中看不出它们具体用到哪里去了，这就是所谓的内存黑洞。

对于内存黑洞，由于我们无法直接统计它的占用情况，只能从meminfo的信息反推，通常我们围绕LRU进行统计：MemTotal = MemFree +【Slab+ VmallocUsed + PageTables + KernelStack + HardwareCorrupted + Bounce + X】+【Active + Inactive + Unevictable + (HugePages_Total * Hugepagesize)】，这里的X就是黑洞内存。

最后黑洞内存问题由于看不到具体申请者，通常只能根据经验来进行问题排查，目前主要的问题原因有：

1. 各类内核驱动、安全插件、硬件驱动等通过alloc_pages申请内存导致内存被占用却无法看到被谁使用。这类情况我们此前遇到过虚拟化环境的balloon驱动、hns3网卡驱动等。
2. socket或者pf_packet socket 收发包队列积压，大量内存被用于socket缓冲区数据包存储，导致系统内存被占用。

总结

通过查看收集的sosreport文件中各项日志文件，能够确定29号凌晨发生的服务器宕机问题是由于系统内存不足，无法为用户态进程分配内存导致。而引起内存不足的原因为从28号下午3点开始出现了异常内存黑洞占用。

由于当前机器没有部署相关内存监控内容，其内存黑洞问题难以在后续环境排查，无法分析造成该问题的原因。建议排查28号下午在问题机器上进行的相关操作，并在之后部署相关内存监控脚本，同时对服务器available内存值进行监控，当发现有available内存值连续降低时及时查看机器状态。

后续机器又多次出现异常宕机，但vmcore要不没有生成，要不生成的无内容。结合上述问题怀疑是硬件存在问题，硬件上面检查发现主板供电存在问题，硬件日志中出现低电压报警。