公司当年有一个自己缓存集群用户session的Java library,是基于hazlcast2.0.3实现的,最近在customer site集群环境中某个blade报了Out of Memory Exception, 其他blades都正常,马上用jrockit jrcmd命令dump了堆和线程进行分析。
printf “##################### heap ##################\n”
su -p occas -c "/opt/jrockit-jdk/bin/jrcmd `ps -ewf | grep weblogic.Name=traffic | grep -v grep | awk '{print $2}'` heap_diagnostics "
printf “#####################threads ##################\n”su -p occas -c "/opt/jrockit-jdk/bin/jrcmd `ps -ewf | grep weblogic.Name=traffic | grep -v grep | awk '{print $2}'` print_threads"
用eclippse memory analyer打开dump回来的heap文件,打开Dominator Tree,发现hazelcast的ConcurrentMapManager吃掉了大部分的系统内存,其持有的CMap包含的java.util.concurrent.ConcurrenthashMap hashentry的数目无比巨大(近80w), 如图