[20221125]设置hugepages遇到的问题.txt

--//前几天我在dg上修改oracle一个参数,要重启才生效,我看了一下数据库没有采用hugepages,想着顺手设置hugepages,没想到遇到问题
--//,我开始以为业务不会受影响.没想到开发或者同事有一些查询移到dg上利用它做只读查询完成,导致前台一些查询业务受到短暂的影
--//响.做一个事后记录分析总结,避免以后重犯类似错误.

1.环境:
SYS@192.168.100.237:1521/orcldg> @pr
==============================
PORT_STRING                   : x86_64/Linux 2.4.xx
VERSION                       : 19.0.0.0.0
BANNER                        : Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
BANNER_FULL                   : Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
BANNER_LEGACY                 : Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
CON_ID                        : 0
PL/SQL procedure successfully completed.

2.遇到问题1:
--//配置hugepages要修改/etc/security/limits.conf,加入如下内容.
# grep memlock /etc/security/limits.conf
#        - memlock - max locked-in-memory address space (KB)
oracle   soft  memlock  unlimited
oracle   hard  memlock  unlimited

--//而我操作界面使用tmux登录,重启数据库后,root执行sysctl -p后,直接startup,导致数据库无法启动.
--//不过我马上明白过来,要重新退出在登录oracle用户.执行就ok了.

--//可以做一个简单测试:
--//注解memlock内容:
# grep memlock /etc/security/limits.conf
#        - memlock - max locked-in-memory address space (KB)
#oracle   soft  memlock  unlimited
#oracle   hard  memlock  unlimited

# su - oracle
$ grep "Max locked memory" /proc/self/limits
Max locked memory         65536                65536                bytes
--//soft , hard memlock = 65536  字节,太小了.

--//取消注解memlock内容:
# grep memlock /etc/security/limits.conf
#        - memlock - max locked-in-memory address space (KB)
oracle   soft  memlock  unlimited
oracle   hard  memlock  unlimited

# su - oracle
$ grep "Max locked memory" /proc/self/limits
Max locked memory         unlimited            unlimited            bytes
--//soft , hard memlock = unlimited.
--//总之遇到这类问题要保持清醒的头脑,意识到退出会话再登录再执行就可以了.
--//另外参考链接http://blog.itpub.net/267265/viewspace-2645466/=>[20190523]修改参数后一些细节注意2.txt,
--//当时的测试也给了我现在很大帮助.

3.遇到问题2:
--//sga_max_size,sga_target设置8G,我想设置vm.nr_hugepages = 4100,于是修改如下::
# grep vm.nr /etc/sysctl.conf
vm.nr_hugepages = 4100
vm.nr_overcommit_hugepages = 1300

# sysctl -p | grep vm.nr
vm.nr_hugepages = 4100
vm.nr_overcommit_hugepages = 1300
--//注意一定要关闭数据库再执行sysctl -p,不然更加无法获得规定数量的vm.nr_hugepages.
--//感觉上这样已经设置,而实际上linux无法找到一个这个大chunk的memory.导致实际的设置情况是:
# sysctl vm.nr_hugepages
vm.nr_hugepages = 3758

--//这样的结果导致仅仅部分oracle共享内存使用hugepages.我开始不知道卡在这里,查看:
$ grep -i HugePages_Total /proc/meminfo
HugePages_Total:    3758

# free -m
              total        used        free      shared  buff/cache   available
Mem:          15751        8622         167         321        6962        6424
Swap:         20479        1087       19392

--//主要原因是无法获取满足需要的大chunk内存,设置vm.nr_hugepages的需求.
--//所以以后设置要注意这些细节问题,应该再安装配置dg时做好这些前期工作.
--//当发现内存不足是,我还修改启动模式为multi-user.target,顺便做一个记录,但是还是无法设置vm.nr_hugepages = 4100
# systemctl set-default multi-user.target
# systemctl isolate multi-user.target
# who -r
         run-level 3  2022-11-23 11:31                   last=5

--//最后,我还是修改sga_max_size,sga_target=7500M.保证数据库启动,先不影响业务的执行.
--//实际上这台服务器还是表现内存不足的情况

4.今天上班尝试取消一些不必要的服务看看:

# systemctl disable ModemManager.service
Removed symlink /etc/systemd/system/multi-user.target.wants/ModemManager.service.
Removed symlink /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service.

# systemctl stop ModemManager.service

# systemctl disable postfix.service
Removed symlink /etc/systemd/system/multi-user.target.wants/postfix.service.
# systemctl stop postfix.service

# systemctl disable cups.service
# systemctl stop cups.service

# sysctl -p
...
# sysctl vm.nr_hugepages
vm.nr_hugepages = 3758

--//还是不行.不知道是否应该先关闭数据库再执行sysctl -p,生产系统不干乱动,暂时放弃!!

5.总结:
--//重启dg前,最好先问一下同事是否可行,因为不知道一些具体的业务情况.
--//事前配置好数据库参数以及相关设置,尽量避免这种中间改动维护工作,导致时间仓促,现场导致30分钟的业务停顿.