kmalloc-128 slab内存泄漏定位过程问题现象进展受阻现网排查分析coredump后记问题现象前几天，技术团队告知，线上几台ARM CentOS设备内存占用高，比其他相同设备占用高约200M。查看 free，meminfo和slabinfo后，怀疑是slab kmalloc-128存在内存泄漏。进展受阻我们发现正常设备和内存占用高设备的 kmalloc-128 占用已经超过177万，粗算下来200多M，刚好是多占用的内存大小。//异常设备的slabkmalloc-128

缘起公司部分项目在部署上通过keepalived实现了了双机热备，通过荣誉和接管，实现高可用性。最近其中一个项目出现了内存耗尽问题，使用<内存问题快速定位工具>定位提示是keepalived进程的rarp socket收报队列挤压了太多数据包导致。 该工具可以快速定位大多数内存问题，详细介绍文档见《内存泄漏定位思路和方法》，在此不再赘述。 分析keepalived我们用的是v2.0.10版本，...

docker使用cgroup memory导致的内存泄漏1. 问题现象及分析1.1 问题现象1.2 问题分析2. 解决办法和尝试2.1 升级到修复后的版本。2.2 禁用cgroup的kmem属性。3. 方案无效及分析3.1 确认内核是否支持该选项3.2 新的解决方案太长不看版本1. 问题现象及分析1.1 问题现象公司产品（centos 3.10.0-514）需要用频繁启动docker，每个docker的运行时间不固定，一段时间后设备内存不足。使用内存泄漏分析工具（传送门https://blog.cs

一年前我写过一个linux系统下内存泄漏问题定位方法的帖子《内存泄漏定位思路和方法》。这是我工作中总结出来的，帮助定位了很多项目内存泄漏问题。后来有同事反应，文章步骤较多，需要熟悉相关系统命令。项目上遇到问题后，再安装步骤逐步排查效率较低。询问是否可以做一个内存泄漏快速定位工具出来。于是我抽时间用shell将内存泄漏定位工具写了出来。在问题设备上进行了验证，可以准确提示泄漏位置。工具链接：内存泄漏快速定位工具该工具适合运维/技术支持/研发/测试等在工作中会遇到内存泄漏的相关人员。工具操作非常简单，直

线上设备出现了内存泄漏，查看相关信息，发现是隐性内存占用过高导致。查阅内存泄漏定位思路和方法，没有找到问题原因。查看线上内存历史统计，发现内存上涨很有规律，大概6天上涨到100%。然后因为内存不足，触发oom，杀掉工作进程后，内存可以下降下来。设备断网的几天内存没有上涨。只有联网时内存消耗才上涨，推断问题和网络数据包相关。杀掉工作进程后内存可以下降，推断内存被缓存在某个位置，进程重启后释放。因为杀掉工作进城后可以释放。所以问题缩小到工作进程以及工作进程拉起的几个相关进程上。挨个kill测试，发现ki

公司产品在重启服务时，log里有如下Call Trace。Jul 29 09:27:39 cpe kernel: [ 997.113469] =============================================================================Jul 29 09:27:39 cpe kernel: [ 997.113474] BUG slab_test (Tainted: G OE ------------ ): Objec

公司测试人员告知一台vrrp测试设备内存占用过高，有内存泄漏嫌疑。我将《内存泄漏定位思路和方法》发给他，让他参照分析，正好也验证下文档是否好用，是否需要改进优化。测试人员参照文档分析后，答复说应该是隐形内存占用过高。我登上去后，大概过了一遍，排除了应用程序内存占用，slab内存占用，vmalloc内存占用等相关可能，确实是隐形内存占用过高，看来我的文档还是挺好用的 ???? 。但是这次的隐形内存，...

本文主要针对基于Linux操作系统，提供了一种通用的内存泄漏定位分析思路和方法。1. 查看内存概况[root@VM_0_17_centos ~]# free total used free shared buff/cache availableMem: 1883844 376664 7...

这次问题源于线上设备发现内存使用过高，触发告警。技术支持报告后，登陆设备查看，发现系统内存占用（超过3.2G），导致可用内存只剩100多M。[root@ ~]# free total used free shared buff/cache availableMem: 3788284 3342156 ...