weblogic服务器优化配置详解

发布时间 : 星期一 文章weblogic服务器优化配置详解更新完毕开始阅读

五、优化默认执行队列线程

默认情况下,一个新的WebLogic实例配置了一个开发模式执行队列,

weblogic.kernel.default,它包含15个线程。另外,WebLogic提供了2个预配置队列:

· weblogic.admin.HTTP——只在管理服务器上才有,这个队列供与管理控

制台的通信用,你不能再配置它。

· weblogic.admin.RMI——管理服务器和被管理服务器上都有这个队列,它

是供管理的交通之用,也不能再配置它。

如果你不配置额外的执行队列,并且指定应用给这些队列,web 应用程序和RMI对象就使用默认的队列weblogic.kernel.default。

注意;如果自带的执行包没有在你的平台上使用,你可能需要调整默认的执行队列线程数和担任socket读的线程的百分比,去实现最佳性能。

5.1你应该更改默认的线程数吗?

增加更多的线程到默认的执行队列并不意味着你能处理更多的工作。即使增加更多的线程,仍然被处理器的能力限制。因为线程消耗内存,所以增加线程数属性的值不必要的降低了性能。一个高的执行线程数导致更多的内存被占用并且增加了上下文转换程序,它也会降低性能。

线程数属性的值与应用程序处理的工作的类型关系密切。例如,如果你的客户应用程序比较小,通过远程调用处理的工作较多,这样,客户端会花费更多的时间连接,因此,与能完成大量客户端任务的客户应用程序相比,会需要更多的线程数。

如果你的工作不需要使用超过15个线程(开发模式默认)或者25个线程(产品模式默认),就不要改变这个属性的值。通常,如果你的应用程序访问数据库花很长时间才返回结果,与访问数据库很短时间就返回的应用程序比较,你会需要更多的执行线程。从后者来看,用少点的线程数可能提高性能。

5.2需要修改默认线程数的情形

为了给执行队列决定一个理想的线程数,当队列中所有应用程序都运行在最大负荷的情况下,监视队列的吞吐量。增加线程数,重复负载测试,直到达到最佳的吞吐量。(在某些情况下,增加线程数将产生足够多的上下文转换程序,使得队列中的吞吐量开始减少。)

注意:WebLogic管理控制台显示的是所有服务器执行队列累积的吞吐量。为了得到这个值,后面将会介绍。

下表列出了在WebLogic 域中调整的线程及与CPU数量相关的情形,这些情况也假定WebLogic运行在最大负荷下,并且使用默认的执行队列满足所有的线程的请求。如果你配置了额外的执行队列并指派了应用程序到具体的队列,就需要依据一个个连接池得到结果。

如果?结果应该:

线程数

CPU正等着工作,但有工作被完成。

CPU利用率不能达到100%。增加线程数。

线程数=CPU的数量理论上理想,但是CPU仍然低利用。增加线程数。 线程数(适当的)>CPU的数量实际中理想,有个适当的上下文转换程序数量和高的CPU利用率。调整适当的线程数并且比较性能结果。

线程数(较大的)>CPU的数量过多的上下文转换程序,能导致重大的性能降级。

当你降低线程数时,性能可以增强。减少线程数,使它等于CPU的数量,然后仅仅增加已经得出的“堵塞”线程的数量。

例如,如果你有4个处理器,它们都同时运行,并出现堵塞线程,于是,你想要的执行线程就是4+堵塞线程的数

5.3修改默认线程数的步骤

用管理控制台修改默认执行队列线程数如下: 1.如果管理服务器没有运行,先启动。 2.访问管理控制台。

3.展开左边面板的Servers 节点,显示域服务。

4.右击服务名称,在弹出菜单中选择View Execute Queues ,就会在右边面板显示有执行队列的表用来修改。

注意:你只能修改默认的执行队列或者用户定义的执行队列。

5.在Name列,直接点击默认执行队列名称,显示配置标签用来修改执行队列数。

6.填下适当的线程数。

7.点击Apply,保存刚才的修改。

8.重启服务器,使新的执行队列设置生效。

5.4指派应用程序到执行队列

虽然可以配置默认的执行队列,为所有的WebLogic应用程序提供最佳的线程数,但是为关键的应用程序配置多个执行队列可以提供更多的管理控制。通过使用多执行队列,你可以保证应用程序有权占用固定的线程数,而不管WebLogic服务器有多大的负荷。

