<b>Java EE操纵程序在Glassfish上的性能调优案例解析</b>[Java编程]
本文“<b>Java EE操纵程序在Glassfish上的性能调优案例解析</b>[Java编程]”是由七道奇为您精心收集,来源于网络转载,文章版权归文章作者所有,本站不对其观点以及内容做任何评价,请读者自行判断,以下是其具体内容:
Java EE利用的性能问题对严厉的项目和产品来说是一个非常重要的问题.分外是企业级的利用,并发用户多,数据传输量大,业务逻辑复杂,占用系统资源多,因此性能问题在企业级利用变得至关重要,它和系统的安定性有着直接的接洽.越发重要的是,性能好的利用在完成相同任务的条件下,可以占用更少的资源,得到更好的用户体验,换句话说,就是可以节俭费用和损耗,得到更高的利润.
要得到更好的性能,就需求对本来的系统举行性能调优.对运行在Glassfish上的JavaEE利用,调优是一件相对复杂的事情.在调优从前必必要熟习到:对JavaEE的系统,调优是多层次的.一个JavaEE的利用其实是整个系统中很少的一部份.开辟人员所开辟的JavaEE程序,无论是JSP还是 EJB,都是运行在JavaEE利用服务器(Glassfish)之上.而利用服务器本身也是Java语言编写的,需求运行在Java虚拟机之上. Java虚拟机也只不过是操作系统的一个利用罢了,和其他的利用(如Apache)关于操作系统来说没有本质的辨别.而操作系统却运行在一定的硬件环境中,包含CPU,内存,网卡和硬盘等等.在这么多的层次中,每一个层次的因素城市影响整个系统的性能.因此,对一个系统的调优,事实上需求同时对每个层次都要调优.JavaEE利用性能调优不但仅和Glassfish有关,Java语言有关,还要和操作系统以及硬件都有关系,需求调优者有综合的知识和技术.这些差别层面的办法需求综合纵效,结合在一同机动利用,才能快速有效的定位性能瓶颈.下面是一些具体的案例解析:
内存泄露问题
某个JavaEE利用运行在8颗CPU的服务器上.上线运行发现性能不安定.性能随着时间的增添而越来越慢.通过操作系统的工具(mpstat),发目前系统很慢的时刻,只有一颗CPU很忙,其他的CPU都很闲暇.因此猜疑是Java虚拟机常常举行内存回收,因为虚拟机在内存回收的时刻,有的回收算法普通只能运行在一个CPU上.通过Java虚拟机的工具“jstat”可以清楚的看到,Java虚拟机举行内存回收的频率非常高,几近每5秒中就有一次,每次回收的时间为2秒钟.别的,通过“jstat”的输出还发现每次回收释放的内存非常有限,大大都对象都无法回收.这种现象很大程度上表示着内存泄露.利用 Java虚拟机的工具“jmap”来获得当前的一个内存映象.发现有很多(超越10000)个的session对象.这是不正常的一个现象.普通来说, session对应于一个用户的多次拜候,当用户退出的时刻,session就应当失效,对象应当被回收.当我们和这个系统的开辟工程师理解有关 session的设置,发现当他们布置利用的时刻,竟然将session的timeout时间设置为50分钟,并且没有供应logout的接口.这样的设置下,每个session的数据城市保存50分钟才会被回收.按照我们的倡议,系统供应了logout的链接,并且奉告用户假如退出利用,应当点击这个 logout的链接;并且将session的timeout时间改正成5分钟.通过几天的测试,证明泄露的问题得到办理.
数据库衔接池问题
某财政利用运行在JavaEE服务器上,后台衔接Oracle数据库.并发用户数目超越100人左右的时刻系统终止呼应.通过操作系统层面的进程监控工具发现进程并没有被杀死或挂起,而CPU利用率几近为零.那么是什么缘由招致系统终止呼利用户恳求呢?我们操纵Java虚拟机的工具(kill -3 pid)将当前的全部线程状况DUMP出来,发现JavaEE服务器的大部份处理线程都在等候数据库衔接池的衔接,而那些已经得到数据库衔接的线程却处于阻塞状况.数据库管理员应要求查抄了数据库的状况,发现全部的衔接的session都处于死锁状况.明显,这是因为数据库端呈现了死锁的操作,阻塞了那些有数据库操作的恳求,占用了全部数据库衔接池中的衔接.后续的恳求假如还要从衔接池中获得衔接,就会阻塞在衔接池上.当办理数据库死锁的问题之后,性能问题迎刃而解.
以上是“<b>Java EE操纵程序在Glassfish上的性能调优案例解析</b>[Java编程]”的内容,如果你对以上该文章内容感兴趣,你可以看看七道奇为您推荐以下文章:
本文地址: | 与您的QQ/BBS好友分享! |