05.wls调优6. 软件性能工程
• 软件性能工程(Software Performance Engineering,
SPE)是一种构建软件系统以达到系统性能目标的方
法。
• SPE过程开始于开发周期早期的系统需求分析阶段。
• 环境所需要的性能目标被记录下来
• 然后,在整个设计和实施阶段,使用定量方法来确定
符合要求的架构。
• 这些方法可用于排除那些性能可能难以接受的架构。
• SPE存在于整个开发过程中,其目的包括:
• 预测和管理不断发展的软件的性能
• 依据规范监视实际性能,并报告确定的问题
13. 找到瓶颈 — CPU限制
• 很容易检查到CPU限制情况,因为此时CPU会以100%
或接近100%的使用率运行
• 可能的原因包括:
• 垃圾回收
• Java应用程序本身效率问题
• 解决方法:
• 监视垃圾收集
• 分析Java应用程序
14. 找到瓶颈 — I/O限制
• I/O限制通常具有以下特征:
• CPU未达到饱和
• 不管客户端负载如何,性能都相同(例如,无论有多少个客户
端,到数据库的TPS始终为50个)
• I/O限制常见的类型:
• 数据库限制
• 网络限制
16. 网络限制
• 如果网络达到饱和,则它就会成为瓶颈
• 可以监视网络来确定网络性能,解决性能问题时,不要忘记检查
数据包丢失或错误
• 数据包再发送、重复数据包、数据包监听丢失
• netstat (显示协议统计和当前的 TCP/IP 网络连接 )
• netstat [-a] [-e] [-n] [-s] [-p protocol] [-r] [interval]
• 网络可能会在带宽使用率低于50%时达到饱和
• 应该确保应用系统有足够的带宽
• 如客户端到WLS,WLS到数据库服务器之间的带宽。
• 在集群中
• Servlets和EJBs复制会话信息需要更大的网络带宽
• 可能的解决方案:
• 购买更多带宽
• 使用更大的数据包,从而更好的利用网络带宽
• 使用特定于操作系统的配置
19. Time Wait Interval
• 应用程序关闭的TCP连接,在被操作系统释放前,将先进入等待
状态。套接字处于等待状态的时间称为time wait interval。在这种
状态下,操作系统会维护分配给该socket的资源,包括文件描述
符
• 这个参数决定TCP Socket 在被执行关闭操作后保持alive状态的时
间间隔
20. swap空间
• 太多的Swap空间
• 会浪费磁盘空间
• 太少的Swap空间
• 则系统会发生错误
• 如果Swap空间用完
• 则服务进程无法启动,通常会出现“application is out of memory‖的错误,严
重时会造成服务进程的死锁。
• Swap分区的数量对性能也有很大的影响
25. JVM调整
• Java EE应用程序部署在Java EE应用服务器上
• 作为Java程序,Java EE应用服务器需要Java虚拟机来
运行和支持其上运行的Java应用程序
• 正确配置JVM参数可以增强应用服务器的性能
• JVM调整的内容包括:
• 内存参数(堆大小)
• 垃圾回收
• 堆栈大小
• 类加载
• 编译/解释
27. HotSpot VM
• 与其他VM一样,HotSpot VM首先直接解释应用程序的
字节码
• 然后,检测占用应用程序大部分时间的方法(“热点
”),并将这些方法转换为本地代码
• HotSpot VM使用自适应优化技术
• 它包括两个可互换的版本:
• 客户端:调整侧重于快速加载和编译重要类和方法
• 服务器端:加载速度较慢,但更侧重于生成高度优化的JIT编译
,从而获得更高的性能
32. 调整垃圾回收常见参数(续)
• 堆中代的大小
• -XX:NewSize=[n]
• -XX:MaxNewSize=[n]
• 建议在生产系统中将NewSize和MaxNewSize设置为相同值
• 建议值为最大堆大小的四分之一左右
• 不要超过堆大小的二分之一
• 年轻代中年轻代空间的大小
• -XX:NewRatio=[n] 年老代:年轻代的比例
• HotSpot客户端默认为8,服务器端默认为2
• 年轻代空间:存活空间比率
• -XX:SurvivorRatio=[n]
• 默认值是25,建议设置为4~8
• 从年轻代提升到年老代的阈值
• -XX:MaxTenuringThreshold=[n]
35. 垃圾回收算法
选项 说明 代
-XX:+UseParallelGC 并行/吞吐量垃圾回收 年轻代
-XX:+UseConMarkSweepGC 并发型低暂停垃圾回收 年老代
-XX:+UseTrainGC 增量型/自适应型低暂停垃
圾回收
年老代
default 串行垃圾回收—让应用程
序暂停
年轻代和年
老代
• 影响垃圾回收算法的 HotSpot命令行开关项
44. JRockit VM
• JRockit VM是针对Intel和Solaris(SPARC)架构开发
和优化的,以便确保Java应用程序的可靠性、可伸缩
性和可管理性
• JRockit VM专用于服务器端应用程序
• 为了获得更好的运行时性能,JRockit使用JIT编译将
Java代码编译为本地代码
• JRockit 在后台对大量使用的方法进行优化,这些方法
是使用低成本取样检测到的
• JRockit还附带一组独立的管理和监视工具( JRockit
Mission Control)
47. JRockit基本参数调整
• 调整Heap大小
• -Xms:<size>
• -Xmx:<size>
• 例如,java -Xms:512m -Xmx:1024m MyServerApp
• 调整垃圾回收算法
• -XgcPrio:throughput
• -XgcPrio:pausetime
• -XgcPrio:deterministic
• 例如,java -XgcPrio:pauseTime MyTransactionApp
49. JRockit性能调整
• Lazy Unlocking
• -XXlazyUnlocking ,减少同步方法的竞争
• Call Profiling
• -XXcallProfiling, 针对用户代码做统计优化
• Large Pages
• -XlargePages, 优化TLB执行方式,CPU的地址映射
51. JRockit Mission Control
• JRockit Mission Control包括一组独立的管理和监视工
具:
• JRockit 管理控制台
• 符合JMX标准的监视工具
• JRockit运行时分析器(Runtime Analyzer)
• 记录JVM和运行中的应用程序,并帮助您对其进行分析
• JRockit内存泄漏检测器
• 检测和查找导致内存泄漏的原因
• JRockit Mission Control的主要功能是执行必要的监控
,同时尽量减少对系统的影响
53. 管理服务器
• 默认情况下,JRockit VM中的管理服务器处于禁用状态
• 要启用管理服务器,请在JVM启动脚本中添加以下命令行
参数:
• - Java –Xmanagement … weblogic.Server
• 管理服务器用于连接的默认端口是7091
• 通过设置以下命令行参数,可以更改管理服务器端口:
• -Djrockit.managementserver.port=<port> …
56. • 不要使用 System.gc(),因为这是个 Full GC,中断时
间会比较长,效率低。也不要使用 finalize() 方法。
• Object 不需要时,显示的将其赋值为 null
• 多用 Pool,但是小的 Object 不要使用 pool,因为会带
来 GC 的效率问题
程序设计与GC的最佳实践
57. JVM/CPU比率
Rule of Thumb
2-4 CPUs per WebLogic JVM
Establish Repeatable Benchmarks and Validate for Your
Application!!!
Empirical experiences on different platforms and applications
show that optimal performance can vary from 1 CPU to 8 CPU’s
per JVM
61. Socket Readers
• 两种socket readers类型:
• Native:性能更好
• Pure Java: 性能相对差,跨平台
• 如果所使用的平台没有可利用的性能包,WLS就分配
一定比例的执行线程用于”Socket Readers”,如果
应用程序经常使用I/O,可以通过提高这个比例来获得性
能的提高。
• Default value: 33%
• Minimum value: 1%
• Maximum value: 99%
77. WLS 9.x 之前版本中的线程管理
• 手段调整线程池大小
• 使用多个执行队列来分散工作
• 使用以下参数调整执行队列:
• 线程计数
• 队列长度
• 阈值百分比
• 最大线程数
• 线程优先级
78. 工作管理器(Work Managers)
• WLS 9.x 之后的版本拥有自调优功能,也就是说,默
认情况下,它可以根据需要调整线程的大小
• WLS 还为管理员提供了Work Manager的Hook API,
用于调整线程
• WLS可以根据以下因素确定工作的优先级:
• 管理员定义的参数
• 运行时度量
• 执行一个请求所用的实际时间
• 请求进出线程池的速率
• 调整工作管理器可以显著调高应用程序的性能
79. Oracle Confidential. | 79
为何要对工作任务划分?
• 应用程序之间的公平共享
• 避免死锁
• 工作任务严格有序的被处理
• 为特定的工作任务类型设置优先级
• 过载保护
传统方法
多线程池
工作管理器(Work Managers)
工作划分
80. Oracle Confidential. | 80
工作管理器(Work Managers)
WLS的自调优线程池
Network Socket Handlers
(―Muxers‖)
Asynchronously dispatched work
from WebLogic kernel, subsystem,
or application
Request Queue
Self Tuning
Thread Pool
1. Monitor rate of
request processing
2. Adjust thread pool
size accordingly
• Active
• Standby
• Stuck
• Hogging
82. Oracle Confidential. | 82
• 请求类(Request Class)可以实现根据优先级安排工
作任务,其包括如下三种类型:
• Fair Share
• Response Time
• Context based
• 约束(Constraints)定义了分配给执行请求的最大线
程数和最小线程数,以及WLS开始拒绝后续请求之前
可以排队或执行的请求的总数,其类型包括:
• Minimum threads
• Maximum threads
• Capacity
工作管理器(Work Managers)
工作任务划分
83. Oracle Confidential. | 83
配置公平份额请求类
Fair Share Request Class
• 公平份额请求类指定处理请求所需的线程使用时间的
评价百分比
• 配置选项:“Name”(名称)和“Fair Share”(公平份额)
• 默认值:50
• 最小值:1
• 最大值:1000
84. Oracle Confidential. | 84
配置响应时间请求类
Response Time Request Class
• 响应时间请求类指定响应时间目标(以毫秒为单位)
• 配置选项:“Name”(名称)和“Goal”(目标)
• 默认值: 0
85. Oracle Confidential. | 85
配置上下文请求类
Context Request Class
• 上下文请求类根据上下文信息(例如,当前用户或当
前用户所属的组)为请求分配请求类
• 配置选项: “Name” (名称)和“Context Case”(上下文案例)
86. Oracle Confidential. | 86
配置最大线程数约束
• 最大线程数约束限制了最多可以有多少个并发线程执
行受此约束制约的请求
• 配置选项:
• Name(名称): 用户指定的名称
• Count(计数): 线程计数 (默认值: -1)
• Data Source(数据源): 其大小被当作最大约束的连接池的名
称
87. Oracle Confidential. | 87
配置最小线程数约束
• 最小线程数约束保证服务器至少分配多少个并发线程
给受此约束制约的请求
• 配置选项
• Name(名称): 用户指定的名称
• Count(计数): 线程计数 (默认值: -1)
88. Oracle Confidential. | 88
配置容量约束
• 容量约束会使服务器在达到其容量时,拒绝后续请求
以避免服务器死锁
• 配置选项:
• Name(名称): 用户指定的名称
• Count(计数): 线程计数 (默认值: -1)
89. Oracle Confidential. | 89
引用请求类型和约束
• 工作管理器(Work Manager )是通过封装用于调度请
求的请求类和(或)约束来定义的
• 配置选项:
• Name (名称)
• Request Class/Constraint (请求类、约束)
90. Oracle Confidential. | 90
全局工作管理器 (Global Work Managers)
• 可供服务器上部署的所有应用程序和模块使用
• 可以从WLS管理控制台创建或在域的配置文件
config.xml中创建
• 创建单独的实例以区分来自其它应用程序的工作
• 可以在应用程序的部署描述符中使用调度策略引用相
应组件的名称,从而控制应用程序的性能
• 对所有应用程序使用相同的调度策略
95. Oracle Confidential. | 95
配置应用级工作管理器
Application Level Work Manager
• 应用程序范围的工作管理器仅可供特定的应用程序或
模块使用
• 应用程序调度策略: weblogic-application.xml
96. Oracle Confidential. | 96
EJB组件级工作管理器
• 组件级工作管理器只能分配到相应的组件
• EJB调度策略:
• Weblogic-ejb-jar.xml
• 用法:
• <weblogic-enterprise-bean>
• <ejb-name>xxx</ejb-name>
• <jndi-name>xxx</jndi-name>
• <dispatch-policy>Work manager here</dispatch-policy>
• <dispatch-policy>也可以表示自定义执行队列,以便向
后兼容
99. Oracle Confidential. | 99
阻塞线程工作管理器
Shutdown Trigger
• 配置阻塞线程工作管理器是为了根据相应的阻塞线程
参数设置来结束所有线程,从而关闭工作管理
• 能提供过载保护
• 配置选项:
• 阻塞线程最长时间:在服务器将某个线程诊断为阻塞前,该线
程必须连续工作的秒杀
• 阻塞线程计数:使服务器转换到Failed状态的阻塞线程数
101. Oracle Confidential. | 101
向后兼容性
• 向后兼容执行队列
• 使用命令行选项:
• -Dweblogic.Use81styleExecuteQueues=true
• 在config.xml中更改服务器设置
• <Use81-style-Execute-Queues>true</Use81-style-
Execute-Queues>
• 以便于应用程序迁移,版本10中提供了向后兼容功能
• 已经配置的工作管理器在运行时会被服务器实例转换
为执行队列
• 执行队列的线程计数以约束中定义的值为基础
• 如果工作管理器未施加任何约束,则会使用全局默认
执行队列
102. Oracle Confidential. | 102
了解CommonJ
• CommonJ是BEA和IBM联合推出的Java EE应用程序
编程模型和API规范
• 提供了一种编程方式来处理应用程序中的工作
• CommonJ工作管理器提供了服务器级别的配置,用于
设置Servlet和EJB的调度策略
103. Oracle Confidential. | 103
访问CommonJ工作管理器
• 可以直接在应用程序中使用JNDI查找访问CommonJ工
作管理器
• 这类工作管理器不需要使用调度策略
• Servlet和EJB可以在本地JVM中通过JNDI查找访问工
作管理器
104. Oracle Confidential. | 104
将CommonJ映射到工作管理器
• 通过在相应的部署描述符中定义resource-ref,可以将工
作管理器资源与应用程序相关联
• Servlet引用web.xml中的resource-ref来访问工作管理器
• EJB引用ejb-jar.xml中的resource-ref来访问工作管理器
• CommonJ工作管理器通过使用服务器描述符中的同名元
素映射到WLS工作管理器
116. 会话超时
• 只要创建了 HTTP session对象,它将一直驻留在内存
中,直到发生以下任一情况:
• 明确地令该对象失效
• 服务器在特定的一段时间(session timeout)后将其删除
• 服务器关闭
• 以上情况中最先发生的为准
• 会话超时值较大意味着该会话对象会在内存中保留较
长时间
• 如果有大量用户,则会话对象的大小和会话超时值会
影响性能
123. 连接池大小
• 可以通过以下参数控制WLS中的连接池大小
• Initial Capacity(初始容量)
• Maximum Capacity(最大容量)
• Capacity Increment(容量增长步长)
• 可以通过调整这些参数来提高服务器性能
• 在开发模式下, 把初始容量设置小一些,在生产模式
下,把它设置大一些
• 对于存在繁重数据库流量的应用程序,可以考虑使初
始容量等于最大容量