Wls_weblogic管理监控.docxVIP

中间件Weblogic管理监控注意事项Weblogic监控的目的：发现系统中的隐患及系统运行是否稳定。主要从以下几方面进行检查：操作系统：检查系统cpu、内存等使用是否异常。如在负载不大的情况下，cpu是否一直居高不下，内存占用是否一直很大。可以通过top(topas)、vmstat、free –m、ps等命令查看。网络：1、位于一个domain中各个服务器是否能够联通。2、weblogic服务器与数据库服务器的链接是否畅通。Weblogic1、检查是否对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 count4、线程是否有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 committedat ernal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:110)at com.qtong.hebmc.ExceptionFilter.doFilter(ExceptionFilter.java:55)如上异常，为什么对用户的response已经提交给用户了，就要怀疑代码中某些地方在过滤器过滤之前已经显示的提交或关闭了对用户的响应的outputstream。有些时候在过滤器中要做后续的一些处理，这时候filter中出现异常，有可能