第五章调优案例分析与实战

_如此甚好 _如此甚好     2022-08-26     227

关键词:

案例1:
  1. 15万PV/天左右的在线文档类型网站最近更换了硬件系统,新的硬件为4个CPU、16GB物理内存,操作系统为64位CentOS 5.4 , Resin作为Web服务器。整个服务器暂时
  2. 没有部署别的应用,所有硬件资源都可以提供给这访问量并不算太大的网站使用。管理员为 了尽量利用硬件资源选用了64位的JDK 1 . 5 ,并通过-Xmx和-Xms参数将
  3. Java堆固定在12GB。使用一段时间后发现使用效果并不理想,网站经常不定期出现长时间失去响应的情况。

  4. 监控服务器运行状况后发现网站失去响应是由GC停顿导致的,虚拟机运行在Server模式 ,默认使用吞吐量优先收集器,回收12GB的堆 ,一次Full GC的停顿时间高达14秒
  5. 。并且由于程序设计的关系,访问文档时要把文档从磁盘提取到内存中,导致内存中出现很多由文档序列化产生的大对象,这些大对象很多都进入了老年代,没有在Minor
  6. GC中清理掉。这种情况下即使有12GB的 堆 ,内存也很快被消耗殆尽,由此导致每隔十几分钟出现十几秒的停顿 ,令网站开发人员和管理员感到很沮丧。

在高性能硬件上部署程序,目前主要有两种方式:

  • 通过64位JDK来使用大内存。
  • 使用若干个32位虚拟机建立逻辑集群来利用硬件资源。

对于第一种方式:
  1. 对于用户交互性强、对停顿时间敏感的系统,可以给Java虚拟机分配超大堆的前提是有把握把应用程序
  2. 的Full GC频率控制得足够低, 至少要低到不会影响用户使用,譬如十几个小时乃至一天才出现一次
  3. Full GC ,这样可以通过在深夜执行定时任务的方式触发Full GC甚至自动重启应用服务器来保持内存
  4. 可用空间在一个稳定的水平。在大多数网站形式的应用里,主要对象的生存周期都应该是请求级或者页面级的,
  5. 会话级和全局级的长生命对象相对很少。只要代码写得合理,应当都能实现在超大堆中正常使用而没有Full GC ,
  6. 这样的话,使用超大堆内存时,网站响应速度才会比较有保证。

但是这种部署方式存在以下的问题:
  • 内存回收导致的长时间停顿。
  • 现阶段 ,64位JDK的性能测试结果普遍低于32位JDK。
  • 相同程序在64位JDK消耗的内存一般比32位JDK大 ,这是由于指针膨胀,以及数据类型对齐补白等因素导致的。

对于第二种方式:
  1. 考虑到在一台物理机器上建立逻辑集群的目的仅仅是为了尽可能利用硬件资源,并不需要关心状态保留
  2. 、热转移之类的高可用性需求,也不需要保证每个虚拟机进程有绝对准确的 均衡负载,因此使用无
  3. Session复制的亲合式集群是一个相当不错的选择。我们仅仅需要保障集群具备亲合性,也就是均衡器
  4. 按一定的规则算法(一般根据SessionID分配)将一个固定的用户请求永远分配到固定的一个集群节点进
  5. 行处理即可,这样程序开发阶段就基本不用为集群环境做什么特别的考虑了。
但是同样存在以下缺点:
  • 尽量避免节点竞争全局的资源,最典型的就是磁盘竞争,各个节点如果同时访问某个磁盘文件的话(尤其是并发写操作容易出现问题),很容易导致IO异常。
  • 很难最高效率地利用某些资源池,譬如连接池,一般都是在各个节点建立自己独立的连接池 ,这样有可能导致一些节点池满了而另外一些节点仍有较多空余。尽管可以使用集中式的JNDI,但这个有一定复杂性并且可能带来额外的性能开销。
  • 各个节点仍然不可避免地受到32位的内存限制,在32位Windows平台中每个进程只能使用2GB的内存 ,考虑到堆以外的内存开销,堆一般最多只能开到1.5GB。在某些Linux或UNIX 系统(如Solaris ) 中 ,可以提升到3GB乃至接近4GB的内存,但32位中仍然受最高4GB(232)内存的限制。
  • 大量使用本地缓存(如大量使用HashMap作为K/V缓存 )的应用 ,在逻辑集群中会造成较大的内存浪费,因为每个逻辑节点上都有一份缓存,这时候可以考虑把本地缓存改为集中式缓存。


  1. 最后的部署方案调整为建立5个32 位JDK的逻辑集群,每个进程按2GB内存计算(其中堆固定为1.5GB ) ,
  2. 占用了 10GB内存。 另外建立一个Apache服务作为前端均衡代理访问门户。考虑到用户对响应速度比
  3. 较关心,并且文档服务的主要压力集中在磁盘和内存访问,CPU资源敏感度较低,因此改为CMS收集器进行
  4. 垃圾回收。部署方式调整后,服务再没有出现长时间停顿,速度比硬件升级前有较大提升。



