大量会话处于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秒就出结果了。