Linux内存泄露案例分析和内存管理分享

一、问题

近期我们运维同事接到线上LB（负载均衡）服务内存报警，运维同事反馈说LB集群有部分机器的内存使用率超过80%，有的甚至超过90%，而且内存使用率还再不停的增长。接到内存报警的消息，让整个团队都比较紧张，我们团队负责的LB服务是零售、物流、科技等业务服务的流量入口，承接上万个服务的流量转发，一旦有故障影响业务服务比较多，必须马上着手解决内存暴涨的问题。目前只是内存报警，暂时不影响业务，先将内存使用率90%以上的LB服务下线，防止内存过高导致LB服务崩溃，影响业务，运维同事密切关注相关的内存报警的消息。

二、排查过程

经过开发同学通过cat /proc/meminfo查看Slab的内核内存可能有泄漏。

$ cat /proc/meminfo
MemTotal:       65922868 kB
MemFree:         9001452 kB
...
Slab:           39242216 kB
SReclaimable:   38506072 kB
SUnreclaim:       736144 kB
....

通过slabtop命令分析slab发现内核中dentry对象占比高，考虑到dentry对象跟文件有关，Linux中一切皆可以为文件，这个可能跟socket文件有关，通过进一步排查发现LB服务上有个curl发送的HTTPS探测脚本，这个脚本存在dentry对象泄漏，并且在curl论坛上找到一篇文章确认了这个问题，这个文章说明了curl-7.19.7版本在发送HTTPS请求时，curl依赖的NSS库存在dentry泄漏的bug，我查看一下我们curl版本就是7.19.7，问题终于真相大白了！！！

$ curl -V
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

$ rpm -aq|grep nss-
nss-util-3.16.1-3.el6.x86_64
nss-sysinit-3.16.1-14.el6.x86_64
nss-softokn-freebl-3.14.3-17.el6.x86_64
nss-softokn-3.14.3-17.el6.x86_64
nss-3.16.1-14.el6.x86_64
nss-tools-3.16.1-14.el6.x86_64

文章中介绍可以设置环境变量NSS_SDB_USE_CACHE修复这个bug，我们验证通过了这个解决方案。

三、解决方案

1、目前先将探测脚本停止，在业务流量低峰时将内存使用率超过90%的服务先通过drop_caches清理一下缓存。

2、等大促过后，探测脚本中设置环境变量NSS_SDB_USE_CACHE，彻底修复这个问题。

四、复盘和总结

这次内存暴涨的问题根本原因是curl-7.19.7依赖的NSS库存在dentry泄漏的bug导致的，探测脚本只是将这个问题暴露出来。这次问题由Linux内存泄漏引发的问题，因此以点带面再次系统学习一下Linux内存管理的知识非常有必要，对我们以后排查内存暴涨的问题非常有帮助。

1）Linux内存寻址

Linux内核主要通过虚拟内存管理进程的地址空间，内核进程和用户进程都只会分配虚拟内存，不会分配物理内存，通过内存寻址将虚拟内存与物理内存做映射。Linux内核中有三种地址，

a、逻辑地址，每个逻辑地址都由一段(segment)和偏移量(offset)组成，偏移量指明了从段开始的地方到实际地址之间的距离。

b、线性地址，又称虚拟地址，是一个32个无符号整数，32位机器内存高达4GB，通常用十六进制数字表示，Linux进程的内存一般说的都是这个内存。

c、物理地址，用于内存芯片级内存单元寻址。它们与从CPU的地址引脚发送到内存总线上的电信号对应。

Linux中的内存控制单元(MMU)通过一种称为分段单元(segmentation unit)的硬件电路把一个逻辑地址转换成线性地址，接着，第二个称为分页单元(paging unit)的硬件电路把线性地址转换成一个物理地址。