Weblogic 常见问题维护

prexim

贡献于2013-05-06

字数:3368 关键词: 应用服务器 WebLogic

Weblogic常见问题维护 出现java.lang.OutOfMemoryError异常提示 对于不明原因的挂起最好获取thread dump信息,对于windows系统,在运行java的窗口按Ctrl+Break,对于unix系统,首先用ps找到运行weblogic的java进程的pid,然后执行kill –3 pid 注意:最好间隔10sec获取一次。 在补充一下: 对于thread dump信息,主要关注的是线程的状态和其执行堆栈 线程的状态一般为三类 A.Runnable(R):当前可以运行的线程 B.Waiting on monitor(CW):线程主动wait C.Waiting for monitor entry(MW):线程等锁 一般关注的都是第一和第三种状态的线程 Cpu很忙则关注runnable的线程 Cpu闲则关注waiting for monitor entry的线程 一种典型的死锁是由于在server端应用(比如servlet)中请求由同一weblogic实例serve的资源 解决办法就是将该servlet放到另外的执行队列里去执行。 WEblogic 调优方案 WebLogic Server Hang产生的原因一般为: 系统内存不足 系统cpu忙 系统文件描述符数目不足 线程死锁 JVM有GC方面的bug 对于一些特定的情况可以使用truss命令跟踪系统调用来进行分析 系统内存不足 出现OutOfMemoryError或是观察到内存吃紧 操作系统本身的剩余内存 通过top或是vmstat观察 操作系统的swap区 Swap区太小可能导致编译jsp时报“Not enough space”的错 操作系统kernel参数中maxdsiz的大小 如果观测到数据库连接池里的连接泄漏,极可能是内存泄漏的先兆 系统内存不足 JVM的heap区大小 通过java命令行中的-Xms,-Xmx指定,建议最小值和最大值设成一样 可以通过weblogic console上server/monitor/performance来观察其使用情况 建议生产系统最少256M,一般情况下可以设置为系统剩余物理内存的80% Heap size太大在一些jvm上会有问题 对于sun和hp的jvm,permanent size太小也会出OutOfMemoryError 在java命令行上加-XX:MaxPermSize=128m 系统内存不足 尽量减少内存消耗 Session中不要放大的数据,并尽量在不再需要的时候remove掉;如果可以调整session timeout到较小的值 避免在J2EE server端应用里边调用awt/swing作图 调整ejb的cache/pool设置 系统内存不足 内存泄漏 可以通过weblogic console来观察jvm的heap memory使用情况来获知是否有内存泄漏情况 采用第三方辅助工具来获取更详细信息 Jprobe/OptimizeIt 系统cpu忙 如果用户访问量很大,cpu占用很高(user态)并不是异常 如果是kernel态很多,需要OS厂商调整操作系统 采用top找到占用cpu很多的进程 如果是非weblogic进程,应该考虑将其移到另外的server上运行 如果是运行weblogic的java进程,通过做thread dump(详细信息后边会介绍到)来确认是那段代码导致了这么高的cpu使用(也有可能是os/jvm本身不正常) 系统文件描述符数目不足 Log中有“too many open files”的错误 表示达到了系统对一个进程能同时打开的文件数的限制 ulimit –a –H 可以查看当前限制 ulimit –n number可以来更改当前环境的设置,建议至少设到4096 Solaris上可以通过/usr/proc/bin/pfiles pid来查看指定进程的限制和当前使用的file descriptor数目 Solaris上root用户可以通过/usr/proc/bin/plimit -n soft,hard pid 来动态更改进程的文件描述符的限制 线程死锁 对于原因不明的hang或是响应慢,最根本的方法就是获取thread dump信息 对于windows系统,在运行java的窗口按Ctrl+Break 对于unix系统,首先用ps找到运行weblogic的java进程的pid,然后执行kill –3 pid JVM将负责将所有java进程的状态、执行堆栈dump到其标准输出 为了方便获取thread dump信息,在weblogic启动的时候,最好将其标准输出重定向到一个文件 为了反映线程状态的动态变化,需要接连多次做thread dump,每次间隔10-20s 线程死锁 对于thread dump信息,主要关注的是线程的状态和其执行堆栈 线程的状态一般为三类 Runnable(R):当前可以运行的线程 Waiting on monitor(CW):线程主动wait Waiting for monitor entry(MW):线程等锁 一般关注的都是第一和第三种状态的线程 Cpu很忙则关注runnable的线程 Cpu闲则关注waiting for monitor entry的线程 一种典型的死锁是由于在server端应用(比如servlet)中请求由同一weblogic实例serve的资源 解决办法就是将该servlet放到另外的执行队列里去执行 JVM有GC方面的bug 打开jvm的gc log 在java命令行上加上-verbose:gc GC的log输出在java进程的标准输出里 在hp的jvm上,可以通过在java命令行上加 -Xverbosegc:file=gcfilename来将gc log写到指定的文件 其输出类似: [GC 15639K->13700K(65280K), 0.0068439 secs] 调整jvm的内存设置和gc算法 升级jvm或是os patch mit –n number可以来更改当前环境的设置,建议至少设到4096 Solaris上可以通过/usr/proc/bin/pfiles pid来查看指定进程的限制和当前使用的file descriptor数目 Solaris上root用户可以通过/usr/proc/bin/plimit -n soft,hard pid 来动态更改进程的文件描述符的限制 线程死锁 对于原因不明的hang或是响应慢,最根本的方法就是获取thread dump信息 对于windows系统,在运行java的窗口按Ctrl+Break 对于unix系统,首先用ps找到运行weblogic的java进程的pid,然后执行kill –3 pid JVM将负责将所有java进程的 (1)weblogic 可以设置-Xms(最小使用内存) -Xmx(最大使用内存),-XX:MaxPermSize 最大使用内存:对于UNIX而言,一般不应超过物理内存的75%; 对于Windows, 一般不应超过物理内存的50%; -XX:MaxPermSize 一般应为ms(最大使用内存)的一半; 停止weblogic服务方法: 1.在BEA安装目录下:\bea\user_projects\domains\你应用程序目录名里,有这样的stopWebLogic.cmd,stopWebLogic.sh文件,windows用户请双击stopWebLogic.cmd,Unix 或Linux 用户请双击stopWebLogic.sh文件就可以了. 2.windows用户按 CTRL+C 3.Unix 或Linux 用户请按 CTRL+D 4.还可以在启动weblogic服务后,通过http://localhost:7001/console 来进行复杂的管理. 监视WebLogic域 监视WebLogic域的健康状况和性能的工具是管理控制台。通过控制台,你可以观察到WebLogic资源的状态和统计信息,如服务器,HTTP,JTA 子系统,JNDI,安全,CORBA连接池,EJB,JDBC以及JMS。 举个例子,在Server――>Monitoring――>Performance为当前服务器实例提供了与等待和运行状态的请求有关的性能参考。它包括下列信息: n         队列中空闲线程数。 n         队列中等待时间最长的请求。 n         吞吐量,根据已经处理的请求数来衡量的。 n         队列长度,根据队列中等待请求数来衡量的。 n         JVM堆还有的内存量。

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 3 金币 [ 分享文档获得金币 ]
1 人已下载

下载文档

相关文档