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

[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分钟的业务停顿.