NO.28 要你命3000-宕机问题面面观:1.最简单定位分析方法

(待完善)

一旦系统宕机，就需要尽快定位问题原因，尽快处理。如果有装一些三方的系统监控软件当然最好，没有的话，也可以按以下几种最简单的方式大致定位问题所在。

(以下说明暂基于Weblogic816、Solaris)
如同破案一般，我们需要了解案发现场，那么最好的现场信息莫过于系统临死前的都有谁访问了他——
1.获得线程Url信息
1.1 如果此应用console控制台还可访问，则
左侧菜单树 yourdomain-servers-yourserver右键菜单中“View Execute Threads” 查看当前执行中的线程Url，并以此为线索看程序有无问题
1.2 如果此应用console控制台已无法访问
a.ps -ef|grep java
根据一些特殊配置信息（比如JVM内存设置的差异，对于Linux、Aix的可以直接看到ServerName，如果不同，则可以很容易分辨出来），判断出哪一个进程是挂起的应用，此行进程信息第二列数字既是PID（可以使用pargs PID进一步验证是否是应用的线程，会显示serverName=yourserver的内容）
b.可以打开另一窗口 动态显示nohup.out
cd /bea/user*/do*/yourdomain
tail -f nohup.out
c.kill -3 PID(刚才记下的PID)
等一会儿nohup.out中会打印出所有当前server中所有驻留线程的信息,发现有程序类的轨迹栈就可以据之查找原因。

2.查看是否OutOfMemory
2.1 如果此应用console控制台还可访问
左侧菜单树 yourdomain-servers-yourserver-"Monitoring"-"Performance" 中的“Memory Usage”查看当前系统内存占用是否过大,如果已经顶到头了，且图几乎不再刷新，则可判定发生了OOM
2.2如果此应用console控制台已无法访问
tail -f nohup.out，看看有没有OutOfMemory字样

stack space

3.查看目前消耗的连接池数
3.1 如果此应用console控制台还可访问
左侧菜单树 domain8888-services-jdbc-connection pools-htconnectionpool右侧页面
中"Monitoring" 标签页面，可以通过不断点击"state","waiters"等连接查看当前消耗的数据库连接数，并以此判断是否为连接消耗过大而引起。