【问题标题】:WebSphere web container threads hungs with maximum threads state in runnableWebSphere Web 容器线程挂起,最大线程状态处于可运行状态
【发布时间】:2016-07-20 07:41:33
【问题描述】:

我们有带有 2 个节点代理和 4 个应用服务器的 WebSphere 环境。在高流量时,其中一个应用程序服务器停止响应请求,并跳转到最大 Web 容器线程数。
在分析线程转储时,我们发现大约 60% 的线程处于可运行状态,等待和停放状态各占 20%。
我们在线程转储中看不到任何死锁警告。 仔细观察,我们发现其中一个 Web 容器线程拥有锁,并显示以下消息:

Owns Monitor Lock on com/ibm/ws/classloader/ExtJarClassLoader@0x0A00000000FA6F30

有人可以帮助理解上述错误及其解决方法吗?

【问题讨论】:

  • 您在 Websphere 日志中看到任何错误吗?
  • 能否提供更多数据,例如 ffdc 错误。
  • 在日志中,我们看到数据库实例存在问题或可扩展性问题。随着大量流量,我们看到数据库响应时间从 1 秒增加到 5 秒。直接的解释是,我们被数据库阻塞了,这缓慢并最终将应用服务器发挥到了最大容量。我们将数据库端的资源增加了一倍,但问题仍然存在。现在我们在线程转储日志中看到了上述错误。
  • @M.Dogru 能否请您帮助我们,我们如何查看 ffdc 错误?
  • /AppServer/profiles//logs/ffdc

标签: java websphere websphere-8 web-container ibm-jdk


【解决方案1】:

查看拥有锁的线程的堆栈跟踪很重要,然后查看等待该锁的所有其他线程的堆栈跟踪。对于 ExtJarClassLoader,它几乎肯定意味着所有线程都在尝试执行 loadClass 操作。如果许多线程都在尝试这样做并被阻塞,那么这通常意味着正在运行的代码正在尝试 失败 loadClass 操作,捕获 ClassNotFoundException 并继续。创建和抛出 ClassNotFoundException 代价高昂,因此通常应该修改代码以缓存整体结果(例如,如果它正在尝试一系列类加载,则应该以某种方式缓存正/负结果)。如果调用loadClass的代码是第三方库,这当然会比较复杂。

【讨论】:

  • 如果需要更多帮助,请将所有 javacore 文件一起压缩成一个 zip 文件并上传到wait.ibm.comwait.ibm.com 将分析线程转储并报告应用程序的瓶颈。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-03-29
  • 2016-04-25
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多