JVM调优案例分析与实战(2):集群间同步导致的内存溢出

环境:一个基于B/S的MIS系统,硬件为两台2个CPU、8GB内存的HP小型机,服务器是WebLogic 9.2,每台机器启动了3个WebLogic实例,构成一个6个节点的亲合式集群。

说明:由于是亲合式集群,节点间没有进行Session同步,但是有一些需求要实现部分数据在各个节点间共享。开始这些数据存放在数据库中,但是由于读写频繁竞争很激烈,对性能影响较大,后面使用JBossCache构建了一个全局缓存。

        全局缓存启用后,服务正常使用了较长一段时间。

问题:最近不定期地多次出现内存溢出问题。

分析:在不出现内存溢出异常的时候,服务内存回收状况一直正常,每次内存回收后都能恢复到一个稳定的可用空间,开始怀疑是程序的某些不常用的代码路径中存在内存泄漏,但是管理员反映最近程序并未更新或升级过,也没有进行什么

        特别操作。只好让服务带着-XX:+HeapDumpOnOutOfMemoryError参数运行了一段时间。在最近一次溢出之后,管理员发回了heapdump文件发现里面存在着大量的org.jgroups.protocols.pbcast.NAKACK对象。

        JBossCache是基于自己的JGroups进行集群间的数据通信,JGroups使用协议栈的方式来实现收发数据包的各种所需特性的*组合,数据包接收和发送时要经过每层协议栈的up()和down()方法,其中的NAKACK栈用于保障各个包

        的有效顺序及重发。

        由于信息有传输失败需要重发的可能性,在确认所有注册的GMS(GroupMembership Service)的节点都收到正确的信息前,发送的信息必须在内存中保留。此MIS的服务端中有一个负责安全校验的全局Filter,每当接收请求时,均会更新

        一次最后的操作时间,并且将这个时间同步到所有节点中,使得一个用户在一段时间内不能在多台机器上登录。在服务器使用过程中,往往一个页面会产生数次乃至数十次的请求,因此这个过滤器导致集群各个节点之间的网络交互非常频繁。

        当网络情况不能满足传输要求时,重发数据在内存中不断地积累,很快就产生了内存溢出。

        这个案例中的问题,既有JBossCache的缺陷,也有MIS系统实现方式上的缺陷。JBossCache官方的mailist中讨论过很多次类似的内存溢出异常问题,据说后续版本有了改进。而更重要的缺陷是这一类被集群共享的数据如果要使用类似JBossCache

       这种集群缓存来同步的话,可以允许读操作频繁,因为数据在本地内存有一份副本,读取的动作不会耗费多少资源,但不应当有过于频繁的写操作,这会带来很大的网络同步的开销。

JVM调优案例分析与实战(2):集群间同步导致的内存溢出

上一篇:幸福


下一篇:利用正则表达式找出文件里的所有邮件地址