Weblogic Server线程数控制.docx
- 文档编号:5362564
- 上传时间:2022-12-15
- 格式:DOCX
- 页数:14
- 大小:44.59KB
Weblogic Server线程数控制.docx
《Weblogic Server线程数控制.docx》由会员分享,可在线阅读,更多相关《Weblogic Server线程数控制.docx(14页珍藏版)》请在冰豆网上搜索。
WeblogicServer线程数控制
WeblogicServer线程数控制
Michael
2012/2/14
文件修改记录
制定日期
生效日期
制定/修订内容摘要
页数
版本
拟稿
审查
批准
2012-02-14
2012-02-14
制定
9
V1.0
Michael
目录
1目的4
2解决方案4
3理解WeblogicServer的线程池4
4理解工作负荷管理器4
5工作负荷管理器应用6
5.1工作负荷管理器的应用范围6
5.1.1默认的WorkManager6
5.1.2全局WorkManager7
5.1.3应用级WorkManager7
5.2部署描述例子8
6过载保护9
7工作负荷管理器及执行队列应用10
7.1修改默认线程数10
7.2修改默认执行队列线程数11
7.3工作负荷管理器应用13
1目的
调整WeblogicServer请求处理线程数。
2解决方案
WeblogicServer允许配置应用的执行优先级。
通过WebLogicServer可以配置应用程序如何根据您定义的规则以及通过监视实际运行时性能来配置运行工作的优先级。
通过定义工作负荷管理器(WorkManager)并将其以全局方式应用于WebLogicServer域或应用于某一特定应用程序组件,您可以定义应用程序的规则和约束条件。
线程约束条件定义为请求分配的最大线程数、用来解决死锁问题的最小线程数和WebLogicServer开始拒绝请求前可以入队或运行的请求总数。
3理解WeblogicServer的线程池
在WebLogicServer9.0版本之前,进程有多个执行队列,在不同的执行队列,基于优先级和排队顺序执行不同的任务,这样可以避免死锁。
有缺省的执行队列:
weblogic.kernel.default,还有预先定义的队列来做内部管理用,如:
weblogic.admin.HTTP和weblogic.admin.RMI。
因为这些队列是为与管理控制台通信和管理通信量保留的,所以不能对其进行重新配置。
除非配置其他执行队列并为其分配应用程序,否则Web应用程序和RMI对象将使用weblogic.kernel.default执行队列。
对性能的调整,可以通过调整缺省队列上的线程数,或者为特定的应用配置自己的执行队列,对这个执行队列指定相应的线程数。
对WebLogicServer9.0以后,建立了单一线程池,可以执行所有类型的操作。
WebLogicServer根据用户定义的规则和实时运行情况,来调整处理工作的优先级。
线程池可以根据系统吞吐情况,自动调整大小。
WorkManagerAPI能使应用程序将单个请求任务分为多个工作项,并使用多个在WeblogicServer中配置的WorkManager指派这些工作项同时实行。
例如,根据历史吞吐量的统计,表明需要更高的线程数量时,WebLogicServer将自动增加线程数目。
与此类似,当统计表明减小线程不会影响吞吐量时,WebLogicServer会减少线程数。
这一新策略将使管理者更容易配置资源和性能调优,避免向从前一样调整自己的执行队列。
4理解工作负荷管理器
工作负荷管理器定义一组可以管理WebLogicServer实例所执行工作的请求类和线程约束条件。
管理员可以配置一套的调度规则与一个或多个应用或者特定的应用程序组件相关联。
可以在域级别、应用程序级别和模块级别上定义工作调度策略和约束。
这样,当我们在WebLogicServer部署多个应用,而这些应用有不同的性能要求,就可以使用WorkManagers定义的策略,根据应用的重要情况,分配不同比例的资源。
如,网上银行业务有企业银行业务和个人银行业务,因为企业银行业务资金数额大,可靠性要求高,那么就可以使用WorkManagers为其分配更多的资源。
WorkManager可以对如下资源进行控制:
FairShareRequestClass:
对请求指定线程使用时间所占百分比。
例如,Server上运行两个模块,WorkManager指定模块A的FairShareRequestClass为80,指定模块B的FairShareRequestClass为20。
当有大业务压力时,请求数量超过线程数,这时WebLogicServer将会分别安排80%和20%的线程使用时间给模块A和模块B。
ResponseTimeRequestClass:
指定响应时间(毫秒为单位)。
此时间不是指某一具体的请求响应时间,而是请求处理的平均响应时间。
WebLogicServer会根据响应时间减去平均处理时间,得到容忍等待时间。
Server调整前端请求压力,以使平均等待时间和容忍等待时间成比例。
例如,Server上运行两个模块,WorkManager指定模块A的响应时间目标为2000ms,模块B的响应时间目标为5000ms,当到大压力情况下,WebLogicServer控制分配到模块A和模块B的请求,使得响应时间大致在2:
5。
实际的平均响应时间可能会比设定的响应时间高或者低,但响应时间比会大致相同,如模块A的响应时间为1000ms,那么模块B的响应时间会在2500ms。
ContextRequestclass:
通过上下文信息分派请求。
如:
当前用户或者当前用户组。
MinThreadsConstraint:
最小线程限制,这样可以给一些请求分配最小线程数,防止请求申请新线程,而资源没有,产生死锁。
MaxThreadsConstraint:
最大线程限制,当请求达到最大的线程限制之后,Server将不会接受新的请求处理,直到当前的线程数目下降了。
CapacityConstraint:
容量限制,当到达这一容量限制时,Server会拒绝前端请求,这样保障了Server不会被资源过度消耗,达到系统可靠服务的目的。
容量数目包括:
等待请求和处理请求之和。
WorkManagers可以在如下配置文件进行域级别、应用程序级别和模块级别上定义:
config.xml—WorkManager指定应用或应用模块的约束条件,可以使用ServerConsole来定义WorkManager。
weblogic-application.xml—WorkManager指定应用或应用内模块的约束条件
weblogic-ejb-jar.xmlorweblogic.xml—WorkManagers指定模块的约束条件
weblogic-web-app.xml—WorkManagers指定应用的约束条件
配置示例:
ResponseTimeRequestClass示例:
FairShareRequestClass示例:
ContextRequestClass示例:
5工作负荷管理器应用
本节将介绍WorkManager的使用范围以及具体应用示例。
5.1工作负荷管理器的应用范围
工作负荷管理器的使用范围有三种类型,每种类型都有其使用范围、定义及使用方式。
一、默认的WorkManager
二、全局的WorkManager
三、应用级别的WorkManager
5.1.1默认的WorkManager
WebLogicServer实现了一个默认的WorkManager来管理线程和自身性能的调整。
当没有为应用指定其他的WorkManager时,所有应用都将使用这个默认的WorkManager。
在很多场景下,默认的WorkManager能满足大多数的应用需求。
WebLogicServer通过默认的WorkManager采用FairShare的算法把线程分配给每个应用。
应用获取分配给自身的线程而不会占有所有的线程。
5.1.1.1覆盖默认的WorkManager
可以通过创建和配置一个全局的名为“default”的WorkManager来覆盖默认的WorkManager。
这样就可以在WebLogicServer中控制线程。
注:
如果覆盖了默认的WorkManager,所有实例都将被覆盖。
5.1.1.2什么时候使用自定义WorkManager
通过以下规则可以帮助你决定什么时候使用WorkManager来管理线程:
●默认的FairShare不再适用。
这种情况也是经常发生的,当一个应用优先级要比另一个高。
●需要指定按响应时间策略的。
●需要指定最小线程数以避免服务器死锁。
5.1.2全局WorkManager
可以通过WebLogicAdministrationConsole和config.xml文件来配置全局的WorkManager,以此来提供给部署到服务器上的所有应用和模块使用。
应用将使用定义为全局的WorkManager作为一个模板。
每个应用都将创建自己的实例来处理与之相关的工作任务,与其他应用的工作任务相隔离。
多个应用可以配置使用同一个分发策略(dispatchpolicy),独立处理每个应用的任务。
5.1.3应用级WorkManager
除了全局范围的WorkManager外,也可以创建只提供给特定应用和模块使用的WorkManager。
通过WebLogicAdministrationConsole和以下方式定义应用级的WorkManager:
⏹weblogic-application.xml
⏹weblogic-ejb-jar.xml
⏹weblogic.xml
如果没有显示的为一个应用指派WorkManager,那么他将采用默认的WorkManager。
在部署描述中使用
如:
在web应用中使用WorkManager
WorkManager定义:
在Webapplication的web.xml文件中添加代码:
5.2部署描述例子
1)weblogic-application.xml
xmlns: j2ee=" xmlns: xsi="http: //www.w3.org/2001/XMLSchema-instance" xsi: schemaLocation=" 2)WebApplicationDescriptor xmlns: j2ee=" xmlns: xsi="http: //www.w3.org/2001/XMLSchema-instance" xsi: schemaLocation=" 3)WebApplicationDescriptor xmlversion="1.0"encoding="UTF-8"? > xmlns: j2ee=" xmlns: xsi="http: //www.w3.org/2001/XMLSchema-instance" xsi: schemaLocation=" 6过载保护 执当系统的负载压力非常大时,如果不对处理容量进行配置,那么会导致内存耗尽出现out-of-memery异常、执行队列过载等问题。 因此在WebLogicServer可以对如下资源进行配置: 因为在Server9.0以后使用了单一线程池,因此可以在管理配置时,指定最大的队列数目。 超过这一配置,Server将会拒绝请求。 请求包括: Web请求;非transaction的RMI请求。 为了保证在这种情况下,管理员还可以对Server进行管理,可以配置管理通道来管理,指定的最大队列长度不会包括管理通道数目。 ●在Web应用中限制HTTP会话数目。 这样当到达最大的会话数目之后,Server将拒绝请求创建新的会话。 如果是集群环境,其中一实例到达最大会话数,那么将通过Proxy转发到另外一个实例上。 ●内存溢出系统自动退出。 即当系统运行时,出现内存溢出错误,Server就会自动停机,避免应用处于不稳定运行状态。 然后,可以通过节点管理服务器或者其它工具将Server自动重启,缩短宕机时间。 配置如下: ●过载状态。 如果运行实例处于WorkManager容量超限或者低内存状态,Server9.0通过ServerRuntimeMBean.getHealthState(),可以获得Server新的一个状态Overloaded.可以提示Server已处于不正常状态,便于管理员对系统状况清楚的了解。 7工作负荷管理器及执行队列应用 7.1修改默认线程数 修改weblogic\user_projects\domains\base_domain\bin下的setDomainEnv.sh中在JAVA_OPTIONS中添加如下: JAVA_OPTIONS="${JAVA_OPTIONS}-Dweblogic.threadpool.MinPoolSize=100-Dweblogic.threadpool.MaxPoolSize=1000" exportJAVA_OPTIONS 说明: JDK5.0以后每个线程栈大小为1M,但是操作系统对一个进程内的线程数还是有限制的,不能无限生成。 32位操作系统根据JVM最大堆内存设置;64位操作系统经验值在3000~5000左右。 调整后重启WeblogicServer,通过监控工具可以查看到服务器启动了最小的线程数。 如下所示: 7.2修改默认执行队列线程数 如果需要使用执行队列的方式(WeblogicServer9.0之前版本功能),需要在JAVA_OPTIONS中添加如下配置: JAVA_OPTIONS="${JAVA_OPTIONS} -Dweblogic.Use81StyleExecuteQueues=true" exportJAVA_OPTIONS 或者在weblogic\user_projects\domains\base_domain\confi.xml中配置要素: 然后在weblogic\user_projects\domains\base_domain\confi.xml中配置执行队列:
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Weblogic Server线程数控制 Server 线程 控制