案例二:集群间同步导致的内存溢出
  1. 有一个基于B/S的MIS系 统 ,硬件为两台2个CPU、8GB内存的HP小型机,服务器是WebLogic 9.2 ,每台机
  2. 器启动了3个WebLogic实 例 ,构成一个6个节点的亲合式集群。由于是亲合式集群,节点之间没有进行
  3. Session同步,但是有一些需求要实现部分数据在各个节点间共享。开始这些数据存放在数据库中,但由
  4. 于读写频繁竞争很激烈,性能影响较大,后面 使用JBossCache构建了 一个全局缓存。全局缓存启用后,
  5. 服务正常使用了一段较长的时间, 但最近却不定期地出现了多次的内存溢出问题。

在内存溢出异常不出现的时候,服务内存回收状况一直正常,每次内存回收后都能恢复到一个稳定的可用空间,开始怀疑是程序某些不常用的代码路径中存在内存泄漏,但管理员反映最近程序并未更新、升级过,也没有进行什么特别操作。只好让服务带着-XX : +HeapDumpOnOutOfMemoryError參数运行了一段时间。在最近一次溢出之后,管理员发回了 heapdump文件 ,发现里面存在着大量的org.jgroups.protocols.pbcast.NAKACK对象。

JBossCache是基于自家的JGroups进行集群间的数据通信,JGroups使用协议栈的方式来实现收发数据包的各种所需特性自由组合,数据包接收和发送时要经过每层协议栈的up()和down()方法,其中的NAKACK栈用于保障各个包的有效顺序及重发。JBossCache协议栈如图5-1所示。

由于信息有传输失败需要重发的可能性,在确认所有注册在GMS ( Group Membership Service ) 的节点都收到正确的信息前,发送的信息必须在内存中保留。而此MIS的服务端中有一个负责安全校验的全局Filter , 每鈑接收到请求时,均会更新一次最后操作时间,并且将这个时间同步到所有的节点去,使得一个用户在一段时间内不能在多台机器上登录。在服务使用过程中,往往一个页面会产生数次乃至数十次的请求,因此这个过滤器导致集群各个节点之间网络交互非常频繁。当网络情况不能满足传输要求时,重发数据在内存中不断堆积,很快就产生了内存溢出。














2017.2.28activiti实战--第五章--用户与组及部署管理部署流程资源

学习资料:《Activiti实战》 第五章用户与组及部署管理(二)部署流程资源内容概览:讲解流程资源的读取与部署。 5.2部署流程资源5.2.1流程资源流程资源常用的有以下几种:1流程定义文件:拓展名为bpmn20.xml和bpmn2流程... 查看详情

软件工程-第五章(结构化分析与设计)

一、结构化分析二、数据流图三、分层数据流图的审查四、数据字典五、描述基本加工的小说明六、结构化设计概述七、数据流图到软件体系结构的映射(信息流、数据流图的类型)八、初始结构图的改进 查看详情

mysql高级调优篇——第五章:sql调优在面试中深度剖析

    上节讲了Sql调优实战,本章聊聊面试中Sql调优深度的剖析场景!    在讲之前我们先做一些准备工作,建立一些需要用到的表:Mysql高级调优篇表补充——建表SQL_风清扬逍遥子的博客-CSDN博客⭐️tbl_emp⭐️... 查看详情

第五章查询处理和执行

sqlserver2012深入解析与性能优化(第3版)第五章查询处理和执行1.sqlserver通过四个步骤处理一个查询,分析,algebrizing,优化,执行。2.分析是分析语法错误生成分析树,绑定部分有,名字解析,类型推倒,聚合绑定,组合绑定。查... 查看详情

《spring实战》学习笔记-第五章:构建springweb应用程序

5.1 SpringMVC起步5.1.1 跟踪SpringMVC的请求  每当用户在Web浏览器中点击链接或提交表单的时候,请求就开始工作了。对请求的工作描述就像是快递投送员。与邮局投递员或FedEx投送员一样,请求会将信息从一个地方带到另一个... 查看详情

机器学习实战第五章logistic回归(代码片段)

