标签：round images 基本 程序 jdk 进程 处理 color 1.5
15万PV/天左右的在线文档类型网站最近更换了硬件系统,新的硬件为4个CPU、16GB物理内存,操作系统为64位CentOS 5.4 , Resin作为Web服务器。整个服务器暂时没有部署别的应用,所有硬件资源都可以提供给这访问量并不算太大的网站使用。管理员为 了尽量利用硬件资源选用了64位的JDK 1 . 5 ,并通过-Xmx和-Xms参数将Java堆固定在12GB。使用一段时间后发现使用效果并不理想,网站经常不定期出现长时间失去响应的情况。监控服务器运行状况后发现网站失去响应是由GC停顿导致的,虚拟机运行在Server模式 ,默认使用吞吐量优先收集器,回收12GB的堆 ,一次Full GC的停顿时间高达14秒。并且由于程序设计的关系,访问文档时要把文档从磁盘提取到内存中,导致内存中出现很多由文档序列化产生的大对象,这些大对象很多都进入了老年代,没有在MinorGC中清理掉。这种情况下即使有12GB的 堆 ,内存也很快被消耗殆尽,由此导致每隔十几分钟出现十几秒的停顿 ,令网站开发人员和管理员感到很沮丧。
在高性能硬件上部署程序,目前主要有两种方式:
对于用户交互性强、对停顿时间敏感的系统,可以给Java虚拟机分配超大堆的前提是有把握把应用程序的Full GC频率控制得足够低, 至少要低到不会影响用户使用,譬如十几个小时乃至一天才出现一次Full GC ,这样可以通过在深夜执行定时任务的方式触发Full GC甚至自动重启应用服务器来保持内存可用空间在一个稳定的水平。在大多数网站形式的应用里,主要对象的生存周期都应该是请求级或者页面级的,- 会话级和全局级的长生命对象相对很少。只要代码写得合理,应当都能实现在超大堆中正常使用而没有Full GC ,
- 这样的话,使用超大堆内存时,网站响应速度才会比较有保证。
考虑到在一台物理机器上建立逻辑集群的目的仅仅是为了尽可能利用硬件资源,并不需要关心状态保留、热转移之类的高可用性需求,也不需要保证每个虚拟机进程有绝对准确的 均衡负载,因此使用无Session复制的亲合式集群是一个相当不错的选择。我们仅仅需要保障集群具备亲合性,也就是均衡器按一定的规则算法(一般根据SessionID分配)将一个固定的用户请求永远分配到固定的一个集群节点进行处理即可,这样程序开发阶段就基本不用为集群环境做什么特别的考虑了。
最后的部署方案调整为建立5个32 位JDK的逻辑集群,每个进程按2GB内存计算(其中堆固定为1.5GB ) ,占用了 10GB内存。 另外建立一个Apache服务作为前端均衡代理访问门户。考虑到用户对响应速度比较关心,并且文档服务的主要压力集中在磁盘和内存访问,CPU资源敏感度较低,因此改为CMS收集器进行垃圾回收。部署方式调整后，服务再没有出现长时间停顿,速度比硬件升级前有较大提升。
有一个基于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栈用于保障各个包的有效顺序及重发。JBossCache协议栈如图5-1所示。
由于信息有传输失败需要重发的可能性,在确认所有注册在GMS ( Group Membership Service ) 的节点都收到正确的信息前,发送的信息必须在内存中保留。而此MIS的服务端中有一个负责安全校验的全局Filter , 每鈑接收到请求时,均会更新一次最后操作时间,并且将这个时间同步到所有的节点去,使得一个用户在一段时间内不能在多台机器上登录。在服务使用过程中,往往一个页面会产生数次乃至数十次的请求,因此这个过滤器导致集群各个节点之间网络交互非常频繁。当网络情况不能满足传输要求时,重发数据在内存中不断堆积,很快就产生了内存溢出。
标签：round images 基本 程序 jdk 进程 处理 color 1.5
原文地址：http://www.cnblogs.com/You0/p/6670177.html
