HP平台的asm要求maxfiles_lim参数为32767

最近在客户遇到一个案例,和大家分享一下,大家如果客户那里也有HP平台,那么要注意在11gR2中kernal参数maxfile_lim要设置成32767,而在11gR1以及之前,这个参数是65536的。(在169706.1文档上,11gR1之前是设置65536的,在11gR2上要求参考install guide,而install guide上写的是32767)

故障现象

加asm磁盘的时候,无法加成功,报错disk is not visiable in cluster-wide,同时伴随报错ora-27070。

其实盘在2个节点上都是能看得到的。

创建test diskgroup的时候,节点1上创建成功,节点2上mount,mount了一会就dismount了,报错ora-27072。

两次报错,在alertlog中都有关于rebalance进程的trace文件,在trace文件中,可以看到关于异步IO的一些报错问题。

初步怀疑和Bug 17264575 : ORA27070 AND HPUXIA64 ERROR: 15 AND DISKGROUP DISMOUNT AFTER ADDING NEW吻合。根据Bug 17264575和Doc ID 1604055.1,虽然研发说要将maxfiles_lim改小到32767。但最后问题总结却说是加大了参数。前后是有矛盾的。

开SR确认是改大还是改小,GCS说无法确认,the only available solution是让我找客户试试。尼玛人家生产系统能随便试么?!

maxfiles_lim是每个process的打开文件句柄数,检查客户当前的打开文件句柄数,他们设置的是65536,实际已经使用率5万多,那么有出现了一个问题,哪怕hit中Bug 17264575,是要求改小到32767,那么我当前已经使用了5万多个打开文件句柄数,那么改小之后,不会有问题吗?是否会有too many open file的报错出现?

进一步分析当前打开文件数的情况,发现打开文件句柄数最多的进程是rebalance进程,其他进程最多就打开4000多个文件,而rebalance进程打开了近5万个文件,其中打开了disk78有4万多个,且disk78不是用在生产diskgroup上的disk,是一个former的disk。

单个进程,打开那么多文件数,且都是同一个文件,根据这个情况,怀疑也是bug,继续查询mos,发现 Bug 18243382 : RBAL PROCESS OPENED TOO MANY FILE DESCRIPTORS ON CANDIDATE ASMDISK。但是这个bug也是基于Bug 17264575,原因也是没有设置正确的maxfiles_lim。客户也是设置了过大的 maxfile_lim,解决方法是缩小maxfiles_lim到32767.

因此我们可以确定是需要缩小maxfile_lim。且缩小后,rebalance进程不会打卡那么多文件数,所有的进程最多只有4000多,不会超过32767,因此不会有too many open files的报错风险。

修改maxfile_lim不用重启,但是连带的参数maxfile需要重启。

另外,修改maxfile_lim也需要重启asm才能是asm的进程获得新的参数。

最后,客户进行了变更,修改参数,减小到32767,重启主机,加盘成功,不再报错。

相关文章

2条评论

发表回复

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

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