oprocd 故障

       Oprocd 同 linux 的 Hangcheck-Timer 一样，有一个 探测机制，会定时去探测节点间的状态，以防止 I/O 出现问题，如果 Oprocd 没有及时返回结果，那么会引起os reboot。

但是，当 系统的 cpu 出现比较高的负载是，Oprocd 会没有及时返回结果的情况，那么这时，节点就会莫名重启，而且，因为 Oprocd 的 响应时间默认情况下设置比较短（0.5S），导致，系统还没来得及写日志信息，就重启了，所以，有时，我们很难去判断是由于什么原因导致系统重启的。这时，我们就需要去设置 Oprocd 的响应时间，将它改长。

首先，我们来看看 Oprocd 的官方解释：

PROCD is a process monitor that runs on hardware platforms supporting other third-party cluster managers and is present only on hardware platforms other than Linux. Its function is to create threads for the various processors on the system and to check if the processors are hanging. Every second, the PROCD thread wakes up and checks the processors on the system, and then goes to sleep for about 500 ms and tries again. If it does not receive any response after n seconds, it reboots the node. On Linux environments, the hangcheck timer module performs the same work that PROCD does on other hardware platforms.

接着，我们来看看，其他人是怎么去定义和设置 oprocd 的响应时间延时的：

linux平台上的Oracle Clusterware 10.2.0.4和以后版本引入了一个新的Oracle Clusterware Process Monitor Daemon (OPROCD)进程来监控系统状态和集群中的每个节点的健康状态，就象已经在不使用第三方的cluster软件的UNIX系统中提供的那样，下面来看看 OPROCD到底是何方神圣。

OPROCD在linux平台上的10.2.0.4版本中和hangcheck- timer一起运行，它和hangcheck-timer模块没有联系和依赖关系，它由init.ccsd进程产生出来并用root用户运行。 OPROCD进程被锁定在内存中来监控集群中的每个它自己运行的节点，来检测机器上的硬件或者驱动的freezes，并且提供I/O的fencing功能（这和SCSI提供的中断的fencing功能不同）。如果一个机器被冻结了足够长的时间后，它被会集群驱逐出节点，它自己需要强制重启自己来阻止集群从失败的节点上的锁资源被重新组织后，失败的节点仍然访问共享的数据文件上的有疑问的I/O操作。为了提供这样的功能，OPROCD执行检查，然后停止运行（休眠），然后如果在期望的时间内不能被唤醒，OPROCD将重启本机的节点。

注意：OPROCD在第三方实现的集群环境中是不存在的，因为在LINUX平台下没有通过验证的第三方的集群解决方案，所以linux平台下的0.2.0.4版本中OPROCD将总是会存在的。

OPROCD启动的时候有两个参数：

-t : 超时时间，缺省1000，单位毫秒 (OPROCD_DEFAULT_TIMEOUT=1000)

-m : 重启前可接受的延迟，单位毫秒，缺省500 (OPROCD_DEFAULT_MARGIN=500)

推荐设置DIAGWAIT为13来增加重启前可接受的时间来把更多的日志信息写入磁盘。

缺省的话，-m的间隔为500：

$ ps -efl | grep oprocd

0 S root 6444 3080 0 78 0 - 636 - Apr15 ? 00:00:00 /bin/sh /etc/init.d/init.cssd oprocd

4 S root 7255 6444 0 -40 - - 516 - Apr15 ? 00:00:00 /u01/app/crs11g/bin/oprocd run -t 1000 -m 500 -f

设置了DIAGWAIT为13会默认增加-m的时间，下面显示设置DIAGWAIT为13后，-m参数值为10000

$ ps -efl | grep oprocd

0 S root 6444 3080 0 78 0 - 636 - Apr15 ? 00:00:00 /bin/sh /etc/init.d/init.cssd oprocd

4 S root 7255 6444 0 -40 - - 516 - Apr15 ? 00:00:00 /u01/app/crs11g/bin/oprocd run -t 1000 -m 10000 -f

OPROCD和hangcheck-timer在linux平台下是同时运行并提供不同的检测机制的，当他们导致节点重启的话，在系统日志中记录的信息是不同的：

oprocd导致的重启会记录"SysRq: resetting"

Hangcheck-timer导致的重启会记录"Hangcheck: hangcheck is restarting the machine"

 

这里，如何 设置 DIAGWAIT 将 oprocd 的世界延迟呢？

Metalink：ID 559365.1

 

番外话：

Oprocd 故障分析：

根据 metalink：ID 265769.1 Troubleshooting 10g and 11.1 Clusterware Reboots 里的说法：

- A problem detected by the OPROCD process. This can be caused by 4 things:

 

1) An OS scheduler problem.

2) The OS is getting locked up in a driver or hardware.

3) Excessive amounts of load on the machine, thus preventing the scheduler from

behaving reasonably.

4) An Oracle bug.

基本上，很大程度上，是由于系统问题或负载造成的，所以，当出现 OPROCD 的故障问题时，除了 oprocd 日志（位于 /etc/oracle/oprocd）可以先看看 系统日志（其实 rac 故障，系统日志肯定要先看看）：

Sun: /var/adm/messages

HP-UX: /var/adm/syslog/syslog.log

Tru64: /var/adm/messages

Linux: /var/log/messages

IBM: /bin/errpt -a > messages.out

 

http://www.itpub.net/viewthread.php?tid=1102568&extra=&page=1

Note: Crash event 0 was a INIT !

Note: This seems to be a user initiated INIT !

Please contact HP support referencing CRASHINFO_NOTE_INIT2.

。。。（略）

User requested reset of the system.

Oracle CRS (oprocd) TOC for clusterware integrity ...

这应该是 hp 的系统日志，具体什么原因也不知道

 

http://www.itpub.net/thread-1382105-1-1.html

http://zhang41082.itpub.net/post/7167/467698

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14730395/viewspace-682701/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14730395/viewspace-682701/