oracle一次卡顿案例(七)-swap

故障描述

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库主机内存使用正常