中间件Weblogic管理监控注意事项

Weblogic监控的目的：发现系统中的隐患及系统运行是否稳定。主要从以下几方面进行检查：

一、 操作系统：

检查系统cpu、内存等使用是否异常。如在负载不大的情况下，cpu是否一直居高不下，内存占用是否一直很大。可以通过top(topas)、vmstat、free –m、ps等命令查看。

如果r经常大于4，且id经常少于40，表示cpu的负荷很重。

如果pi，po长期不等于0，表示内存不足。

如果disk经常不等于0，且在b中的队列大于3，表示io性能不好。

1.)如果在processes中运行的序列(process r)是连续的大于在系统中的CPU的个数表示系统现在运行比较慢,有多数的进程等待CPU。

2.)如果r的输出数大于系统中可用CPU个数的4倍的话,则系统面临着CPU短缺的问题,或者是CPU的速率过低,系统中有多数的进程在等待CPU,造成系统中进程运行过慢。

3.)如果空闲时间(cpu id)持续为0并且系统时间(cpu sy)是用户时间的两倍(cpu us)系统则面临着CPU资源的短缺。

解决办法:

当发生以上问题的时候请先调整应用程序对CPU的占用情况.使得应用程序能够更有效的使用CPU.同时可以考虑增加更多的CPU.  关于CPU的使用情况还可以结合mpstat,  ps aux top  prstat –a等等一些相应的命令来综合考虑关于具体的CPU的使用情况,和那些进程在占用大量的CPU时间.一般情况下，应用程序的问题会比较大一些.比如一些sql语句不合理等等都会造成这样的现象.

内存问题现象:

内存的瓶颈是由scan rate (sr)来决定的.scan rate是通过每秒的始终算法来进行页扫描的.如果scan rate(sr)连续的大于每秒200页则表示可能存在内存缺陷.同样的如果page项中的pi和po这两栏表示每秒页面的调入的页数和每秒调出的页数.如果该值经常为非零值,也有可能存在内存的瓶颈,当然,如果个别的时候不为0的话,属于正常的页面调度这个是虚拟内存的主要原理.

解决办法:

1.调节applications & servers使得对内存和cache的使用更加有效.

2.增加系统的内存.

3. Implement priority paging in s in pre solaris 8 versions by adding line "set priority paging=1" in /etc/system. Remove this line if upgrading from Solaris 7 to 8 & retaining old /etc/system file.

关于内存的使用情况还可以结ps aux top  prstat –a等等一些相应的命令来综合考虑关于具体的内存的使用情况,和那些进程在占用大量的内存.一般情况下，如果内存的占用率比较高,但是,CPU的占用很低的时候,可以考虑是有很多的应用程序占用了内存没有释放,但是,并没有占用CPU时间,可以考虑应用程序,对于未占用CPU时间和一些后台的程序,释放内存的占用。

二、 网络：

1、位于一个domain中各个服务器是否能够联通。

2、weblogic服务器与数据库服务器的链接是否畅通。

三、 Weblogic

1、检查是否对jvm进行了优化，如最大堆内存、最小堆内存，以及gc算法是否合理。

2、检查gc是否正常

主要是通过weblogic控制台，查看jvm的空闲内存的变化情况，每次gc的回收情况。特别是可以在控制台强制垃圾回收，看看回收的内存是否太小。如果回收的内存太小，说明可能存在内存益处的隐患。

3、检查线程数

通过weblogic控制台可以查看线程数的统计信息。weblogic9及以上的线程是自优化的。但应该查看系统的线程最大数是否过大，如果过大，就要注意系统为什么会有这么大的压力。如下为示例截图

Active Execute Threads：在活动的线程池内处理请求的线程个数

Execute Thread Total Count：线程池内线程的总数

Execute Thread Idle Count：池内的空闲线程数。它不包含stuck和standby的线程数。它是指等待接收新请求到来并处理的线程个数

queue length ：请求队列的长度，及队列中等待线程处理的请求的个数

hogging thread count ：线程处理一个请求时间超过一定值被视为hogging状态，如果继续处理请求超过一定时间将被视为stuck，或处理完请求后被放回线程池

standby thread count ：统计在standby（备用）线程池内的线程数。这些线程不需要处理当前请求被放入standby池内，当活动的线程池内需要更多线程时，这些线程将被激活。

Execute Thread Total Count= Active Execute Threads+ standby thread count

4、线程是否有stuck状态的。

  线程stuck状态说明存在超时的线程，也有可能存在线程的死锁。在查看线程数的时候，查看Health一栏，如果出现Warning则代表有stuck（阻塞线程），就要查看系统的运行状态，jvm等的状态是否正常，内存使用率等。立即做thread dump得到当前虚拟机下线程活动快照，就可以分析服务器线程之间是否存在死锁，以及哪些线程处于stuck状态。

产生thread dump，可以通过命令ps –ef | grep java 列出所有java进程即启动的所有的weblogic server进程，找到有线程阻塞的进程号wls_pid，然后使用kill -3 wls_pid得到thread dump。通常thread dump会被输入到标准输出中，如果用nohup后台方式启动则会出现在nohup.out或重命名的文件中 。如果是windows环境则在dos标准输出窗口中用“ctrl+break”组合键获取thread dump。

