症状：
1、amms进程间歇性hang住，引起登网成功率下降
2、amms进程下所有工作线程均hang住，pstack显示如下：
----------------- lwp# 41 / thread# 41 --------------------
feedb075 read (b6, b2625d80, 8)
fe58e904 __1cDhpiEread6FipvI_I_ (b6, b2625d80, 8) + a0
fe58fa72 JVM_Read (b6, b2625d80, 8) + 36
b2f5b1ff Java_java_net_SocketInputStream_socketRead0 (a30f518, b2627dbc, b2627dc0, b2627de0, 0, 8) + 137
fb498e62 ???????? (bd23ad10, 0, 8, 0, a30f400, bd23ad28)
fb4c7820 ???????? ()
根据经验，对于OLTP生产系统，业务侧大量的socket读超时可能跟数据库有关。于是，将问题处理引导至数据库方向。果然，发现数据库(solaris10+oracle10g RAC)有如下异常：
1、lgwr进程的cpu占用异常，高达10%（正常应该在1%以下）
2、观察忙时awr报告，log file sync和log file parallel write高达80ms（正常应该在5ms以下）
3、写脚本从应用debug日志amms1.log提取写登网表时间，发现高达300ms（正常应该在10ms以下）
这里看上去像一个数据库的性能问题，果真如此么？
最后经过几个星期的折腾，发现原来是solaris DISM引起的，不用DISM后，问题解决。
注：
1、如何判断当前数据库是否用了DISM技术？
当使用DISM的时候，一个名为ora_dism_sid的进程会随oracle实例启动而启动，随oracle实例关闭而退出。
[[email protected]]ps -ef|grep -v grep|grepdism
root 10633 1 0 Jun 11 ? 0:42 ora_dism_RWDB
这里可以明显看到，oracle用了DISM。
2、oracle 10g什么时候用DISM？
在oracle10g中，如果sga_max_size和sga_target一样大，那么系统不会使用DISM（使用ISM）。如果设置sga_target比sga_max_size小，那么会使用DISM。
3、DISM可能引起什么问题？
DISM可能会引起oracle SGA无法被正常锁定，引起问题。判断方法：
#/usr/sbin/lockstat -A -n 200000 sleep 10
如果有大量的segspt_softunlock或者spt_anon_getpages，那么SGA可能没有被正常锁定。
如果用ISM，那么sga的内存会直接被os锁定，不会有这种问题。
当我们把sga_target改得和sga_max_size一样大并逐一重启实例，确认oracle不再使用DISM后，问题解决，所有症状都消失。awr报告top events恢复如下：
小结：
在系统负载没有明显变化的情况下，看到的cpu和io异常，可能并非由性能问题引起，要多角度多层次综合分析问题。