http://blog.itpub.net/30310891/viewspace-2927363/
稀奇古怪的..
某次，用户反馈一套已经正常运行一段时间的 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 后解决问题。
用户 反馈 监控 报错，错误如下：
查询 后台日志 ：
根据 MOS, 调整参数（ Oracle Linux: ORA-27301:OS Failure Message: No Buffer Space Available (Doc ID 2041723.1) ）
|
1
2
3
4
|
修改内核参数vm.min_free_kbytes修改网络MTU值ifconfig lo mtu 16436 |
运行一段时间后，内存仍长时间占有：
此时其实已经可以确定大页尚未生效问题。
查看后台日志中进一步确定。
分析到此处，其实问题已经能看的很清楚了， 操作系统层面配置了大页 1 60GB ，这部分内存会从物理内存中直接分配掉，正常情况下该内存空间可用于数据库 S GA ，但是从数据库 alert 告警日志中却看到大页的使用是 0KB ，因此数据库 S GA 和 P GA 的内存空间还要额外的从物理内存中分配，一旦并发或连接数上来了，物理内存耗尽导致大量 S WAP ，进而导致性能出现瓶颈。
修改 memlock 资源限制，并 重启数据库实例后，业务及内存使用均恢复正常。因此，本次故障，是由于 memlock 配置不规范造成的。
|
1
2
3
|
shell> vi /etc/security/limits.conf* soft memlock unlimited* hard memlock unlimited |
那这就带来了新的问题，这套 Oracle RAC ，在 业务调整前，在 同样没有设置 memlock 限制的情况下，为啥没有出现性能问题呢？因此，还需要进一步下转分析。
（ 1 ）保持 mem lock 资源限制为默认
（ 2 ）重启操作系统 , 让集群将实例带起来（大页生效）
|
1
2
3
4
5
6
7
8
9
10
11
12
|
查看数据库日志(此时数据库正常使用大页)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 ）使用集群管理命令启动数据库 （大页生效）
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
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 命令分别启动数据库（大页未生效）
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
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 的出现。