# 异常 ### 环境描述 - 系统：Linux - 数据库：Oracle 11.2.0.4 ### 现象 ASM alert 日志 ``` ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O Linux-x86_64 Error: 2: No such file or directory Additional information: 3 Additional information: 128 ``` # 网上建议 调整内核参数 ``` #fs.aio-max-nr = 1048576 fs.aio-max-nr = 3145728 ``` 参考 - ORA-27090: MESSAGE 27090 NOT FOUND; (DOC ID 579108.1) # 概念整理 ### aio aio 异步读写是在 Linux 内核 2.6 之后才正式纳入其标准。之所以会增加此模块，是因为众所周知我们计算机 CPU 的执行速度远大于 I/O 读写的执行速度，如果我们用传统的阻塞式或非阻塞式来操作 I/O 的话，那么我们在同一个程序中（不用多线程或多进程）就不能同时操作俩个以上的文件 I/O，每次只能对一个文件进行 I/O 操作，很明显这样效率很低下（因为 CPU 速度远大于 I/O 操作的速度，所以当执行 I/O 时，CPU 其实还可以做更多的事）。因此就诞生了相对高效的异步 I/O ##### aio-nr＆aio-max-nr： aio-nr 是指定的事件数的运行总和 io_setup 系统调用所有当前活动的 aio上下文。如果 aio-nr 到达 aio-max-nr 然后 io_setup 将失败并使用EAGAIN。注意提高 aio-max-nr 不会导致预分配或重新调整大小任何内核数据结构。 - /proc/sys/fs/aio-nr 文件提供了系统范围异步 I/O 请求现在的数目。 - /proc/sys/fs/aio-max-nr 文件是所允许的并发请求的最大个数 ##### 修改 1. 可以临时修改内核参数aio-max-nr ```shell echo > /proc/sys/fs/aio-max-nr 1048576 ``` 2. 永久修改内核参数 aio-max-nr，需要在 /etc/sysctl.conf 加上下面这句 ``` fs.aio-max-nr = 1048576 ``` 使参数生效 ```shell sysctl -p ``` ### FILESYSTEMIO_OPTIONS 初始化参数 可以使用 FILESYSTEMIO_OPTIONS 初始化参数启用或禁用文件系统文件的异步I/O或直接I/O。这个参数是特定于平台的，并且有一个最适合特定平台的默认值。它可以动态更改以更新默认设置。 FILESYTEMIO_OPTIONS 可以设置为以下值之一： - ASYNCH：在文件系统文件上启用异步 I/O，对传输没有时间要求。 - DIRECTIO：在文件系统文件上启用直接 I/O，这绕过了缓冲区缓存。 - SETALL：在文件系统文件上启用异步和直接 I/O。 - NONE：关闭文件系统文件的异步I/O和直接I/O。 ##### 参考 - "Warning: OS async I/O limit 128 is lower than recovery batch 1024" in Alert log (Doc ID 471846.1) ### ora.crf ora.crf 是 Cluster Health Monitor（以下简称 CHM）提供服务的资源， 用来自动收集操作系统（CPU、内存、SWAP、进程、I/O 以及网络等）的使用情况。 当然还是建议生产环境部署 OSW 来收集记录更久的信息， OSW 是调用的 OS 命令，而 CHM 调用的是 OS API，开销低、实时性强。 开始的版本是每秒一次，从 11.2.0.3 应该是变为每 5 秒一次。 CHM主要包括两个服务： 1. System Monitor Service(osysmond)：这个服务在所有节点都会运行，osysmond 会将每个节点的资源使用情况发送给 cluster logger service，后者将会把所有节点的信息都接收并保存到 CHM 的资料库。 ```shell $ ps -ef|grep osysmond root 7984 1 0 Jun05 ? 01:16:14 /u01/app/11.2.0/grid/bin/osysmond.bin ``` 2. Cluster Logger Service(ologgerd)：在一个集群中的，ologgerd 会有一个主机点(master)，还有一个备节点(standby)。当 ologgerd 在当前的节点遇到问题无法启动后，它会在备用节点启用。 ##### CHM诊断日志 ``` $GRID_HOME/log//crflogd/crflogd.log $GRID_HOME/log//crfmond/crfmond.log ``` ##### CHM Repository 用于存放收集到数据，默认情况下，会存在于 $GI_HOME/crf 下 ，需要 1 GB 的磁盘空间， 每个节点大约每天会占用 0.5GB 的空间， 您可以使用 OCLUMON 来调整它的存放路径以及允许的空间大小(最多只能保存 3 天的数据) ##### 获得CHM生成的数据的方法有两种 1. 一种是使用 Grid_home/bin/diagcollection.pl ```shell diagcollection.pl -collect -chmos -incidenttime inc_time -incidentduration duration ``` 2. 另外一种获得 CHM 生成的数据的方法为 oclumon ```shell oclumon dumpnodeview [[-allnodes] | [-n node1 node2] [-last “duration”] | [-s “time_stamp” -e “time_stamp”] [-v] [-warning]] [-h] ``` ##### 停止和禁用 ora.crf resource ``` On each node, as root user: # /bin/crsctl stop res ora.crf -init # /bin/crsctl modify res ora.crf -attr ENABLED=0 -init ``` # 分析 近日发现，有少量库及时调整到 fs.aio-max-nr = 3145728，依然会出现此异常，所以对这个问题进行了追踪 1. 通过实时调用 /proc/sys/fs/aio-nr 获取当前的 aio 数 2. 通过启停 Oracle DB、监听、ora.crf 等服务的方式可知 ora.crf 为占用大量 aio 的罪魁祸首 ### 参考 - [[Oracle]&[Linux]Linux异步IO的怪事，aio被贼偷走了](https://mp.weixin.qq.com/s/yJ9EGsZkABiIPSFZwMNdBQ) # 最终建议 关闭 ora.crf，改用 OSWatch 来监控系统使用资源的变化