一、现象描述

最近一天下午块下班时手机和邮件连续收到zabbix监控告警，提示同城机房某生产交易库ASM日志有报错，报错信息如下：

[PHX-HG-silk-DB-Oracle]Oracle ORA ASM Log Error(s) found on PHX-H-DB-Oracle-10.1.4.80-silkord1: PROBLEM (Value: ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O
ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O。

该生产数据库是一套11G RAC集群，前期这套数据库两台物理服务器硬件过保，过保之前使用的是Centos 6操作系统，新采购的服务器无法安装Centos 6，于是部署了Centos 7.9操作系统，前期通过搭建DG并进行主备切换将过保服务器进行了替换，在系统替换前未出现同类报错信息。

于是登录该数据库环境，查看日志，显示只有节点一ASM日志有此报错，报错信息如下：

Errors in file /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_ora_230236.trc:
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
Additional information: 1
Sat Apr 22 06:06:52 2023
Errors in file /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_ora_84473.trc:
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
Additional information: 1
Sat Apr 22 08:06:34 2023
Errors in file /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_ora_99517.trc:
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
Additional information: 369362919
Sat Apr 22 08:06:52 2023
Errors in file /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_ora_100200.trc:
ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O
Linux-x86_64 Error: 11: Resource temporarily unavailable
Additional information: 3
Additional information: 128

从问题出现当天下午16点出现报错后，频繁报错，每隔几分钟报错一次。

二、处理过程

查询网上及MOS资料，显示ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O和操作系统aio设置相关。

查询到当前aio-nr和aio-max-nr信息如下：

[root@xxxxx ~]# cat /proc/sys/fs/aio-max-nr
1048576
[root@xxxx ~]# cat /proc/sys/fs/aio-nr
1047552

aio-nr是在io_setup系统调用上为所有当前活动的aio上下文指定的事件数的运行总数。如果aio-nr达到aio-max-nr，那么io_setup将因EAGAIN而失败。
知识点：

在Linux中，"aio-nr"是指异步输入输出（Asynchronous I/O）操作的数量。异步I/O是一种在进行文件操作时，可以在操作完成之前继续执行其他任务的机制。通过异步I/O，应用程序可以发起I/O操作，然后继续执行其他任务，而不需要等待操作完成。

"aio-nr"是Linux内核中的一个统计指标，表示当前系统中活动的异步I/O操作的数量。它反映了系统正在处理的异步I/O操作的负载情况。

异步I/O可以提高系统的性能和响应能力，特别是在需要处理大量I/O操作的高负载环境中。通过异步I/O，应用程序可以更有效地管理和利用系统资源，并提高对外部设备的访问效率。

"aio-max-nr"参数的作用是限制系统中可以同时进行的异步I/O操作的数量，以控制对系统资源的使用。它定义了系统所能支持的最大异步I/O操作数目，超过这个限制的操作将被拒绝。

通过适当配置"aio-max-nr"参数，可以平衡系统性能和资源利用的需求。如果应用程序需要大量的异步I/O操作，可能需要增加这个限制，以确保系统能够处理足够的异步I/O请求。但是，过高的限制可能会导致资源过度消耗。因此，这个参数的设置应该根据系统的特定需求和资源状况进行调整。

通过查询报错日志里的trc文件初步判定和定时监控asm_diskgroup相关。

[root@xxxx ~]# more /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_ora_171522.trc
Trace file /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_ora_171522.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Real Application Clusters and Automatic Storage Management options
ORACLE_HOME = /u01/app/11.2.0/grid
System name:    Linux
Node name:      ph-silk-primary-db1
Release:        3.10.0-1160.el7.x86_64
Version:        #1 SMP Mon Oct 19 16:18:59 UTC 2020
Machine:        x86_64
Instance name: +ASM1
Redo thread mounted by this instance: 0 <none>
Oracle process number: 33
Unix process pid: 171522, image: oracle@ph-silk-primary-db1 (TNS V1-V3)
 
 
*** 2023-04-23 09:07:33.222
*** SESSION ID:(64.55981) 2023-04-23 09:07:33.222
*** CLIENT ID:() 2023-04-23 09:07:33.222
*** SERVICE NAME:() 2023-04-23 09:07:33.222
*** MODULE NAME:(sqlplus@ph-silk-primary-db1 (TNS V1-V3)) 2023-04-23 09:07:33.222
*** ACTION NAME:() 2023-04-23 09:07:33.222
  
WARNING:Could not increase the asynch I/O limit to 256 for kfdParallelIO.
 
*** 2023-04-23 09:07:33.222
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=1, mask=0x0)
----- Error Stack Dump -----
ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O
Linux-x86_64 Error: 11: Resource temporarily unavailable
Additional information: 3
Additional information: 128
Additional information: 386140135
----- Current SQL Statement for this session (sql_id=7v21cmm3d7z26) -----
select name,state from v$asm_diskgroup
 
----- Call Stack Trace -----
calling              call     entry                argument values in hex     
location             type     point                (? means dubious value)    
-------------------- -------- -------------------- ----------------------------
skdstdst()+41        call     kgdsdst()            000000000 ? 000000000 ?
                                                   7FFEB42E36D0 ? 7FFEB42E37A8 ?
                                                   7FFEB42E8250 ? 000000002 ?
ksedst1()+103        call     skdstdst()           000000000 ? 000000000 ?
                                                   7FFEB42E36D0 ? 7FFEB42E37A8 ?
                                                   7FFEB42E8250 ? 000000002 ?

三、处理结果

根据MOS建议，对该台服务器aio-max-nr调整为一个较大值，如下所示。
另可参照https://blog.pythian.com/troubleshooting-ora-27090-async-io-errors/ 这篇文章。

sysctl -w fs.aio-max-nr=50000000

[root@xxxx~]# cat /proc/sys/fs/aio-nr
1048576
[root@xxxx~]# cat /proc/sys/fs/aio-max-nr
50000000

为安全起见，先在测试环境进行了验证测试，待观察一段时间后没问题，在征得同意后对生产环境进行了修改。

aio-max-nr的修改无需重启操作系统。

因为该生产环境是RAC环境，为保证两台环境参数尽可能一致，也对另一台未出现问题的服务器进行了同样修改。

修改后，告警消除，连续观察几天，也未再产生告警。