大量会话处于CSS initialization等待

接到一个问题,客户的某个系统突然CPU冲高,一个小时内CPU从5%冲到60%以上,在数据库中发现大量的会话在等待CSS initialization。

该系统是非RAC非ASM的系统,一般来说,不会出现CSS(cluster synchronization service)的等待,只有在访问voting disk或ocr的时候才会有这个等待,但是为什么在一个非RAC非ASM系统中出现了这个等待呢?

进一步检查会话的SQL,发现是一个监控程序发起的,里面有关于空间的检查,有查到了v$asm_diskgroup视图。这个倒是可以理解,查asm diskgroup的时候,出现了css的等待,但是这个等待一般不会持续很长时间,为什么会长时间的hang在这里?我们在测试机上执行select * from v$asm_diskgroup不到1秒就出结果了,从10046的trace看,虽然期间也有CSS initialization的等待,但是只是维持了很短一瞬间,而在客户的生产环境中,这个等待却持续很长时间,5分钟了还一直hang在那里不动。

查询metalink,发现有个Bug 10024824 – Database/session hang with ‘CSS initialization’ ,版本是10.2.0.5,而我们的数据库版本也正好是这个版本。

看上去像是和目录权限有关。我们去检查该目录的权限,发现权限是751:

难道真的要把权限改成771才能解决这个问题?

在之前的测试机上的测试中,我们发现每查询一次v$asm_diskgroup都会在client目录下生成一个新的cssN.log,如果是按照bug来说,是权限的问题,那么client目录一定是不能被写入,所以才hang住。我们继续检查目录和目录中的文件。

检查时我们发现这个目录下面存在大量的文件,ls的结果返回很多很多,如果想看看是否有最近的文件,ls -lrt根本没法看,所以我们只能先ls -lrt到一个文件,再tail看最后的几行是不是最近的,以确定是不是一直在写:

我们发现cssN.log文件一直在产生,最近的一个是4分钟前产生,平均2,3分钟就产生一个,忙的时候每分钟产生5,6个。目前已经大约有2万多个了,从属主看,权限设置正常,看上去不像权限设置771之后就能解决的问题。

我们继续分析,我们再次测试运行一个查询,并且用truss追踪该进程,我们此时才发现了问题的根源:进程大部分的时间是花在遍历client下cssN.log文件:

因此,我们判断,在每次查询v$asm_diskgroup的时候,都会在client下生成一个新的cssN.log文件(10.2.0.5才有,其他版本没发现),生成的命名规则是前一个数字加1。因此,生成新的cssN.log文件时,需要遍历整个client目录下的cssN.log文件,才能知道最大的数字是多少,才能生成第N+1的文件。而在client下不断生成大量文件,这个和oracle的一个unpublish bug 6004127 有关(ID 729349.1)。目前没有patch,文档上说解决的方法是用crontab定期清理client下的cssN.log

综上,所以监控软件查询v$asm_diskgroup时,总是会hang住(其实也不是完全hang住,等遍历完client下所有文件,就能跑完了,但是这会随着每次查询,每生成一个cssN.log,变得越来越慢)。当比较多的foglight进程查询v$asm_diskgroup就会堵住。

解决方案:定期清理$ORACLE_HOME/log/hostname/client下的文件,或者升级数据库到10.2.0.5以上,或者更改代码,不查询v$asm_diskgroup。

ps:当晚客户清理了目录,测试查询v$asm_diskgroup,不到1秒就出结果了。

相关文章

2条评论

  1. re vmcd:你是用了goagent的代理吧,暂时去掉代理就不会乱码了。我在chrome下用proxy switchysharp+goagent做代理,切换到直接连接后,就不乱码了,

回复 小荷 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据