4个月前 (01-02)  jvm |   抢沙发  36 
文章评分 0 次,平均分 0.0
[收起] 文章目录

java堆外内存泄漏排查案例

我在Twitter的团队意外地建立了一个系统来检测激动人心的体育赛事:我们在三个不同的场合被寻呼,因为我们的一个服务在一个数据中心宕机。不用说,我们希望尽快取消这个系统的建设。我第一次被传呼是在西雅图海鹰队NFL季后赛的比赛中,在最后一分钟打成平手。我想其他的网页是由于NCAA篮球和板球世界杯。

这些事件导致大量用户同时发微博,发送流量大幅飙升。我们的服务最终使用了几GB的额外内存,并被Linux内核杀死。在一个实例被杀死后,其余实例的负载会增加,最终会将它们全部关闭。作为一个JVM服务,“额外”内存必须是native memory本机内存,而不仅仅是普通的Java对象分配,但是我们的服务没有对本机内存做任何特殊的处理。几周前,我们终于发现了潜在的Java本机内存泄漏。

始终关闭gziputstreamgziputstream,因为它们通过zlib使用本机内存。要追踪泄漏,请使用Jemalloc,并使用MALLOC_CONF环境变量启用采样分析。

与我之前提到的JVM mmap垃圾收集暂停类似,很多人花了很多时间调试这个问题,历时数月。每次我们被传呼时,我们都会设置额外的解决方法,以使将来更难触发。我们也花了更多的时间试图找到“真正的”错误,没有太多的成功。这个特殊的问题很容易重现:只需向一个测试实例发送许多并发请求。不幸的是,减慢实例的速度(例如使用strace)会使问题消失。既然我们的缓解措施似乎奏效了,我们就转向了更优先的问题。

几周前,有人报告了一个与我们类似的问题。kirandeeppaul建议使用jemalloc的内置分配配置文件,它跟踪调用malloc的内容。这是相对较低的成本,因为它只对malloc调用的一小部分进行采样。这也很容易尝试,因为可以通过设置MALLOC_CONF环境变量来打开它,而无需任何代码更改。这就成功了。

我的设置:

MALLOC_CONF=prof:true,lg_prof_interval:30,lg_prof_sample:17

它在每分配1 GB之后将配置文件写入磁盘,并每128 kB记录一次堆栈跟踪。可以使用jeprofjemalloc的一部分)将此文件转换为图形。这为我们的服务创建了下图。

java直接内存

这表明94%的“活动”块是由Java_Java_util_zip_deflatter_init和deflatInit2(zlib的一部分)分配的,而只有4%来自os::malloc和JVM本身。

我发现这个程序压缩任何东西都很奇怪,所以我向Carsten Varming(Twitter-NYC的本地JVM专家)提到了它。他以前在Twitter上见过Deflater导致内存问题。它使用本机zlib库,该库使用malloc分配一个小缓冲区。如果它没有关闭,那么直到终结器运行时内存才会被释放,这可以解释这些症状。

我们使用linux perf来查找压缩内容的代码。在Twitter上,我们将JVM和perf配置为跨本机代码和Java代码生成堆栈跟踪,因此我运行perf record-g-p(PID)来记录堆栈跟踪,同时生成重载(您可以使用perf map agent来实现这一点)。

然后,我使用perf report搜索引用Deflater的堆栈,这很快就显示了罪魁祸首:一个异常记录器在压缩消息时没有关闭GZIPOutputStream。这解释了为什么它只发生在重载期间:只有在垃圾收集之间发生大量异常时,内存使用才会增加,最终终结器将运行以清除本机分配。添加try/finally块来关闭流解决了这个问题,并在负载下稳定了服务的内存使用。

我花了几个小时在Twitter上审核GZIP流的所有用法,发现有几个地方忘记关闭流。我不认为它们中的任何一个会导致类似的内存泄漏,但我还是修复了它们,以避免将来的复制和粘贴错误。(我在Apache Spark中也发现了一个)我认为FindBugs会报告这些问题的警告,这显示了静态分析的潜在价值,特别是对于这种“已知危险”的情况。我希望有一个预提交检查器阻止人们提交没有调用close()的代码使用。

 

除特别注明外,本站所有文章均为老K的Java博客原创,转载请注明出处来自https://javakk.com/1172.html

关于

发表评论

表情 格式

暂无评论

登录

忘记密码 ?

切换登录

注册