weblogic挂起

weblogic挂起
1.     表现现象
    服务器不在响应请求，页面很久还打不开
   请求超时
  请求处理的时间越来越长
通常，服务器挂起不会表现为服务器崩溃，进入控制台查看server实例状态，仍然是RUNNING状态，进到请求队列里面查看，发现空闲执行线程没有了
⒉分析服务器挂起的原因
⑴ webloigc各线程队列工作原理
Execute Queue
weblogic.kernel.Default: 执行队列线程
服务器挂起的可能原因
 
问题名称 问题描述 不正常工作部分
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通，说明服务器可能未挂起，只是执行线程在执行耗时的操作未返回，此时可做thread dump进一步分析执行线程执行什么操作.
如果ping不通，则说明服务器确实挂起.
 
②查看执行线程队列，查看空闲线程数，如果线程数为空,查看每个线程是否正常处理，如都卡在某一个请求上，则此请求对应的操作可能有问题，在执行耗时操作。如果确实是高并发引起的，则考虑增大执行线程数;如果线程数仍有空闲，则问题可能发生在socket reader线程池上，可能socket reader未配置使用本地性能包或者确实由于高并发请求引起。
 
weblogic宕机
⒈表现现象
进入控制台查看server实例状态，是SHUTDOWN状态
⒉分析服务器宕机的原因
问题名称 问题描述 不正常工作部分
硬件问题 如磁盘损坏、CPU烧起来等  
非法访问地址错误 如JVM自身bug导致访问地址出错
OOM内存溢出问题 应用程序导致内存溢出  
…… 很多原因  

 
硬件问题不可避免，如果出现此问题，只能修复或者更换；
非法访问地址错误涉及到的可能是系统级的错误，我没能力分析，各位可以补充下。
OOM问题是我们应用中导致宕机的主要原因，下面将针对OOM主要分析。
⒊ OOM宕机问题分析排查
⑴ threaddump 和heapdump分析
服务器宕机的时候一般都会产生javacore和heapdump文件，我们最直接的可以拿来分析，javacore是关于CPU当前运行堆栈等相关信息 ，heapdump是目前内存的使用情况，两者结合起来分析，可以看出哪个点上导致了内存溢出，如果在这个点上确实加载了大量的数据并且创建大量对象，那么可以在这个点上做优化
 
⑵内存泄露分析
如果在上一步骤中发现近段时间没有加载大数据，那么就有可能是内存泄露问题。内存泄露是比较难跟踪的，需要比较深入分析。以下给出一个简单的分析步骤:
 
u       GC日志分析:
垃圾回收日志(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日志分析工具，这里推荐使用
IBM Pattern Modeling and Analysis Tool for Java Garbage Collector
回收前和回收后没有发生多大变化，或者回收后一直呈上升趋势，那么基本可以判定发生了内存泄露
u       内存泄露持续跟踪工具
如果在上面的GC日志分析中看到内存发生了泄露，那么下一步就需要定位到底是哪个地方内存发生了泄露。首先检查所有的集合、容器对象，如是否定义了全局的对象数组、对象列表、MAP，在操作这些数组、列表的时候，是否将不用的集合里的引用置为空等。
如果通过上面无法定位，那么这里推荐一款java 系统监控分析的软件Jprofile
（jprofile官方上说支持AIX,不过我在AIX5.3运行，总是报
 JVMCI158: Can't load "libjprofiler.a", because load ENOENT on shared library(s)
错误，不知道有哪位高手试成功过，请告知下）
Jprofile的使用请参考相关附件资源.
查看Jprofile分析报告，可以定位到哪个地方发生内存泄露