1. 典型现象
（1）响应时间越来越长。
（2）响应超时或没有得到响应。
（3）资源濒临枯竭：内存、工作线程、数据库连接池…
2. 产生原因
（1）threads 数量不够
（2）内存不足
（3）资源竞争
（4）垃圾回收占用时间太长
（5）程序死锁或数据库死锁
（6）某个方法调用相当耗时耗资源
3. 诊断步骤
（1）Ping Server：java weblogic.Admin –url t3://localhost:7001 –username user –password password THREAD_DUMP
如果Ping不通，说明Server确实Hang住了；如果Ping得通，说明Server没Hang住，而是应用自身Hang住了，应该检查应用。
（2）如果Hang可以重现，重启Server，加上参数：–verbosegc，打印详细GC。
看看Server Hang住时，是否在进行频繁的Full GC。
（3）观察所有execute threads的工作情况：domainName> Servers> serverName> Monitoring> General>Monitor All Active Queues> weblogic.kernel.Default
如果所有execute threads都在工作，说明这可能是导致Server Hang的原因。
如果有execute threads处在空闲状态，而Server 依然 Hang住，检查socket reader threads。
（4）每隔10秒，获取一次 Thread Dump，看看有无线程死锁情况。
4. 解决方案
4.1 如果所有execute threads都在工作，而Server Hang住
（1）增加资源：内存、工作线程、数据库连接池（数量参考execute threads）…
（2）为耗时较长的请求创建单独的execute thread queues。
（3）将耗时较长的同步操作改为异步操作，比如把操作逻辑放到Message Driven Bean中。
4.2 如果有execute threads处在空闲状态，而Server Hang住
（1）检查Socket Reader 线程，确定Socket Reader 线程都在正常工作。
（2）适当提高 Socket Reader 线程数。
（3）集群环境下需要更多的Socket Reader 线程。
5. 如何模拟Server Hang5.1 模拟4.1 的情形
（1）编写一个Java Servlet，该Servlet啥都不干，只是睡觉，并且Sleep很长时间。
（2）编写一个多线程程序，启动和execute threads数量相等的进程，每个进程都去访问上面的Servlet。
（3）Ping Server ：java weblogic.Admin -url t3://localhost:7001 -username system -password weblogic PING
由于所有execute threads都在访问该沉睡中的Servlet，没有一个空闲，Server无法Ping通。
（4）观察execute threads（这里使用的是WLS8.1）：[Server]->Monitor->General，选择Monitor all Active Queues...，选择weblogic.kernel.Default ，发现所有的execute threads都在“干同样的活”：
（5）增加和execute threads数量（这里使用的是WLS8.1）：[Server]->Configuration->General，点击 Advanced Options， 点击Configure Execute Queues选择weblogic.kernel.Default ，选择Configuration，修改Thread Count值为25，Apply 并重启Server。
出现这种情况时，增加execute threads只能解燃眉之急。为了彻底解决问题，还是需要静下心来分析Thread Dump，看看execute threads都在做什么，哪个调用时间比较长。
可以把调用时间比较长的操作（EJBs/Servlets）单独使用另一个Queue。或者可以考虑用异步操作代替时间比较长的同步操作，比如使用Message Driven Bean来实现。
5.2 模拟4.2 的情形
（1）响应时间越来越长。
（2）响应超时或没有得到响应。
（3）资源濒临枯竭：内存、工作线程、数据库连接池…
2. 产生原因
（1）threads 数量不够
（2）内存不足
（3）资源竞争
（4）垃圾回收占用时间太长
（5）程序死锁或数据库死锁
（6）某个方法调用相当耗时耗资源
3. 诊断步骤
（1）Ping Server：java weblogic.Admin –url t3://localhost:7001 –username user –password password THREAD_DUMP
如果Ping不通，说明Server确实Hang住了；如果Ping得通，说明Server没Hang住，而是应用自身Hang住了，应该检查应用。
（2）如果Hang可以重现，重启Server，加上参数：–verbosegc，打印详细GC。
看看Server Hang住时，是否在进行频繁的Full GC。
（3）观察所有execute threads的工作情况：domainName> Servers> serverName> Monitoring> General>Monitor All Active Queues> weblogic.kernel.Default
如果所有execute threads都在工作，说明这可能是导致Server Hang的原因。
如果有execute threads处在空闲状态，而Server 依然 Hang住，检查socket reader threads。
（4）每隔10秒，获取一次 Thread Dump，看看有无线程死锁情况。
4. 解决方案
4.1 如果所有execute threads都在工作，而Server Hang住
（1）增加资源：内存、工作线程、数据库连接池（数量参考execute threads）…
（2）为耗时较长的请求创建单独的execute thread queues。
（3）将耗时较长的同步操作改为异步操作，比如把操作逻辑放到Message Driven Bean中。
4.2 如果有execute threads处在空闲状态，而Server Hang住
（1）检查Socket Reader 线程，确定Socket Reader 线程都在正常工作。
（2）适当提高 Socket Reader 线程数。
（3）集群环境下需要更多的Socket Reader 线程。
5. 如何模拟Server Hang5.1 模拟4.1 的情形
（1）编写一个Java Servlet，该Servlet啥都不干，只是睡觉，并且Sleep很长时间。
（2）编写一个多线程程序，启动和execute threads数量相等的进程，每个进程都去访问上面的Servlet。
（3）Ping Server ：java weblogic.Admin -url t3://localhost:7001 -username system -password weblogic PING
由于所有execute threads都在访问该沉睡中的Servlet，没有一个空闲，Server无法Ping通。
（4）观察execute threads（这里使用的是WLS8.1）：[Server]->Monitor->General，选择Monitor all Active Queues...，选择weblogic.kernel.Default ，发现所有的execute threads都在“干同样的活”：
（5）增加和execute threads数量（这里使用的是WLS8.1）：[Server]->Configuration->General，点击 Advanced Options， 点击Configure Execute Queues选择weblogic.kernel.Default ，选择Configuration，修改Thread Count值为25，Apply 并重启Server。
出现这种情况时，增加execute threads只能解燃眉之急。为了彻底解决问题，还是需要静下心来分析Thread Dump，看看execute threads都在做什么，哪个调用时间比较长。
可以把调用时间比较长的操作（EJBs/Servlets）单独使用另一个Queue。或者可以考虑用异步操作代替时间比较长的同步操作，比如使用Message Driven Bean来实现。
5.2 模拟4.2 的情形
没有评论:
发表评论