记录处理那次系统性能故障的过程

那次为了下载jprofiler7来测试系统的内存泄露点,还主动去开通了迅雷三个月的会员,虽然钱不多。因为那时候下载这个软件速度非常慢,才几K的速度,而这个软件却有70多兆,一冲动就花钱开了个会员,心想离线下载也许会快点,结果也没快多少,估计是国外服务器的问题吧。


后来终于下载完了,把软件传到现网的服务器上去又花了一部分时间,因为使用VPN来连接的,速度也不快。

传上去后,一开始以为能够直接不用重启weblogic,jprofiler能够直接attach到那个weblogic的进程,结果试了好久也不行,无奈只有在weblogic的启动参数中加了启动参数:

-agentpath:/home/xxxuser/xxxme/jprofiler7/bin/hpux-ia64w/libjprofilerti.so
直到那台服务器因没有足够的内存跑不动了,才叫pso来重启weblogic,8G的内存都用完了,这是什么内存泄露啊。后来发现系统一开始处理任务的速度越快,服务器也就会死的越快。


加上上面的启动命令后,就可以直接使用jprofiler连上weblogic的进程查看heap的使用情况,包括每个对象的数量及占用内存空间的大小。

观察了几次,就发现有几个关于Hibernate的对象数量特别多,而且是一直增长的。因我没用使用过Hibernate,对它的初始化产生的对象及日志没有足够的重视,当时还没有立即发现问题的所在。问了下身边有用过这个框架的同事,说可能是多次初始化了Hibernate的SessionFactory。

于是查找jpa使用Hibernate的地方,的确发现有一个地方工厂方法每被调用一次,就产生一个SessionFactory对象,原始的代码如下:

public static EntityManagerFactory getPlatformEntityManagerFactory() {
  EntityManagerFactory factory = Persistence.createEntityManagerFactory("xxxDS");
  return factory;
}

不知道当初那些人是怎么写的代码,也不考虑一下是否合适,就写上去了,结果排查这个问题实在是太费劲了,起初还以为是自己模块的问题。

结果因为这个问题导致了一系列的问题,管理有点混乱啊。

而我除了要处理本身模块的问题外,还要处理各种各样的问题,包括性能,功能以及接口调试,而我也只是一个普通的开发。

那时的我感觉真的好累,我是否有必要做这么多啊?

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值