故障描述

2021年8月30日9点15分客户反映统一号源库卡顿，楼下自助挂号机异常等待，经查证为his的故障，his库内存满载，

导致其他库到his库的dblink查询出现故障。

大页的概念

内存都是以页的形式划分的，默认情况下每页是4K，这就意味着如果物理内存很大，则映射表的条目将会非常多，

会影响CPU的检索效率。因为内存大小是固定的，为了减少映射表的条目，可采取的办法只有增加页的尺寸。

这种增大的内存页尺寸在Linux 2.1中，称为Big page；在AS 3/4中，称为Hugepage

在Linux中配置hugepage可以提高oracle的性能，减少oracle sga的页交换，类似于aix中的lagepage。

当你主机的物理内存为64G，设SGA>=32G时，建议开启大页

问题详细诊断过程

观察oracle官方监控oswatch，发现卡顿时间内的swap使用过高，说明当时内存已经近乎满载。

可以看到当时消耗内存最高的为udisks-daemon进程

Oracle官方论坛Mos上可见udisks-daemon占大量内存为bug，文档（Doc ID 2281732.1），

特征为udisks-daemon进程使用内存较大

查看db alert日志可以看到oracle建议最少增加大页数量35838，大小70g，可以发现oracle认为大页的配置不佳。

此时可以判断出结果，因udisks-daemon的bug占用部分内存（100+G），且大页配置参数不正确，导致内存满负荷

，导致业务崩溃。

重新运行官方脚本hugepages_settings.sh，计算大页数量的值

见本人其他文章

oracle 大页配置详细介绍

根据最新算出的大页数131595，将/etc/sysctl.conf中的大页参数修改为

vm.nr_hugepages = 131595

接着根据大页数设置内存锁，/etc/security/limits.conf中添加

* soft memlock 269527040

* hard memlock 269527040

于2021年8月30日晚上10点重启主机使大页生效，再次查看db alert日志发现已经不再有RECOMMENDATION建议

并且查看大页使用情况也可看到大页正在使用

grep Huge /proc/meminfo

经过2021年8月30日的修改大页参数修改后，2021年8月31日保障，数据库his、emr库主机内存使用正常