Solaris10平台资源过度使用案例：JBoss控制台报JMS消息服务器无法连接

问题描述：在Solaris10平台上运行着JBoos服务，但现在客户端无法登陆，查看 JBoss控制台，发现报JMS消息服务器无法连接；使用telnet方式登陆该平台同样很缓慢。

1、首先 使用vmstat 检查CPU使用情况，主要观测系统usr，sys分别占用CPU情况，检查发现系统很繁忙；

2、使用mdb –k | ::memstat查看内存使用情况，发现系统使用了96%的内存，明显使用率过高。

3、使用prstat –a来查看系统中，是哪些进程占用了过多的CPU资源，发现有三个进程，分别是jboss应用程序，sulogin进程，和snmp进程，CPU使用率分别为45%，18%，15%左右。对于jboss应用程序占用资源多，暂时可以不考虑；对于另外两个进程，尤其是sulogin进程占用资源多，并且还显示运行了400多天，推断这个进程可能有问题，通过kill -9 该进程ID，杀死该进程。

   由于开始对snmp进程不了解，该进程也被我一并杀掉了，后来知道该进程是OMCR系统管理模块使用的进程，如果误删除了该进程，可以使用/usr/sfw/sbin/snmpd重启该进程。

   由于系统报线程数过多问题，又进一步查看了jboss的线程数，使用prstat –p 进程ID，可以看到其线程数为1221个。使用jboss控制台的systeminfo，察看了具体的线程情况，通过UIL2.SocketManager.ReadTask#,UIL2.SocketManager.WriteTask#, UIL2(SocketManager.MsgPool关键字，可以查看出有多少个JMS线程，经统计这三个线程的数目分别为333，333，334，合起来共1000个，也就是发生了JMS消息死锁或相互等待的情况。

   对于这种情况，只能通过重启jboss服务来解决。重启服务后，发现CPU使用率有了一定程度的下降。

4、进一步分析内存问题，首先检查系统当前数据库实例情况：使用ps –ef|grep ora_，发现系统有两个数据库实例，询问测试人员，有一个实例不使用，于是用oracle用户登录，执行export ORACLE_SID=omcr;sqlplus/ as sysdba;shutdown immediate；关闭掉不用的数据库实例；又查看了一下正在运行的数据库使用的内存情况，将sga和pga看到的结果相加，得到当前数据库使用的全部内存，大小在3G左右，而jboss在4G左右。做了这些工作后，检查系统，发现内存使用立即下降到70%左右。

5、 最后使用vmstat ，以及uptime观察系统运行情况，发现负载恢复到正常水平，客户端登陆和操作响应速度明显有提升，系统恢复正常水平。