记一次内存告警
个人博客原文:
记一次内存告警
今天给大家分享一次生产上遇到的内存问题。
生产上的一个应用经常运行一段时间后就内存告警,在一次告警中,先 dump 了内存下来,然后再重启了应用。
dump 命令:
jmap -dump:format=b,file=memory.pro {pid}
用 VisualVM 打开文件,看了一下,发现占用很高的是 java.nio.ByteBuffer[],点击多层引用进去发现是 HBase 连接,看起来很明显,大概知道是什么问题了,有 6 万多个连接对象,肯定是连接未释放导致的。
内存到底是什么导致连接未释放? 看了公司内部封装的框架代码,操作 HBase 有使用 HTablePool,配置了队列数是 10,这就奇了怪了。为啥连接数还那么高?
只能通过 HBase 源代码来看个究竟,直到看了 HBase 的 HTablePool#getTable(),取出为空的话还会自动创建 HTable,说明配置队列数不是固定死的,还会自动创建的。当 HBase 操作慢的时候,存 HTable 的队列很容易就为空了,这个时候会额外创建 HTable,这时候怀疑额外创建的 HTable 没有释放资源,再继续看代码。
getTable既然可以无限创建 HTable,那就得关注下存 HTable 到队列的代码了。看了 HTablePool#putTable() 代码发现,只是简单判断了队列没满,就把 HTable 放到队列,多余的 HTable 竟然啥都没处理,就这样堆积在内存中。
putTable看了 HBase 版本,是可怜的 0.89 古老版,在新的版本这个问题都不存在了,下面是 0.98 版本,已经解决了这个问题,把多余的 HTable 回收了。
putTable这个坑也是公司一直没升级 HBase 导致的。所以要跟得上开源的脚步,尽量用高的版本的开源框架。在没升级 HBase 的时候,只能根据业务,把 HTablePool 队列配置配高些,才会减少自动创建的 HTable。
公众号