- 论坛徽章:
- 0
|
回复 62# huanglao2002
从日常的运维监控角度来说,个人认为几个方面值得关注:
操作系统,网络,WebLogic,系统日志
操作系统:
检查系统cpu、内存等使用是否异常。如在负载不大的情况下,cpu是否一直居高不下内存占用是否一直很大,硬盘空间是否写满(对于服务器,通常可能性不大)。可以通过top(topas)、vmstat、iostat、netstat、free –m、ps、df、du等命令查看。
网络:
检测位于一个domain中各个服务器是否能够联通,以及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状态。
5.JDBC连接池
检查连接池中等待连接的数目是否过大,可以做适当调整。如果用户访问系统变慢,且连接池基本占满,但是weblogic的线程数量很少,就要怀疑应用是否没有释放数据库连接。
系统日志
这是最常用到的查错方法,一般情况下,看到日志中有明显错误是值得庆幸的,这样可以直接根据问题寻求答案。
还有一点要提到的是日志的输出方式最好是根据业务来定,以免造成日志冗余,占用大量磁盘空间。
关于监控,ibm,quest(如foglight)等公司都有相应的对WebLogic的监控工具,但主要是集中在对jvm的管理监控上,相对来说比较智能。当然在sun,jrockit得较高版本的jdk中都有集成相应的监控工具(如jconsole等。。)
以上只是个人的浅见,希望对您有所帮助(ps:我看了一下,您的这些问题以及常见的监控手段在WebLogic企业级运维实战中均有具体阐述) |
|