系统层面如何定位I/O进程:
方法一 iotop:
yun install iotop
$ iotop -oP
命令的含义:只显示有I/O行为的进程
方法二 pidstat:
[root@crfkaifa ~]# yum install sysstat
Updated:
sysstat.x86_64 0:9.0.4-33el6_9.1
[root@crfkaifa ~]# pidstat -d 2
1、从网上下载了iopp.c,编译 gcc -o iopp iopp.c,
运行该命令iopp -c -i -k -u 2发现ologgerd进行磁盘IO很高,该进程是CHM(Cluster Health Monitor)导致的,CHM是Oracle11g的新特性,主要用来收集节点上的负载信息,网上说是bug,再没有更好的处理方式下先关闭。
2、关闭CHM
Node Eviction due to OLOGGERD High CPU (Doc ID 1636942.1)
Loggerd uses high cpu and do lots of I/O to the disk where the BDB (Berkeley Database used by CHM) resides.
This is due to BUG 13867435 - OLOGGERD USING A LOT OF RESOURCES .
你把CHM关闭看看如何
[root@node3 ~]# ps -ef |grep crf
root 3127 1 1 22:10 ? 00:00:02 /u01/11.2.0/ghome/bin/ologgerd -M -d /u01/11.2.0/ghome/crf/db/node3
root 3488 3264 0 22:12 pts/0 00:00:00 grep crf
[root@node3 ~]# cd /u01/11.2.0/ghome/bin/
./crsctl stop res ora.crf -init
CRS-2673: Attempting to stop 'ora.crf' on 'node3'
CRS-2677: Stop of 'ora.crf' on 'node3' succeeded
[root@node3 bin]# ps -ef |grep crf
root 3609 3264 0 22:13 pts/0 00:00:00 grep crf
[root@node3 bin]#
关闭后磁盘Io降下来了,性能恢复正常。
感悟:通过这件事以后我会尝试发现问题解决问题
以前看到磁盘爆满就想当然的以为是磁盘文题,自己认为是共享磁盘不断通信造成的搞IO
想到了用另一种方法重建asm,比如openfile。还想到了换SSD
这次因为前几天都是ok的,当然也有幸运成分,肯定是前几天没触发CHM进程
这次我就试着监控linux系统,然后试着找占用磁盘高的进程,然后再从rac方面找
也是幸运的我看到了这一篇文章,其实my support上应该也可以找到