NO.28 要你命3000

NO.28 要你命3000

 (待完善)

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

    (以下说明暂基于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"等连接查看当前消耗的数据库连接数，并以此判断是否为连接消耗过大而引起。