摘要：部分信息来自互联上搜索的相关信息，如有引用或争议，可以私信我。
1.问题现象
系统环境：Windows Server 2019
数据库版本：Oracle 19.3
发现osysmond进程CPU使用率在78%以上，正常情况在1%以下。
2.OSYSMOND进程CHM
对于ora.crf，其资源对应的功能是CHM资源对应的功能是ClusterHealthMonitor（以下简称CHM）是一个Oracle提供的工具，用来自动收集操作系统的资源（CPU、内存、SWAP、进程、I/O以及网络等）的使用情况。CHM会每秒收集一次数据。这些系统资源数据对于诊断集群系统的节点重启、Hang、实例驱逐(Eviction)、性能问题等是非常有帮助的。另外可以使用CHM来及早发现一些系统负载高、内存异常等问题，从而避免产生更严重的问题。ora.crf资源是11.2.0.2之后才出现的。
由于ora.crf服务生成的文件crf*.bdb,HOSTNAME.ldb会很大，这样就对GI_HOME目录的使用率造成了压力。并且其核心进程OSYSMOND在收集OS层面的信息时，经常会出现CPU消耗过大、内存使用过高甚至导致集群hang的情况。
例如：AIX:osysmond.bin High CPU Usage ( Doc ID 1397988.1 ) ，osysmond.binsocket leak causing RAC node hang and ACFS issues (Doc ID1526421.1)，osysmond.binHigh Memory Consumption on Solaris 11 (Doc ID1543623.1)等等，MOS一搜太多太多类似案例，有兴趣的朋友自己去撸撸。
OSYSMOND进程是用于收集os层面的诊断信息，在windows平台这种没有OSWatcher的情况下有用。对于可以部署OSWatcher的平台，CHM作用有限，既然有对主机资源消耗更少的OSW，那就完全没有选择CHM的必要了，所以果断关闭CHM才是最合理的选择。
3.分析过程
1)分析OSYSMOND进程：
分为两种情形：
Case1 - high number of disks
Case2 - high number of open file descriptor
根据文档：
ClusterHealth Monitor (CHM/OS) osysmond.bin High Resource (CPU, Memory andFD etc) Usage ( Doc ID 1554116.1 )
11.2.0.3版本相关的bug在GIPSU 11.2.0.3.7中均已修复。
1、查看OSWatcher输出，以便区分下两种情形
2、查看gi和oracle用户的opatchlsinventory输出
2)综合当前情况继续分析
查看OSW的iostat发现不存在大量的磁盘问题，并且当前GI版本为11.2.0.3.9，
结合opatch补丁清单做了下排除，已知的这方面bug中匹配的只剩下这个了：
Bug16901346 : OSYSMOND PROCESS TAKING ALMOST 5% OF CPU BECAUSE OF HIGHOPEN FDS COUNT
其补丁下载中也有GIPSU 11.2.0.3.9上的fix：
https://updates.oracle.com/download/16901346.html
该bug的判断方法是：
ocludumpnode view shows: Too many open FDs (100090)on node racnode1 (> 90%of max allowed)
#cpus:16 cpu: 45.93 cpuq: 40 physmemfree: 10178944 physmemtotal: 50331648mcache: 4781768
swapfree:8242176 swaptotal: 8388608 ior: 6234 iow: 2624 ios: 353 swpin: 0swpout: 0 pgin: 0 pgout: 0
netr:12450.397 netw: 11801.061 procs: 2134 rtprocs: 1346
#fds:100036;';3:Time=07-08-13 15.44.25, Too many open FDs (100036)on noderacnode1 (> 90% of max allowed)'
#sysfdlimit:65534 #disks: 43 #nics: 4 nicErrors: 0
运行如下命令输出看下：
su- grid
$oclumondumpnodeview -allnodes -v -s "2016-08-08 00:00:00" -e"2016-08-09 12:00:00"
如果以上命令运行报错，也可通过如下命令查看
su-
#<gi_home>/bin/diagcollection.pl--collect --chmos
命令输出结果示例如下：
#/oracle/app/11.2.0/grid/bin/diagcollection.pl --collect --chmos
ProductionCopyright 2004, 2010, Oracle. All rights reserved
ClusterReady Services (CRS) diagnostic collection tool
Cannotparse master oclumon get
ClusterHealth Monitor (OS) information has not been retrieved. 《===仍然无法获取CHM数据
Rundiagcollection on master node to collect CHM/OS information
CollectingOS logs
Collectingsysconfig data
无法获取CHM原因分析：
chm可能停掉了吧或者hang了，所以无法dump出信息(可以通过crflog来查看其目前的状态 <GRID_HOME>/log/<node_name>/下的crfmond和crflogd)。
在11.2.0.3.9之上没有其他已知bug会导致这个情况，只有该BUG16901346会导致。
4.解决方法
由于chm只是收集os层面的诊断信息而已，chm收集的信息OSWatcher也会收集，故选择停掉chm。
临时解决
是重启ora.crf服务
$GI_HOME/bin/crsctl stop res ora.crf -init
$GI_HOME/bin/crsctl start res ora.crf -init
11.2 的补丁没有找到，只找到了12.1的补丁程序18701017: AIX-12102-CHM:MEMORY LEAK(0.23 MB/HR) IN OSYSMOND.BIN。
为了防止此类问题发生还是安装相应补丁。
关闭chm：
PS C:\Users\Administrator> crsctl.exe modify resource ora.crf -attr "AUTO_START=never" -init
PS C:\Users\Administrator> crsctl.exe stop res ora.crf -init
CRS-2673: 尝试停止 'ora.crf' (在 'zxrdsrv1' 上)
CRS-2677: 成功停止 'ora.crf' (在 'zxrdsrv1' 上)
PS C:\Users\Administrator>