5.5创建执行队列

一个执行队列代表执行线程的命名集,线程指向一个或多个Servlet、JSP、EJB、RMI对象。执行队列在config.xml文件中描述,作为服务器元素的一部分。如,在config.xml文件中描述一个有4个线程的队列,命名为CriticalAppQueue,如下: ... 另一种创建队列的方法是通过管理控制台,配置步骤如下: 1.启动管理服务器,访问控制台。

2.展开左边面板中Servers节点,显示域中要配置的服务。 3.右击你要增加队列的服务实例,从弹出菜单中选择View Execute Queues。 4.在队列配置标签中,点击配置新执行队列链接。

5.在队列配置标签中,更改下列属性或接受系统的默认值: · 线程名称(Name):你可以输入线程名称,如CriticalAppQueue。

· 队列长度(Queue Length):通常保留默认值65536,队列长度表明了同时

发来请求的最大数,65536个请求是个很大的数,即使达到这个最大数,也是很少见的。

如果达到最大队列长度,WebLogic会自动成倍增长队列大小,以处理额外的工作。

注意:超过65536个请求预示队列中的线程有问题,不仅仅只是队列本身的长度问题,实践表明在队列中有堵塞线程或线程数不足的情况存在。

· 队列长限制百分比(Queue Length Threshold Percent):达到队列长度百

分比(1-99)时,就构成了溢出条件的产生。实际队列大小在限制的百分比之下时才被认为是正常的;在限制百分比之上就会产生溢出。当出现溢出,WebLogic日志就会产生一个错误消息,并且按线程数增量(Threads Increase)属性的值增加线程数,以帮助减少负载量。

(默认的队列长限制百分比为90%。一般情况下,应保留90%或其左右,以应对一些潜在的情况,使得有额外的线程可以去处理一些请求中的异常。记住,队列长度限制百分比不是一定作为自动优化参数――因为正常运作情况下,这个限度从不会被触发。) · 线程数(Tread Count):指派到这个队列的线程数。如果你不需要使用

超过15个线程(默认),就不必更改这个属性值。 · 线程数增量(Threads Increase):是指WebLogic探测到有溢出时,增加

到执行队列的线程数。当你指定为0(默认),出现溢出时,WebLogic会把运行良好状态改为“警告”,而且也不会指派额外的线程去减少负荷量。

(注意:如果WebLogic实例的线程数响应了溢出,那么这些额外的线程就会滞留在执行队列,直到服务器重启。监视错误日志,以判断溢出产生的原因,以便根据需要重配置线程数,防止以后类似情况产生。不要同时使用线程数增量和队列长限制百分比作为自动优化的手段。如此做通常结果会产生比正常需要还多的线程被指派到执行队列,这样上下文转化程序的增多会使服务器遭受很差的性能。) · 最大线程数:是指执行队列中能运行的,这个值保护WebLogic为了响

应频繁溢出,创建过多的线程数。默认情况下,最大线程数为400。 · 线程优先级:线程优先级与此队列相关。默认值为5。

6.点击Create,创建队列。 7.重启服务器。

5.6指派Servlet和JSP到执行队列

你可以把servlet或JSP分配到指定的配置执行队列,只需在初始参数中标识执行队列的名称。初始参数出现在Servert或JSP的部署描述文件web.xml中的init-param元素里。为了分配一个队列,可以把队列名作为wl-dispatch-policy参数的值。如: MainServlet /myapplication/critical.jsp wl-dispatch-policy CriticalAppQueue 5.7指派EJB和RMI对象到执行队列

为了把EJB分配到指定的队列,可以使用weblogic-ejb-jar.xml文件中dispatch-policy元素。

然而你也可以通过使用appc编译器-dispatchPolicy选项来设置派遣策略,BEA强烈推荐使用部署描述元素。因为用这种方式,如果EJB重编译,在部署用例期间,这个设置不会被丢失。

为了把RMI对象分配到指定的队列,可以使用rmic编译器的-dispatchPolicy选项,如:

java weblogic.rmic -dispatchPolicy CriticalAppQueue ...

联系合同范文客服:xxxxx#qq.com(#替换为@)