linux内存泄露案例(linux内存占用怎么看top)

---

一、cgroup内存泄露问题排查记录发生内存泄漏的主机是集群机器。已经运行5天左右，内存使用率超过90%。其上运行集群管理软件和docker，并运行测试脚本反复启停。容器。
长时间运行后，集群主机的内存占用逐渐增加，出现应用程序OOM现象。
验证时发现主机总内存使用率较高，但应用程序实际内存使用率较低或未发现明显异常。
可以看到内存使用率为83.6%，而顶部显示的实际内存使用率最多只有0.6%。没有应用程序占用太多内存。
内存占用除了用户应用占用之外，还包括内核占用，所以要检查内核内存占用情况。
使用Linux文件系统界面查看
可以看到占用率极高的项被slab内核占用了：
继续查看详细的内核占用情况，按照按缓存大小排序
可以在这里看到：
kmalloc-2048,kmalloc-4096,kernfs_node_cache,kmalloc-1024,kmalloc-192,kmalloc-512都占用较大的面积。高与正常主机相比，已经严重超出正常值。
如果内核缓存过高，可以尝试释放内核缓存：
但是，做了上述操作后，使用内存仍然没有明显减少，这就是也和上面看到的SUnreclaim一致：2447108KB//面板的不可回收内存大小。该内存无法释放。
kmalloc是内核分配的内存。参考价值是kernfs_node_cache占用率高，所以研究了这一项的功能。
显然，这个现象是内核使用严重超标，所以我在搜索时添加了关键字memoryleak，很快就发现了问题Issuesdocker-run--memoryslabcacheleakoncentos7
这个问题表明：centos7重复运行dockerrun--rm--memory1ghello-world时，内核内存使用量大幅增加，无法释放。而且这个现象和现在的现象是一致。
最终这指向kernelcgroup内部内存泄漏问题，slableakcausingacrashwhenusingkmemcontrolgroup
一般原因是如果在kernel3.10上使用kmemlimit设置，回收cgroup时无法释放部分分配的内存。。至于更深入的了解，首先要解决当前的问题，还需要时间。
原因可能已经确定。为了再次确定这个问题，如果能够通过上面的方法解决的话，就可以确定确实是这个问题。
在仅运行Docker的机器上运行上述指令并检查磁贴的内存使用情况。可以看到内存使用量显着增加。并且最终的表现与现有环境的问题是一致的。总内存使用率高，用户态内存使用率低，内核内存使用率高且无法释放。
由于这是一个内核问题，并且已知明确的递归路径，因此可以通过两种方式解决：
最终，经过测试，我选择更改内核版本，Ubuntu18.04将作为新的操作系统。
Linux内核采用分层内存管理方法。每层解决不同的问题，从下到上，如下：
Slab是Linux操作系统的一种。系统。内存分配机制。它的工作是针对某些经常分配和释放的对象，例如进程句柄。这些物体的尺寸一般都比较小。如果直接用伙伴系统来分配和释放，不仅会造成很多内部问题。碎片化，而且处理速度也会太慢。lab分配器是基于对象来管理的。相同类型的对象被分为一个类别（如进程描述符）。每当请求这样的对象时，slab分配器就会从slab列表中分配该大小的对象。关闭，当需要释放它时，它会被保存回此列表，而不是直接发送回合作伙伴系统，从而避免这些内部碎片。lab分配器不会删除分配的对象，而是释放它们并将它们存储在内存中。以后请求新对象时，可以直接从内存中获取，无需重复初始化。
Slab占用内存过高。Slab可以手动释放可回收缓存。其工作原理如下：
drop_caches的四个值都有值。含义如下：

---

二、top怎么查看内存泄露linux检查进程的内存使用情况
按M后按Top-C
这会将内存使用情况从大到小排序
如果内存使用量只有1或2GB或在设置范围内范围是的，一般是没有记忆的。