关于glibc:实战总结｜记一次-glibc-导致的堆外内存泄露
问题景象团队外围利用每次公布完之后，内存会逐渐占用，不重启或者重新部署就会导致整体内存占用率超过90%。 $$公布2天后的内存占用趋势$$ 摸索起因一堆内找到起因呈现这种问题，第一想到的就是集群中随便找一台机器，信手dump一下内存，看看是否有堆内存使用率过高的状况。 $$内存泄露$$ $$泄露对象占比$$ 发现 占比18.8% 问题解决是common-division这个包引入的 暂时性修复计划 以后加载俄罗斯(RU)国内地址库，改为一个小国家地址库 以色列(IL)以后业务应用场景在补发场景下会应用，增加打点日志，确保是否还有业务在应用该服务，没人在用的话，间接下掉（后发现，确还有业务在用呢 ）。完满解决问题，要的就是速度！！公布 ~~上线！！顺道记录下同一台机器的前后比照。 公布后短时间内有个内存增长实属失常，后续在做察看。公布第二天，棘手又dump一下同一台机器的内存 由原来的18.8%到4.07%的占比，升高了14%，牛皮！！ 傻了眼，内存又飙升到86%~~ 该死的迷之自信！！ $$公布后内存使用率$$ 摸索起因二没方法汇报了~~~然而问题还是要去看看为什么会占用这么大的内存空间的~ 查看过程内存应用 java 过程内存使用率 84.9%，RES 6.8G。查看堆内应用状况当期机器配置为 4Core 8G，堆最大5G，堆应用为有余3G左右。 应用arthas的dashboard/memory 命令查看以后内存应用状况： 以后堆内+非堆内存加起来，远有余以后RES的使用量。那么是什么中央在占用内存？？ 开始初步狐疑是『堆外内存泄露』开启NMT查看内存应用笔者是预发环境，正式环境开启需谨慎，本性能有5%-10%的性能损失！！！-XX:NativeMemoryTracking=detailjcmd pid VM.native_memory 如图有很多内存是Unknown(因为是预发开启，绝对占比仍是很高)。 概念NMT displays “committed” memory, not "resident" (which you get through the ps command). In other words, a memory page can be committed without considering as a resident (until it directly accessed).rssAnalyzer 内存剖析笔者没有应用，因为本性能与NMT作用相似，临时没有截图了~rssAnalyzer(外部工具)，能够通过oss在预发/线上下载。通过NMT查看内存应用，根本确认是堆外内存泄露。剩下的剖析过程就是确认是否堆外泄露，哪里在泄露。 堆外内存剖析查了一堆文档基本思路就是 ...