- 论坛徽章:
- 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企业级运维实战中均有具体阐述） |
|
免费注册
楼主: 无风之谷
发表于 2012-02-19 10:37
