dev2dev 首页 > 资源中心 > 专家Blog > 专家Blog文章
使用执行队列管理系统资源
不久以前，一位客户向我求助，他遇到了严重的系统故障。其症状主要是，如果用户登录特定的应用程序失败，就会被重定向到一个技术性错误页面。该问题第一次报告之后大约60分钟，中间设备（WebLogic服务器的宿主）会报告文件描述符用尽，这影响了部署在每个集群上的所有应用程序。看起来好像是单个应用程序中的资源管理问题引发了系统范围的问题。
我到达现场时已经是问题出现的第4天了，绕过该问题的唯一方法就是，重启从数据库到web服务器的所有服务，这需要整整40分钟。客户违反了他们的SLA（服务水平协议），因此承受了巨大的压力，务必要找出问题的根源并解决它。
基础架构小组详细地为我介绍了问题的背景，并向我提供了WLS和我所要求的其他应用程序的所有日志文件和线程转储。他们继续工作，而我则开始分析数据，大约半个小时后，我已经确定问题出在哪里，以及同样重要的是，不在哪里。
线程转储显示，WebLogic服务器没有空闲线程，并且几乎所有的线程都在处理对远程EJB的调用。而这些EJB却在对另外的（不是BEA的）Java应用服务器进行RMI调用。该服务器的线程转储显示，有大量的线程处于MW状态，而它们所等待的线程正在执行来自开源包HTTPClient（不要与Apache Jakarta项目中的同名包混淆了）的代码。在与基础架构小组谈论了这些情况之后，我们成功地通过加入一个操作过程缓解了问题。该过程非常简单，它的功能是监控RMI应用服务器进程所使用的开放文件描述符的数量，如果超出了设定的阈值，服务器就会重启。而服务不会中断，因为RMI应用服务器不止一个，如果客户机请求失败，就会被转到另一个服务器上。
添加了该过程之后，我开始努力解决引发问题的开源HTTPClient代码。该库由第三方RMI应用程序使用，而且版本非常老。我实在怀疑它还能在现在的环境中使用，我把这种情况告诉了客户。正如通常会出现的情况，当初做出使用该软件的决定的人已经不在那里工作了，否则他就会被解雇。
该代码本身就存在一个严重的问题，它的一个设计特点又使问题加重。首先，用来创建HTTP连接的套接字选项SO_TIMEOUT被设为0，有效地禁用了超时。其次，套接字是在多个不同的HTTP连接线程之间共享的。这意味着，如果有一个连接长时间地使用套接字，那么许多其它的连接就必须一直等到它被释放。该行为与线程转储的数据关联。尽管其他超时（例如，事务超时或Apache HTTP连接超时）可能会释放资源，但是这些超时的设置远远不够。我们修复了代码，问题就得以有效解决。但是，仅仅几天之后，网络小组因为一些应该只花费6秒钟的网络操作却花了长得多的时间而进行了一次深入研究，结果发现根源是一个硬件路由器在不断丢失数据包。
如果对应用程序资源管理能够更密切注意，这些问题决不会拖到如此严重以至于使客户违反SLA的地步。例如，为了缓解问题，我曾经建议创建和分配几个执行队列。这种行为通常涉及到性能调优，但是它是限制资源消费的一个不错的方法。我还遇到不少客户，他们为一个任务关键型的应用程序创建了临时的执行队列，但是之后又让多个应用程序（通常都是不那么关键的）共享一个大的队列，从而导致他们也遇到了类似的问题。
下面是一些有用的资源：
Using Execute Queues to Control Thread Usage.
Common WebLogic Server Deadlocks and How to Avoid Them.
View from the Trenches: Looking at Thread-Dumps.
评论
发表人：david.turing，2005年8月30日，09:12 AM
下面是weblogic.Admin工具的输出结果：
C:\bea\user_projects\domains\medrec>java -cp %CLASSPATH% weblogic.Admin -url localhost:7001 -userna
e weblogic -password weblogic GET -pretty -type ExecuteQueue
---------------------------
MBeanName: "examples:Name=weblogic.kernel.Default,Server=examplesServer,Type=ExecuteQueue"
CachingDisabled: true
Name: weblogic.kernel.Default
Notes:
ObjectName: weblogic.kernel.Default
Parent: examplesServer
QueueLength: 65536
Registered: false
ThreadCount: 15
ThreadsIncrease: 0
ThreadsMaximum: 400
ThreadsMinimum: 5
Type: ExecuteQueue
发表人：hoos，2005年8月30日，01:23 PM
- 我同意您关于多个队列的说法，但是对于文中的例子，多个队列也挽救不了服务，因为即使weblogic正常运行，服务还要依赖于其他组件才可用。为出现问题的RMI服务创建单独的队列（假定称之为“AuthenticationQueue”）可以使Weblogic Instance继续处理其他的请求，但是代价是如果没有辅助工具，就很难诊断问题。
发表人：simonvc，2005年9月5日，08:49 AM
- 我基本同意您的说法，对于服务仍然要受到其他组件的影响这一点我没有异议。但是对于至少已经登录的客户可以继续使用服务，如果“AuthenticationQueue”非常小，假设不超过5个线程，队列应该对丢失的文件描述符有所限制。线程队列有助于减轻问题的严重性，但是不能阻止其发生。
我认为，添加新的队列不会促使诊断这些问题变得更加 困难。利用线程转储，可以很轻松地查明所有的线程队列及其内部线程的状态，这些就足以找出问题所在。
原文出处：
http://dev2dev.bea.com/blog/hoos/archive/2005/08/using_execute_q.html
作者其它文章
|
