• 服务器不在响应请求，页面很久还打不开
• 请求超时
• 请求处理的时间越来越长

weblogic.admin.HTTP: 供与管理控制台的通信用

weblogic.admin.RMI:管理服务器和被管理服务器上都有这个队列，它是供管理的交通之用

weblogic.kernel.Default:执行队列线程

weblogic.kernel.System: weblogic自用





即 ListenThread传入
àsocket reader线程池(本地性能包)
à执行线程池，对每个server做threaddump的时候正常可以看到如下图线程信息，如果没有看到socket reader或者是ListenThread，那么这个server工作是不正常的，此时server可能处于fail状态



ListenThread负责响应所有请求，然后传入给socket reader线程，Socket Reader 线程接受来自监听线程队列的传入请求，并将该请求放入执行线程队列，执行线程负责执行具体任何。

上面其中任何一个环节工作不正常均有可能造成挂起的现象。

⑵服务器挂起的可能原因

问题名称	问题描述	不正常工作部分
JSP 编译导致服务器挂起	在大量负载情况下 JSP 编译造成服务器挂起	全部
JVM 错误导致服务器挂起	SUN JVM 错误，比如轻量型线程库、造成线程死锁等	执行线程队列
JDBC 中的服务器挂起	死锁造成 JDBC 挂起	执行线程队列
JSP 导致服务器挂起	servlet 时间的 JSP 错误设置，比如 PageCheckSeconds	全部
垃圾回收导致服务器挂起	垃圾回收花费太多时间	全部
线程占用导致服务器挂起	线程全部被占用，没有线程可用于新工作	执行线程队列
应用程序死锁导致服务器挂起	应用程序死锁 － 线程锁定资源 1，然后等待锁定资源 2。另一个线程锁定资源 2，然后等待锁定资源 1	执行线程队列
EJB_RMI 服务器挂起	RMI、RJVM 响应 － 所有绑定线程等待 RJVM、RMI 响应	weblogic.admin.RMI
网络IO资源限制	如等待网络IO资源	socket reader线程
大量高并发请求	大量高并发请求	执行线程队列
大量耗时操作导致执行线程用尽	如从数据库中加载大量数据	执行线程队列

⒊ 挂起问题排查步骤



①
ping挂起的server实例

。

如下面操作，可以ping浙江测试环境的CRM

具体的weblogic.Admin用法可以查看帮助

如果可以ping通，说明服务器可能未挂起，只是执行线程在执行耗时的操作未返回，此时可做thread dump进一步分析执行线程执行什么操作.

如果ping不通，则说明服务器确实挂起.

②查看执行线程队列，查看空闲线程数，如果线程数为空,查看每个线程是否正常处理，如都卡在某一个请求上，则此请求对应的操作可能有问题，在执行耗时操作。如果确实是高并发引起的，则考虑增大执行线程数;如果线程数仍有空闲，则问题可能发生在socket reader线程池上，可能socket reader未配置使用本地性能包或者确实由于高并发请求引起。配置使用本地性能包如下图:



③ 收集 Thread Dump

一般每隔 5 到 10 秒进行三个至更多个Thread Dump，并将信息保存下来，以便下面做分析，hread Dump 提供关于每个线程在特定时刻正在执行什么操作的信息,对分析线程状态变化、查找挂起原因很有帮助。

Thread Dump在unix平台上有几种方法:

如果看不到javacore和threaddump文件，请检查是否配置了以下参数(AIX上缺省只会产生 javacore)：

④ 分析Thread Dump

分析工具:
IBM Thread and Monitor Dump Analyzer for Javajca38.zip,如下图:

可以方便查看每个线程此时的堆栈信息。

⒈表现现象

进入控制台查看server实例状态，是SHUTDOWN状态如下图:

查看server状态:



在对应的目录下一般可以看到javacore file 和heapdump file,如下图:





⒉分析服务器宕机的原因

问题名称	问题描述	不正常工作部分
硬件问题	如磁盘损坏、CPU烧起来等
非法访问地址错误	如JVM自身bug导致访问地址出错
OOM内存溢出问题	应用程序导致内存溢出
……	很多原因

硬件问题不可避免，如果出现此问题，只能修复或者更换；

非法访问地址错误涉及到的可能是系统级的错误，我没能力分析，各位可以补充下。

OOM问题是我们应用中导致宕机的主要原因，下面将针对OOM主要分析。

⒊ OOM宕机问题分析排查

⑴ threaddump 和heapdump分析

服务器宕机的时候一般都会产生javacore和heapdump文件，我们最直接的可以拿来分析，javacore是关于CPU当前运行堆栈等相关信息 ，heapdump是目前内存的使用情况，两者结合起来分析，可以看出哪个点上导致了内存溢出，如果在这个点上确实加载了大量的数据并且创建大量对象，那么可以在这个点上做优化。如下面SM宕机的一个实例:



从上面可以看出，当前CPU正在运行执行队列线程11上，线程11当前的堆栈信息如右边所示，继续往下可以看到

跟踪应用程序的代码，发现此处会从数据库中级联加载组织信息，其数据量在几万甚至几十万以上，每条数据均创建一个对象，可以想象需要很大内存.

⑵内存泄露分析

如果在上一步骤中发现近段时间没有加载大数据，那么就有可能是内存泄露问题。内存泄露是比较难跟踪的，需要比较深入分析。以下给出一个简单的分析步骤:

垃圾回收日志(Verbose GC)可以帮我们断定是否发生了内存泄漏，导致JVM宕掉。要获取GC工作日志，我们可以在JVM启动的时候设置一个命令行选项-verbose:gc 或–verbosegc，在AIX机器上该选项为
-verbose:gc -Xverbosegclog:gc.log

。该选项可以打开一个开关追踪每次垃圾回收循环的内容（This option switches on a substantial trace of every garbage collection cycle.）。生成的详细垃圾回收日志在不同的平台，不同的发布版本上差别很大。从这些日志中，我们可以查看总的heap堆利用情况，用来判断gc是否花费很长时间，gc发生次数是否太多等。

GC日志分析工具，这里推荐使用

对于GC日志的分析，可以看到如下图:



如果上图回收前和回收后没有发生多大变化，或者回收后一直呈上升趋势，那么基本可以判定发生了内存泄露

如果在上面的GC日志分析中看到内存发生了泄露，那么下一步就需要定位到底是哪个地方内存发生了泄露。首先检查所有的集合、容器对象，如是否定义了全局的对象数组、对象列表、MAP，在操作这些数组、列表的时候，是否将不用的集合里的引用置为空等。

如果通过上面无法定位，那么这里推荐一款java 系统监控分析的软件Jprofile

（jprofile官方上说支持AIX,不过我在AIX5.3运行，总是报

Jprofile的使用请参考相关附件资源.

查看Jprofile分析报告，可以定位到哪个地方发生内存泄露。如下图是我启动本机weblogic的内存监控图:



该贴被xiaoyang编辑于2011-11-10 11:13:30