聚合国内IT技术精华文章,分享IT技术精华,帮助IT从业人士成长

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

2015-07-03 17:05 浏览: 1361823 次 我要评论(0 条) 字号:

最近在客户遇到一个案例,和大家分享一下,大家如果客户那里也有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。但最后问题总结却说是加大了参数。前后是有矛盾的。

@ Asynchronous IO on HP limits the max value of the file descriptor used to
@ 32768, due to the asynch structures storing the fd in a short.
@ .
@ The problem in 10372187 was that if the OS 'number of files' limit was set
@ too high, this low water mark would be set too high, meaning
@ file descriptors used would be > 32768, and so asynchronous IO fails.
@ => checking code shows fix is present, snippet of change:
@ /* 10372187: An fd above 32768 will blow the max value for
@ * an fd in the hp asynch structure (short)
@ ...
@ if (newfd > SB2MAXVAL)
@ {
@ SLERC_OERC (*se) = OER(27080);
@ ...
@ .
@ The setting as used by customer are:
@ maxfiles 8192 8192
@ maxfiles_lim 63488 63488
<< way above 2^15 (32768)
....
 
***
SWALSH 10/31/13 08:52 am ***
 
@
Key Symptoms/Summary/Rediscovery:
@
Closing as per o/s kernel parameter increase resolved issue. Thanks.
@ .
@
Explain why this is not a bug:
@
Insufficient file handles, but after maxfiles_lm is increased issue is
@
resolved.
@ .

开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,重启主机,加盘成功,不再报错。



网友评论已有0条评论, 我也要评论

发表评论

*

* (保密)

Ctrl+Enter 快捷回复