5、jdbc连接池

检查连接池中等待连接的数目是否过大，可以做适当调整。如果用户访问系统变慢，且连接池基本占满，但是weblogic的线程数量很少，就要怀疑应用是否没有释放数据库连接。如下为监控数据库连接池截图示例：

查找连接泄露点的方法：如下图所示选中数据源，点击Configuration->Diagnostics，把Profile Connection Leak前打上√即可。当再次出现连接池泄漏时查看server日志便可找到具体发生泄露的代码，并加以改正，通常打上finally块，关闭连接。

四、 系统日志

通过系统的日志分析weblogic服务器及应用程序出现的错误，找到可能影响系统性能的服务器和应用的地方。举例如下：

1、已经对用户进行响应

java.lang.IllegalStateException: Cannot forward a response that is already committed

at weblogic.servlet.internal.RequestDispatcherImpl.forward(Request

    DispatcherImpl.java:110)

at com.qtong.hebmc.ExceptionFilter.doFilter(ExceptionFilter.java:55)

如上异常，为什么对用户的response已经提交给用户了，就要怀疑代码中某些地方在过滤器过滤之前已经显示的提交或关闭了对用户的响应的outputstream。有些时候在过滤器中要做后续的一些处理，这时候filter中出现异常，有可能导致数据库连接不释放及一些后续的处理得不到执行。

2、线程一直处于stuck状态

STUCK] ExecuteThread: '32' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "632" seconds working on the request "Http Request: /stat/test/TestCtrl.statOracleTest.do", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.

这句表名线程32执行时间超过600秒设定的时间。检查这个请求是否会导致线程执行超时，是否是长时间的处理。当前系统状态是否正常，是否是cpu、内存等资源不足导致的线程执行缓慢。

重要的一点要查看线程32是否变成unstuck状态。否则就有可能出现线程死锁。

unstuck".>

3、数据库连接问题

java.sql.SQLException: [BEA][Oracle JDBC Driver]Error establishing socket to host and port: dbnew2_vip:1521. Reason: Connection refused

当出现此问题时，一般系统都执行缓慢。检查是否ping通数据库，是否有权限，也可以请数据库工程师查看数据库是否运行正常。检查dns服务器或本地dns映射是否正常，域名dbnew2_vip能否解析。

4、检查Weblogic记录的Error级别的日志。找到可能影响系统运行及功能的问题。

如：#### Error> > <> <> 肃移动equest parsing failed, Code: -1>

此出，说明线程1执行请求“/service/js/mareal/mareal.肃移动

”的时候，weblogic对这个请求解析失败，可以请工程师修改请求的格式，以免影响应用的功能。

5、class文件找不到

java.lang.ClassNotFoundException: com.qtong.hebmc.controller.js.mareal.mareal.jobile.com.service.LoginCtrl

at java.lang.Class.forNameImpl(Native Method)

at java.lang.Class.forName(Class.java:130)

at com.mareal.sterna.Controller.parseController(Controller.java:67)

... 20 more

检查控制器是否书写正确，还是这个java文件没有正确编译部署。

6、邮件服务器异常

org.apache.commons.mail.EmailException: Sending the email to the following server failed : 218.207.67.75:25

Caused by:

javax.mail.MessagingException: Could not connect to SMTP host: 218.207.67.75, port: 25;

  nested exception is:

java.net.SocketException: Connection timed out:could be due to invalid address

检查邮件服务器是否有问题，ip是否冲突，网络连接是否正常，以免影响应用的功能。

7、是否是算法的bug导致的oom。如下：

java.lang.OutOfMemoryError: Initializing Writer

at com.sun.imageio.plugins.jpeg.JPEGImageWriter.initJPEGImageWriter(Native Method)

at com.sun.imageio.plugins.jpeg.JPEGImageWriter.(JPEGImageWriter.java:206)

at com.sun.imageio.plugins.jpeg.JPEGImageWriterSpi.createWriterInstance(JPEGImageWriterSpi.java:130)

at javax.imageio.spi.ImageWriterSpi.createWriterInstance(ImageWriterSpi.java:358)

at javax.imageio.ImageIO$ImageWriterIterator.next(ImageIO.java:851)

at javax.imageio.ImageIO$ImageWriterIterator.next(ImageIO.java:835)

at javax.imageio.ImageIO.write(ImageIO.java:1473)

at javax.imageio.ImageIO.write(ImageIO.java:1554)

at com.qtong.hebmc.controller.LoginCtrl.smsRandomPic(LoginCtrl.java:267)

... 21 more

应该查看com.sun.imageio.plugins.jpeg.JPEGImageWriter是否存在bug，处理大图片时，是否会导致oom。可以上sun管网查看。

8、低级字符越界异常

java.lang.StringIndexOutOfBoundsException

at java.lang.String.substring(String.java:1088)

at com.qtong.hebmc.controller.nethall.ChongZhiKaChaXunCtrl.transact

     (ChongZhiKaChaXunCtrl.java:25)

强烈建议工程师避免这种问题。