一个间歇性进程hang问题的处理

症状：

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实例关闭而退出。

[oracle@MSPRG-DB1]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异常，可能并非由性能问题引起，要多角度多层次综合分析问题。

本文出自 “记忆碎片” 博客，请务必保留此出处http://weikle.blog.51cto.com/3324327/1627699