性能文章>实战:一次疑似内存泄漏的问题排查>

实战:一次疑似内存泄漏的问题排查原创

8761314

问题背景

最近服务器到期等因素,进行了迁移。租了其它的外国厂商,但是由于资费问题,购买了1.5G 内存的服务器(现)。因为原本用惯了4G内存的服务器(原),现在压缩成这样,似乎不太能支持我的使用,囧!

现在就来说下blog服务分配的内存情况:

:4G 内存,分配给blog,1.5G。

:1.5G内存,分配给blog,500M。

由于此次调整,原本以为资源需求压力会更大。实际上应该不会,仔细想想,blog也没多少内容的。那么根据此次调整之后,已经出现了2次OutOfMemoryError了。

由于JVM参数配置有加上-XX:+HeapDumpOnOutOfMemoryError,所以出现OutOfMemoryError时会将堆栈输出到指定的文件,这样可以方便以后排查问题。

OS:CentOS7
Web容器:Tomcat 8
ORM:Hibernate3
数据库:MySQL5

问题解决过程

诊断排查出现内存泄漏对象

image.png

这个文件占用了差不多535M,说明里面的对象占用空间很大。这里我使用了MAT工具来排查。

image.png

1)Histogram (可以查看每个类的实例(即对象)的数量和大小)

image.png

通过Histogram图,我们初步看出,实际上跟我们自己的代码好像是没有关系,因为这里没找到我们对应的包名和类名。不过可以看到一些疑惑就是Tomcat和mysql相关的类占用了很大内存。

2)Dominator Tree(列出Heap Dump中处于活跃状态中的最大的几个对象,默认按 retained size进行排序)

image.png

从这里可以更加明确是哪些对象占用了大部分资源了,似乎也是跟Tomcat和mysql有关。

3)Top Consumer(按类、类加载器和包分别进行查询,并以饼图的方式列出最大的几个对象)

image.png

通过上面这个饼图,我们更加明确的是哪些对象占用了大部分资源。其它一些视图这里就不展开了。

小结:上面MAT的各种视图表明,并不是说占用资源大的对象是就是内存泄漏的罪魁祸首,它这里只是做了个统计,方便你观察和发现问题,只是提示你可能这些对象存在泄漏的可能性。

诊断排查占用大资源内因

由上面的图中,我从TaskThread这个类入手:

image.png

发现主要占用的资源在StatefulPersistenceContext这个类,很明显这个是Hibernate持久化相关的。

image.png

查看下类的注释,大致意思是:

PersistenceContext表示Hibernate正在跟踪的持久化“内容”的状态。这包括持久实体、集合以及生成的代理。

SessionImpl和PersistentContext之间应该是一对一的对应关系。SessionImpl使用PersistentContext来跟踪其上下文的当前状态。事件监听器使用PersistentContext来执行处理。

因为Hibernate的一级缓存就是在Session层面上,所以StatefulPersistenceContext跟一级缓存有关系,网上有些资料也有说StatefulPersistenceContext存在问题可能造成内存泄漏等原因。

可以在使用完Session时进行clear清除。这样就能防止占用过大资源,但是,使用一级缓存是能够大大的增强性能,如果这么做的话,似乎有违背Hibernate的设计初衷,因此,这里我们不能采取这种做法。

继续往下挖,看这里面存放的是具体什么对象吧!

image.png

从这里可以看出,持久化的主要对象实体是ShareArticle,并且有1706个实体之多!~,这里只是TaskThread这个线程所持有这么多的实体,要知道下面还有几个大对象TaskThread,里面也是有包含这些的,所以不仅仅1千个多实体。

找出问题根源(“真凶”)

image.png

看到这个实体的每个字段,才知道问题出现在哪!这张表有一个content字段,类型是mediumtext,存放文章内容。所以一旦加载到内存里,自然的需要占用大部分资源了。

找到问题的点在哪了,接下来就得看怎么优化,毕竟在资源急缺的我,需要优化下当前的服务了。

解决问题,优化!优化!

优化之一:查询不返回content字段

特别是哪些查询列表相关的。这能大大的减少占用内存。因为有些查询List结果实际上是没有使用到content字段,再次查询出来也是一种浪费。

说下这个过程吧,由于使用的是Hibernate,虽说有其优点,但是使用起来极其不灵活!在公司用惯了Mybatis,才知道Mybatis的好,哈哈!

优化之二:只查询需要的字段

在查询当前文章的上下文时,基本上也是不用用到content字段,这里只需要返回id和title,即可。其实跟上面2.4.1的类似。

优化之三:延迟加载指定字段

我们知道,Hibernate在一对多、多对多等关系中,是支持延迟加载的。查资料发现Hibernate3也能支持指定字段进行延迟加载,在需要的时候再次去查询数据库指定的字段再返回。

所以就动手干!但是也遇到使用时出现不生效,资料表明需要再次使用字节码进行增强才能正常使用。

小结:经过上面的优化,服务再也不会出现OutOfMemeryError了,而且资源占用也大幅度降低。

总结(经验与优化)

1)针对占用资源多的,是否能够不存在数据库,比如生成静态HTML文件,访问的时候直接包含在页面直接返回,这样能快速返回,占用内存少,提升性能。

2)针对大字段(占用资源大),没用到时不返回。

3)只返回需要的字段,在SQL优化的上必有,这样也能提升mysql的吞吐量,也不会浪费资源。

4)如果追求灵活性,ORM建议使用mybatis,毕竟互联网公司基本用它。Hibernate更适合在企业系统里面使用。

5)如果已经使用了Hibernate了,可以增加字段延迟加载机制,进而在需要的时候再去查询。

本文来自:搬运工来架构 公众号,作者:cocodroid。

点赞收藏
Java小能手
请先登录,查看3条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

日常Bug排查-集群逐步失去响应

日常Bug排查-集群逐步失去响应

浅析AbstractQueuedSynchronizer

浅析AbstractQueuedSynchronizer

14
3