defgradAscent(dataMatIn,classLabels):dataMatrix=mat(dataMatIn)#converttoNumPymatrixlabelMat=mat(classLabels).transpose()#converttoNumPymatrixm,n=shape(dataMatrix)alpha=0.001maxCycles=500weights=ones(( 查看详情

第五章相关分析第七组作业

第五章 相关分析小组作业组号:7 一、小组成员与小组任务 1.小组成员组长:余富强组员:陈洋、单兰东、金硕、颜洋洋 小组成员任务余富强:负责制作幻灯片,全程督导组员完成任务金硕:负责幻灯片讲解以及... 查看详情

spring实战第四版第五章pom.xml

<projectxmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0http://maven.apache.org/maven-v4_0_0.xsd"& 查看详情

r语言基础题及答案——r语言与统计分析第五章课后习题(汤银才)(代码片段)

R语言与统计分析第五章课后习题(汤银才)题-1设总体XXX是用无线电测距仪测量距离的误差,它服从(α,β)(α,β)(α,β)上的均匀分布,在200次测量中,误差为XiX_iXi​的次数有nin_ini​次:XiX_iXi​3579111315171921nin_ini​21161526221421221825求(α,β)(α,... 查看详情

r语言基础题及答案——r语言与统计分析第五章课后习题(汤银才)(代码片段)

R语言与统计分析第五章课后习题(汤银才)题-1设总体XXX是用无线电测距仪测量距离的误差,它服从(α,β)(α,β)(α,β)上的均匀分布,在200次测量中,误差为XiX_iXi​的次数有nin_ini​次:XiX_iXi​3579111315171921nin_ini​21161526221421221825求(α,β)(α,... 查看详情

kvm虚拟化实战精讲[第五章利用virsh对虚拟机管理]

650)this.width=650;"src="http://s3.51cto.com/wyfs02/M02/89/41/wKiom1gNwm7ThEqhAAM9UfYsuuE552.jpg-wh_500x0-wm_3-wmp_4-s_1450775902.jpg"style="float:none;"title="KVM虚拟化实战精讲[第五章利用virsh对虚拟机管理]"alt="wKiom1 查看详情

深入理解_jvm内存管理调优案例分析与实战10

1、高性能硬件上的程序部署策略目前常用2种方式:(1)通过64位JDK来使用大内存:   使用第一种方式关键:     <1>控制应用程序的FullGC频率。譬如10多个小时甚至一天才出现一次FullGC。  ... 查看详情

c++第五章个人银行账户管理程序案例

【第五章】 个人银行账户管理程序 案例实现//5_11.cpp#include"account.h"#include<iostream>#include"account.cpp"usingnamespacestd;intmain(){ //建立几个账户 SavingsAccountsa0(1,21325302,0.015); SavingsAccountsa1(1, 查看详情

第五章相关分析来自212独立团团长关育顺的小组作业

第五章 相关分析小组作业组号:1 一、小组成员与小组任务 1.小组成员组长:关育顺组员:刘嘉雯、徐小川、李泽霖、郭倚天 小组成员任务关育顺:负责幻灯片讲解以及软件操作,全程督导组员完成任务刘嘉雯:... 查看详情

第五章作业

一、.需求分析的目的是什么,有什么作用?需求分析的目的:是要求开发人员准确地理解用户需要什么,进行细致地调查分析,将用户的需陈述转化为完整的需求定义,再由需求定义转化为相应的软件需求规格说明。需求分析... 查看详情

第五章相关分析第二小组作业组长:乙佳荣

第五章相关分析第二小组成员:组长:乙佳荣组员:王洋于媛龄李天婵小组成员任务:乙佳荣:分配监督任务,进行ppt制作王洋:查询资料并做总结李天婵:回收资料,制作ppt于媛龄:总结ppt并讲解pptppt展示:  查看详情

《深入理解spark-核心思想与源码分析》第五章任务提交与执行

即欲捭之贵周,即欲阖之贵密。周密之贵,微而与道相随。---《鬼谷子》解释:译文:如果要分析问题,关键在于周详,如果要综合归纳问题,关键在于严密。周详严密的关键在于精深而与道相随。解词:捭阖(bǎihé):开合... 查看详情

《java并发编程的艺术》读后笔记-第五章java中的锁(代码片段)

文章目录《Java并发编程的艺术》读后笔记-第五章Java中的锁第五章Java中的锁1.Lock接口1-1定义1-2Lock的使用1-3Lock与synchronized区别1-4Lock的API2.队列同步器2-1定义2-2队列同步器的接口和示例2-3队列同步器的实现分析1)同步队列2ÿ... 查看详情