weblogic日常维护总结与故障诊断Word文档格式.docx
《weblogic日常维护总结与故障诊断Word文档格式.docx》由会员分享，可在线阅读，更多相关《weblogic日常维护总结与故障诊断Word文档格式.docx（12页珍藏版）》请在冰豆网上搜索。
F、程序EJB/WebModule（域-部署）；
状态为活动，健康状况为ok。
其目标关联正确
G、JMS（域-服务-消息传送-JMS服务器）；
健康状态为ok。
4、在控制台生成dump；
生成DumpThreadStacks内容；
查找queryList等关键字符，即可快速定位问题代码。
5、如果控制台打不开或无法进入，就要先看进程有没有在跑，如果进程有，但控制台或程序无法进入，一般就是有故障了，此时，可以通过相关日志进行后台分析分析。
三、后台日志分析：
一般来说，新建立的环境，配置的问题多一点；
已经运行的生成系统错误或bug的可能性大点。
当出现故障时，就可以调取系统日志、中间件的日志，根据相关关键字（BEA-）网上搜索，或到官方网站对相关问题的描述进行查找。
WebLogic在启动及运行过程中会记录各种LOG信息，以帮助系统治理员对整个应用系统进行治理及维护。
1、log默认位置
..\user_projects\domains\your_domain\servers\AdminServer\logs下面的;
;
新版的如：
C:
\Oracle\Middleware\user_projects\domains\base_domain\servers\AdminServer\logs
如果是重定向输出的，就看重定向输出的文件。
2、日志文件说明
WebLogicSERVER运行日志
假如WebLogicSERVER在启动或运行过程中有错误发生，错误信息会显示在屏幕上，并且会记录在一个LOG文件中，该文件默认名为。
该文件也记录WebLogic的启动及关闭等其他运行信息。
可在Gernal属性页中设置该文件的路径及名字，错误的输出的等级等。
HTTP访问日志
在WebLogic中可以对用HTTP，HTTPS协议访问的服务器上的文件都做记录，该LOG文件默认的名字为,内容如下，该文件具体记录在某个时间，某个IP地址的客户端访问了服务器上的那个文件。
DOMAIN运行日志
记录一个DOMIAN的运行情况，一个DOMAIN中的各个WebLogicSERVER可以把它们的一些运行信息（比如：
很严重的错误）发送给一个DOMAIN的ADMINISTRATORSERVER上，ADMINISTRATORSERVER把这些信息些到DOMAIN日志中。
默认名为：
。
一般就看这个最多。
3、通过控制台查看或修改系统日志路径
登录weblogic后台
左侧菜单：
Environment->
Servers
右侧菜单：
AdminServer（admin）->
logging
只找到、
配置如图:
4、其他
如果日志太少，里面没有记载相关信息，可参照日志文件的回滚设置。
在“滚动类型:
”属性页中可以设置这些日志文件的回滚方式，当日志文件到一定得大小或过了设定的时间后，把日志信息保存到一个新的文件中。
WebLogic提供按文件大小和时间两种方式。
如下面的设置种，选择RotationType为BYSIZE。
也就是当日志文件的大小达到500K时，重新写一个新的文件。
假如RotationType为BYTIME，那么是每隔一段时间重新写一个新的文件。
并且对这些文件编号设置日志文件名如：
_%yyyy%_%MM%_%dd%_%hh%_%mm%
5、日志的处理：
查看日志中输出的具体内容，再进行处理。
如：
BEA-
下面是一个线程阻塞的一个信息
2011-8-13上午03时51分46秒
四、产生hreadDump来分析问题
hreadDump是非常有用的诊断Java应用问题的工具，每一个Java虚拟机都有及时生成显示所有线程在某一点状态的thread-dump的能力。
虽然各个Java虚拟机threaddump打印输出格式上略微有一些不同，但是Threaddumps出来的信息包含线程；
线程的运行状态、标识和调用的堆栈；
调用的堆栈包含完整的类名，所执行的方法，如果可能的话还有源代码的行数。
ThreadDump特点：
能在各种操作系统下使用
能在各种Java应用服务器下使用
可以在生产环境下使用而不影响系统的性能
可以将问题直接定位到应用程序的代码行上
ThreadDump能诊断的问题包括：
查找内存泄露，常见的是程序里load大量的数据到缓存
发现死锁线程
收集ThreadDump
进行ThreadDump的方法取决于安装挂起服务器实例的操作系统。
有关在不同的操作系统上进行ThreadDump的信息，
SolarisOS
<
ctrl>
-’\’（Control-Backslash）
kill-QUIT<
pid>
Linux
Linux操作系统查看线程的方式不同于其它操作系统。
该操作系统将每个线程视为一个进程。
若要在Linux上进行ThreadDump，查找通过其启动所有其它进程的进程ID。
使用命令：
若要获得根PID，使用：
ps-efHl|grep'
java'
**.**
使用一个作为字符串的grep参数（可在与服务器启动命令匹配的进程堆栈中找到该字符串）。
如果ps命令还没有管道传送到另一个例程，则报告的第一个PID将是根进程。
IBMAIX
在AIX上用IBM的JVM，内存溢出时默认地会产生javacore文件（关于cpu的）和heapdump文件（关于内存的）。
执行kill-3<
命令可以生成javacore文件和heapdump文件（pid为wasjava进程的id号，可以用ps-ef|grepjava查到），可以多执行几次。
有些Java应用服务器是在控制台上运行，如Weblogic，为了方便获取threaddump信息，在weblogic启动的时候，最好将其标准输出重定向到一个文件，用"
nohupsh>
&
"
命令，执行"
kill-3<
，Stacktrace就会输出到里。
为了反映线程状态的动态变化，需要接连多次做threaddump，每次间隔10-20s。
Windows、XP、NT
设置DOS窗口的属性：
Layout->
ScreenBufferSize->
Height9999。
同时按下CTRL-BREAK
找到ThreadDump的最开始的位置：
Fullthreaddump."
每个服务器需要<
Ctrl>
-<
Break>
来创建诊断问题所需的ThreadDump。
确保在每个服务器上执行几次，每次间隔大约5到10秒，以帮助诊断死锁问题。
在NT上，在命令shell中输入CTRL-Break。
获取失败时刻的获取失败时刻的ThreadDump
启动JVM时，加入参数：
SunJVM:
-XX:
+ShowMessageBoxOnE
JRockitJVM:
五、
常见的问题
1、OutofMemory
当JVM没有足够的内存执行任务时，会触发
当没有更多内存可以分配时
或空闲的内存有太多碎片，无法利用时
可能不足的内存类型有可能不足的内存类型有：
：
Native（物理内存）
Heap（堆内存）
特定Java内存代（例如，permanet）
对OutofMemory的响应的响应
JVM会发送error到标准输出流和错误输出流
WLS会将应用程序没有处理的Java异常和错误都输出
到服务器日志
Out-of-Memory和类似的系统错误不应该由应用程序直
接处理接处理
如果应用程序发生错误，会给客户端返回错误信息（
例如HTTP500）
如果WLS子系统发生错误，则服务器处于不稳定状态
，需要重启
内存泄漏内存泄漏
内存泄漏：
最常见的引发Out-of-Memory错误的原因
在Java中，内存泄漏并不常发生（相对传统语言）
内存泄漏的原因是当对象不再被需要时，没有显式声明，进而
没有被垃圾回收处理
常见的场景有：
太大的缓存造成内存泄漏
太多使用HTTP会话，导致内存泄漏
对数据库操作结束时，没有正常关闭数据集及数据连接
动态类加载问题
错误日志错误日志
该日志文件通常包括如下类型的信息：
操作系统错误消息
JVM版本
硬件和操作系统参数
系统环境变量
堆和垃圾回收汇总
线程汇总
Runtimedataarea主要包括五个部分：
Heap（堆）,MethodArea（方法区域）,JavaStack（java的栈）,ProgramCounter（程序计数器）,Nativemethodstack（本地方法栈）。
Heap和MethodArea是被所有线程的共享使用的；
而Javastack,Programcounter和Nativemethodstack是以线程为粒度的，每个线程独自拥有。
Heap
Java程序在运行时创建的所有类实或数组都放在同一个堆中。
而一个Java虚拟实例中只存在一个堆空间，因此所有线程都将共享这个堆。
每一个java程序独占一个JVM实例，因而每个java程序都有它自己的堆空间，它们不会彼此干扰。
但是同一java程序的多个线程都共享着同一个堆空间，就得考虑多线程访问对象（堆数据）的同步问题。
Methodarea
在Java虚拟机中，被装载的class的信息存储在Methodarea的内存中。
当虚拟机装载某个类型时，它使用类装载器定位相应的class文件，然后读入这个class文件内容并把它传输到虚拟机中。
紧接着虚拟机提取其中的类型信息，并将这些信息存储到方法区。
该类型中的类（静态）变量同样也存储在方法区中。
与Heap一样，methodarea是多线程共享的，因此要考虑多线程访问的同步问题。
比如，假设同时两个线程都企图访问一个名为Lava的类，而这个类还没有内装载入虚拟机，那么，这时应该只有一个线程去装载它，而另一个线程则只能等待。
Javastack
Javastack以帧为单位保存线程的运行状态。
虚拟机只会直接对Javastack执行两种操作：
以帧为单位的压栈或出栈。
每当线程调用一个方法的时候，就对当前状态作为一个帧保存到javastack中（压栈）；
当一个方法调用返回时，从javastack弹出一个帧（出栈）。
栈的大小是有一定的限制，这个可能出现StackOverFlow问题。
下面的程序可以说明这个问题。
publicclassTestStackOverFlow{
publicstaticvoidmain（String[]args）{
Recursiver=newRecursive（）;
（10000）;
}
}
classRecursive{
publicintdoit（intt）{
if（t<
=1）{
return1;
}
returnt+doit（t-1）;
？
Programcounter
每个运行中的Java程序，每一个线程都有它自己的PC寄存器，也是该线程启动时创建的。
PC寄存器的内容总是指向下一条将被执行指令的饿&
ldquo;
地址&
rdquo;
，这里的&
可以是一个本地指针，也可以是在方法区中相对应于该方法起始指令的偏移量。
Nativemethodstack
对于一个运行中的Java程序而言，它还能会用到一些跟本地方法相关的数据区。
当某个线程调用一个本地方法时，它就进入了一个全新的并且不再受虚拟机限制的世界。
本地方法可以通过本地方法接口来访问虚拟机的运行时数据区，不止与此，它还可以做任何它想做的事情。
比如，可以调用寄存器，或在操作系统中分配内存等。
总之，本地方法具有和JVM相同的能力和权限。
（这里出现JVM无法控制的内存溢出问题nativeheapOutOfMemory）
旧系统
2、服务器挂起
问题描述
在出现以下情况时怀疑服务器挂起：
服务器不响应新的请求。
请求超时。
请求处理的时间越来越长（其最终结果可能是挂起）。
通常，服务器挂起不会表现为服务器崩溃，但服务器挂起之后可能会崩溃。
资源濒临枯竭：
内存、工作线程、数据库连接池…
故障排除
请注意，并非下面所有任务都需要完成。
有些问题仅通过执行几项任务就可以解决。
快速链接：
为什么发生此问题
服务器挂起的可能原因
基本步骤
已知的WebLogicServer问题
收集ThreadDump
ThreadDump分析
为什么发生此问题
服务器挂起有多种原因。
一般而言，服务器挂起是因为缺少某种资源。
缺少资源会阻止服务器响应服务请求。
例如，由于故障（死锁）或者大量请求的缘故，可能没有任何可用的执行线程来完成工作，所有执行线程都被占用或忙于处理以前的请求。
引起引起ServerHang的原因的原因
工作线程太少
垃圾回收占用时间太多
JVM代码优化问题
应用程序死锁
JDBC死锁
RemoteJNDIlookups
JSP编译
JSP不正确的设置：
PageCheckSeconds
JVMbug
服务器挂起的可能原因
主题模式名称链接
RMI、RJVM响应－所有绑定线程等待RJVM、RMI响应。
EJB_RMI服务器挂起EJB_RMI服务器挂起
应用程序死锁－线程锁定资源1，然后等待锁定资源2。
另一个线程锁定资源2，然后等待锁定资源1。
应用程序死锁导致服务器挂起待定
线程全部被占用，没有线程可用于新工作。
线程占用导致服务器挂起待定
垃圾回收花费太多时间。
垃圾回收导致服务器挂起待定
servlet时间的JSP错误设置，比如PageCheckSeconds。
JSP导致服务器挂起待定
死锁造成JDBC挂起。
JDBC中的服务器挂起待定
（代码优化）过程中的JVM挂起类似于服务器挂起。
代码优化中服务器挂起待定
在大量负载情况下JSP编译造成服务器挂起。
JSP编译导致服务器挂起待定
SUNJVM错误，比如轻量型线程库。
SunJVM错误导致服务器挂起待定
返回页首
基本步骤
当服务器挂起时，首先使用javat3:
0x96afdc4]
at
确定“Default”ExecuteThread队列是否超载。
利用控制台确定“Default”队列中的所有ExecuteThreads是否空闲。
如果没有一个空闲，则应用程序可能需要一个更大的ExecuteThread数来配置。
可以通过控制台更改该值，并将其保存在文件中。
如果执行队列有空闲线程，则可能没有分配足够的SocketReader线程。
缺省情况下，WebLogicServer实例在启动时创建三个SocketReader线程。
如果群集系统在高峰期使用的SocketReader线程超过三个，则增加SocketReader线程的数量。
通常，SocketReader线程的数量应当较小。
但是，如果WeblogicServe充当正在挂起的服务器实例的客户端，则应当为每个WeblogicServe配置一个线程。
如果使用JDBC连接池，确保池中已经配置的JDBC连接数量与同时请求（即执行线程）的数量相等。
已知的WebLogic问题
JDBC产生死锁问题的可能性存在。
检查在开头找到的服务器的版本和ServicePack级别。
然后对已经应用于服务器类路径的所有临时修补程序检查以上版本和ServicePack行。
修补程序将指明已经解决了什么问题。
ThreadDump分析
分析服务器挂起的最有用的工具是一系列ThreadDump。
ThreadDump提供关于每个线程在特定时刻正在执行什么操作的信息。
一系列ThreadDump（一般每隔5到10秒进行三个或更多ThreadDump）可以帮助分析每个线程从一个ThreadDump到另一个ThreadDump过程中的状态变化或所缺少的变化。
挂起服务器ThreadDump一般显示线程状态从第一个ThreadDump到最后一个ThreadDump中变化很小。
在ThreadDump中查看的内容
所有请求都通过ListenThread进入WebLogicServer。
如果ListenThread丢失，就无法接收任何工作，因此也无法完成任何工作。
确认在ThreadDump中存在ListenThread。
ListenThread应当在socketAccept方法中。
下面示例说明监听线程（ListenThread）的形式。
SocketReader线程接受来自监听线程队列的传入请求，并将该请求放入执行线程队列。
如果ThreadDump中没有SocketReader线程，则在某个地方存在导致SocketReader线程消失的错误。
应当始终保持至少有三个SocketReader线程。
一个SocketReader线程一般用于轮询功能，另外两个用于处理请求。
下面是一个ThreadDump示例中的SocketReader线程。
ThreadPoolPercentSocketReaders属性设定要用于从javaSocket中读取消息的执行线程的最大百分比。
此属性的最佳值是针对应用程序设定的。
缺省值为33，有效范围是1到99。
分配执行线程充当SocketReader线程可提高服务器接受客户端请求的速度和能力。
必须平衡专门用于从Socket读取消息的执行线程和那些在服务器中执行实际运行任务的线程的数量。
后续步骤
后续步骤要求进一步分析ThreadDump。
检查ThreadDump，了解每个线程在服务器挂起时正在执行的操作。
这有助于分析下一个探查阶段。
例如，如果JSP编译中涉及许多线程，参考服务器挂起的可能原因一节可了解进一步的诊断和测试操作。
PingServe
java-urlt3:
PING起时仍有空闲的挂起时仍有空闲的Execute线程线程
挂起时仍有空闲的挂起时仍有空闲的线程线程
确定SocketReade线程都在正常工作。
适当提高SocketReader线程数。
集群环境下需要更多的SocketReader线程。
2.挂起时没有空闲的挂起时没有空闲的Execute线程线程
挂起时没有空闲的挂起时没有空闲的线程线程
确定所有线程都在正常工作，没有死锁等现象。
为耗时较长的请求创建单独的请求队列。
增加资源：
应用检查
EJBRMIcalls
JSPcalls
其它检查
垃圾回收
代码优化
JVMbugs
JSP编译问题
dump分析工具heapAnalyzer
升级会员 