Oracle大页未正常使用导致大量SWAP案例分析

时间:2022-12-09 12:06:41

故障背景

某次,用户反馈一套已经正常运行一段时间的 Oracle  11.2.0.4 RAC 数据库( 128G 物理内存),在调整 process 阈值之后, R AC 集群中其中一个节点出现系统卡慢现象,甚至本地 sql plus 登录也很缓慢,并且随后出现实例宕机故障,故障前的典型特征是可用物理内存耗尽并出现大量 S WAP 交换。

故障描述

1 2 号新环境投产后连接数提高了 30 倍, 6 号数据库连接数暴涨,业务和开发建议扩大数据库连接数。此时运行均正常。

2 8 号晚上将数据库连接数有 2000 调整为 4000 ,出现偶发集群可用率为 50% ,和 1 节点连接中断告警。

3 10 号中午将连接数参数有 4000 回退为 2000

4 11 号凌晨还是出现集群可用率为 50% ,和 1 节点连接中断告警,会自愈但是机器使用卡顿。

5 )根据 M OS 调整信号量 (Doc ID 2041723.1)

ifconfig lo mtu 16436

6 )调整后仍然复现,排查后最终确定为系统大页未生效,进而导致服务器 O OM ,设置系统资源限制 memlock 后解决问题。

诊断过程

用户 反馈 监控 报错,错误如下:

  Oracle大页未正常使用导致大量SWAP案例分析

查询 后台日志

  Oracle大页未正常使用导致大量SWAP案例分析

根据 MOS, 调整参数( Oracle Linux: ORA-27301:OS Failure Message: No Buffer Space Available (Doc ID 2041723.1)

  Oracle大页未正常使用导致大量SWAP案例分析

修改内核参数
vm.min_free_kbytes
修改网络MTU值
ifconfig lo mtu 16436

 

运行一段时间后,内存仍长时间占有:

  Oracle大页未正常使用导致大量SWAP案例分析

  Oracle大页未正常使用导致大量SWAP案例分析

  Oracle大页未正常使用导致大量SWAP案例分析

  Oracle大页未正常使用导致大量SWAP案例分析

 

此时其实已经可以确定大页尚未生效问题。

  Oracle大页未正常使用导致大量SWAP案例分析

查看后台日志中进一步确定。

 

分析到此处,其实问题已经能看的很清楚了, 操作系统层面配置了大页 1 60GB ,这部分内存会从物理内存中直接分配掉,正常情况下该内存空间可用于数据库 S GA ,但是从数据库 alert 告警日志中却看到大页的使用是 0KB ,因此数据库 S GA P GA 的内存空间还要额外的从物理内存中分配,一旦并发或连接数上来了,物理内存耗尽导致大量 S WAP ,进而导致性能出现瓶颈。

修改 memlock 资源限制,并 重启数据库实例后,业务及内存使用均恢复正常。因此,本次故障,是由于 memlock 配置不规范造成的。

shell> vi /etc/security/limits.conf
* soft memlock unlimited
* hard memlock unlimited


那这就带来了新的问题,这套 Oracle  RAC ,在 业务调整前,在 同样没有设置 memlock 限制的情况下,为啥没有出现性能问题呢?因此,还需要进一步下转分析。

测试验证

1 )保持 mem lock 资源限制为默认

  Oracle大页未正常使用导致大量SWAP案例分析

2 )重启操作系统 , 让集群将实例带起来(大页生效)

查看数据库日志(此时数据库正常使用大页)
Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = UNLIMITED
 
Total Shared Global Region in Large Pages = 2210 MB (100%)
 
Large Pages used by this instance: 1105 (2210 MB)
Large Pages unused system wide = 3 (6144 KB)
Large Pages configured system wide = 1108 (2216 MB)
Large Page size = 2048 KB
********************************************************************


3 )使用集群管理命令启动数据库 (大页生效)

srvctl start database -d ora
 
查看数据库日志(此时数据库正常使用大页)
Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = UNLIMITED
 
Total Shared Global Region in Large Pages = 2210 MB (100%)
 
Large Pages used by this instance: 1105 (2210 MB)
Large Pages unused system wide = 3 (6144 KB)
Large Pages configured system wide = 1108 (2216 MB)
Large Page size = 2048 KB
*******************************************************************

*

4 )使用 startup 命令分别启动数据库(大页未生效)

startup
 
查看数据库日志(此时数据库无法使用大页)
 
Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = 64 KB
 
Total Shared Global Region in Large Pages = 0 KB (0%)
 
Large Pages used by this instance: 0 (0 KB)
Large Pages unused system wide = 1108 (2216 MB)
Large Pages configured system wide = 1108 (2216 MB)
Large Page size = 2048 KB
 
RECOMMENDATION:
  Total System Global Area size is 2210 MB. For optimal performance,
  prior to the next instance restart:
  1. Large pages are automatically locked into physical memory.
 Increase the per process memlock (soft) limit to at least 2216 MB to lock
 100% System Global Area's large pages into physical memory
********************************************************************


  因此,可以得出结论,在未设置 memlock 资源限制的情况下,不同的启动方式会影响大页的生效,具体参考如下:

1.  集群将实例带起来,数据库能正常使用大页

2.  用集群管理命令启动数据库,数据库能正常使用大页  

3.  startup 会根据实际的用户环境生效

后续在跟用户的交流中确认,实际操作步骤就是为对两节点依次使用 startup 方式进行启动,此时在未正常配置 memlock 限制下,大页无法被正常使用,导致系统 O OM 的出现。