数据库宕机分析以及大页作用

--原文：https://www.modb.pro/db/43752?xzs=

发现问题

数据库宕机

思路步骤

发现Oracle Rac集群一节点数据库宕机，优先恢复业务，进入oracle用户拉起数据库
#查询集群状态
/u01/app/11.2.0/grid/bin/crsctl status res -t

#进入Oracle用户，启动数据库，查找alter日志路径
su - oracle
sqlplus / as sysdba
startup
show parameter dump

#background_dump_dest这列后边就是数据库alter日志的位置

tail -3000f /u01/app/oracle/diag/rdbms/cw*/cw*/trace/alert_cw*.log
根据启动时间往前找，发现关键词

---

Mon Jan 11 09:29:24 2021
PMON (ospid: 23267): terminating the instance due to error 471
Mon Jan 11 09:29:24 2021
opiodr aborting process unknown ospid (27363) as a result of ORA-1092
Mon Jan 11 09:29:24 2021
ORA-1092 : opitsk aborting process
Mon Jan 11 09:29:24 2021
System state dump requested by (instance=1, osid=23267 (PMON)), summary=[abnormal instance termination].
System State dumped to trace file/u01/app/oracle/diag/rdbms/cwglrac1/cwglrac11/trace/cwglrac11_diag_23277_20210111092924.trc
Mon Jan 11 09:29:24 2021
opiodr aborting process unknown ospid (27513) as a result of ORA-1092
Instance terminated by PMON, pid = 23267

这种情况下可以暂时确定是PMON杀掉了Oracle数据库进程，PMON这么做的原因是一般是因为服务器资源不足，避免服务器宕机而杀掉进程

---

接下来去/u01/app/oracle/diag/rdbms/cwglrac1/cwglrac11/trace/cwglrac11_diag_23277_20210111092924.trc观察报警日志
但是我一直没看懂过trc日志，跳过

---

接着看系统日志
more /var/log/message
开头暴击。直接就发现报错
Jan 11 09:29:23 cwglrac11 kernel: oracle invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0

oom-killer 重点词就是这个oom，out of Memory的简写，也就是内存不足。

---

按理来说不应该因为，业务高峰期已过，而且服务器内存377G，我还设置了大页，查看两个节点
free -g

cat /proc/meminfo | grep Huge

发现大页居然没被使用！！
cat /proc/meminfo | grep Huge
AnonHugePages: 0 kB
HugePages_Total: 111616
HugePages_Free: 111616
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB

HugePages_Rsvd为零，HugePages_Free跟HugePages_Total一样大，这就代表数据库没有使用大页，没有使用大页服务器占据着内存也不会释放给别人使用，所以才会发生数据库被PMON进程kill的事发生

---

解决问题

设置大页的一些参数
ulimit -l unlimited

cp /etc/security/limits.conf /etc/security/limits20210111.conf

vim /etc/security/limits.conf
增加：
oracle soft memlock unlimited
oracle hard memlock unlimited

这样的话，即时生效和永久生效都设置成功了
两个节点轮流重启数据库
记住观察
cat /proc/meminfo | grep Huge

总结问题

1）通过分析alert日志和相关的trace，在结合系统日志定位故障原因：发现是资源耗尽被系统kill-
2）分析为什么资源会耗尽：查看/proc/meminfo 发现大页开启却未被使用
3）解决问题，以防下次再次发生：调整内存锁的限制，使得大页被oracle使用

---

以下是一些知识的扩展，找机会补上

1、PMON进程的作用

2、oom-killer的意思和缘由

3、使用大页的意义及如何判断是否使用

使用大内存页有哪些好处：

1. 减少页表(Page Table）大小。每一个Huge Page，对应的是连续的2MB物理内存，这样12GB的物理内存只需要48KB的Page Table，与原来的24MB相比减少很多。
2. Huge Page内存只能锁定在物理内存中，不能被交换到交换区。这样避免了交换引起的性能影响。
3. 由于页表数量的减少，使得CPU中的TLB（可理解为CPU对页表的CACHE）的命中率大大提高。
4. 针对Huge Page的页表，在各进程之间可以共享，也降低了Page Table的大小。实际上这里可以反映出Linux在分页处理机制上的缺陷。而其他操作系统，比如AIX，对于共享内存段这样的内存，进程共享相同的页表，避免了Linux的这种问题。像笔者维护的一套系统，连接数平常都是5000以上，实例的SGA在60GB左右，要是按Linux的分页处理方式，系统中大部分内存都会被页表给用掉。

HugePages Total表示系统中配置的大内存页页面数。HugePages Free表示没有访问过的大内存页面数，这里free容易引起误解，这在稍后有所解释。HugePages Rsvd表示已经分配但是还未使用的页面数。Hugepagesize表示大内存页面大小，这里为2MB，注意在有的内核配置中可能为4MB。

计算方法
HugePages_Total=ceil(SGA_MAX_SIZE/Hugepagesize)+N

2. 修改/etc/sysctl.conf文件，增加如下行：
   vm.nr_hugepages=9218
   然后执行sysctl –p命令，使配置生效。
   这里vm.nr_hugepages这个参数值为第2步计算出的大内存页数量。然后检查/proc/meminfo，如果HugePages_Total小于设置的数量，那么表明没有足够的连续物理内存用于这些大内存页，需要重启服务器。

3. 在/etc/security/limits.conf文件中增加如下行：
   oracle soft memlock 18878464
   oracle hard memlock 18878464
   这里设定oracle用户可以锁定内存的大小 ，以KB为单位。
   然后重新以oracle用户连接到数据库服务器，使用ulimit -a命令，可以看到：
   max lockedmemory (kbytes, -l) 18878464
   这里将memlock配置为unlimited也可以。

4. 如果数据库使用MANUAL方式管理SGA，需要改为AUTO方式，即将SGA_TARGET_SIZE设置为大于0的值。对于11g，由于HugePage只能用于共享内存，不能用于PGA，所以不能使用AMM，即不能设置MEMORY_TARGET为大于0，只能分别设置SGA和PGA，SGA同样只能是AUTO方式管理。