[20191202]关于oracle实例是否使用hugepages问题.txt --//前几天论坛的讨论,别人问我为什么什么依据判断是否使用hugepages问题,实际上我也不知道. --//我自己也在想如何判断oracle实例是否使用hugepages的问题.自己也做一点总结: 1.检查/proc/meminfo的输出: # grep -i page /proc/meminfo AnonPages: 90672 kB PageTables: 5956 kB AnonHugePages: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB --//这是最直观的方式,但是如果你服务器启动多了实例,那些实例使用,那些没有通过这个就很难判断. --//而且还有一个问题,oracle现在可以设置use_large_pages=true,false,auto,only. --//你查询参数use_large_pages,描述上说明Use large pages if available (TRUE/FALSE/ONLY),缺省就是true,如果设置false,实际上 --//就不用. 如果参数为True,那么当系统的HugePage被使用尽,只有small pages的情况下,SGA也会继续运行。此时,Oracle实例就运行在内存使用 混合模式(Mixed Mode)下。 如果参数为是Only,从含义上,表示Oracle实例只会使用HugePage作为内存使用。如果系统在AMM模式或者HugePage用尽的时候,数据库 就不能启动或者报错。 如果参数为是false,就不使用HugePage. 2.使用smem观察: --//仅仅观察实例对应的后台进程的通过smem查询发现.USS占用很大,基本可以确定没有使用. # smem -tk -U oracle -P "ora_.*_xxxxx1" PID User Command Swap USS PSS RSS ..... 21557 oracle ora_mman_xxxxx1 0 348.1M 687.7M 2.5G 21561 oracle ora_dbw1_xxxxx1 0 120.5M 1.0G 4.9G 21559 oracle ora_dbw0_xxxxx1 0 117.0M 1.1G 5.2G 21563 oracle ora_dbw2_xxxxx1 0 119.7M 1.1G 5.2G 21565 oracle ora_dbw3_xxxxx1 0 135.5M 1.1G 5.2G 21545 oracle ora_lms1_xxxxx1 0 755.5M 2.0G 6.9G 21541 oracle ora_lms0_xxxxx1 0 764.7M 2.1G 7.0G 21549 oracle ora_lms2_xxxxx1 0 791.2M 2.2G 7.4G ------------------------------------------------------------------------------- 54 1 0 3.6G 12.6G 54.4G --//而使用hugepages根本看不到这样的情况.当然仅仅时经验之谈,只要运行有一段时间,都可以看到这样的情况. 3.查看alert*.log文件: --//数据库启动时查看alert日志,可以发现如下信息: Fri Nov 29 10:10:47 2019 Adjusting the default value of parameter parallel_max_servers from 480 to 170 due to the value of parameter processes (200) Starting ORACLE instance (normal) ************************ Large Pages Information ******************* Parameter use_large_pages = ONLY Per process system memlock (soft) limit = 51 GB Total Shared Global Region in Large Pages = 618 MB (100%) Large Pages used by this instance: 309 (618 MB) Large Pages unused system wide = 0 (0 KB) Large Pages configured system wide = 309 (618 MB) Large Page size = 2048 KB ******************************************************************** 4.查看/proc/<spid>/numa_maps相关信息: $ ps -ef | grep "[o]ra_pmon_.*" | awk '{print $2}' | xargs -IQ grep 'huge dirty=' /proc/Q/numa_maps 60000000 default file=/SYSV00000000\040(deleted) huge dirty=1 mapmax=25 N0=1 60c00000 default file=/SYSV00000000\040(deleted) huge dirty=35 mapmax=25 N0=28 N1=7 86800000 interleave:0-1 file=/SYSVe8a8ec10\040(deleted) huge dirty=1 mapmax=25 N0=1 --//也就是查询共享内存段时候包含huge dirty --//补充执行以下命令更为准确. $ ps -ef | grep "[o]ra_pmon_.*" | awk '{print $2}' | xargs -IQ grep "SYSV" /proc/Q/numa_maps 5.检查oracle参数: SYS@book> show parameter memory_ NAME TYPE VALUE ------------------------ ----------- ------- hi_shared_memory_address integer 0 memory_max_target big integer 0 memory_target big integer 0 shared_memory_address integer 0 --//检查memory_*参数是否是0,不过这个并不能确定是否使用hugepages,仅仅能确定有可能. 6.问题: --//问题在于如果是混合模式,以上判断可能就不是很准.仅仅能判断是否使用hugepages. --//修改/etc/sysctl.conf如下: vm.nr_hugepages = 104 vm.nr_overcommit_hugepages = 0 --//修改参数*.use_large_pages='TRUE'. --//重启启动数据库,alert提示如下: Mon Dec 02 08:50:18 2019 Adjusting the default value of parameter parallel_max_servers from 480 to 170 due to the value of parameter processes (200) Starting ORACLE instance (normal) ************************ Large Pages Information ******************* Per process system memlock (soft) limit = 51 GB Total Shared Global Region in Large Pages = 208 MB (33%) Large Pages used by this instance: 104 (208 MB) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Large Pages unused system wide = 0 (0 KB) Large Pages configured system wide = 104 (208 MB) Large Page size = 2048 KB RECOMMENDATION: Total System Global Area size is 618 MB. For optimal performance, prior to the next instance restart: 1. Increase the number of unused large pages by at least 205 (page size 2048 KB, total size 410 MB) system wide to get 100% of the System Global Area allocated with large pages ******************************************************************** --//仅仅从alter看到相关信息使用hugepages,而且是混合模式. $ grep -i page /proc/meminfo AnonPages: 149212 kB PageTables: 14540 kB AnonHugePages: 0 kB HugePages_Total: 104 HugePages_Free: 51 HugePages_Rsvd: 51 HugePages_Surp: 0 Hugepagesize: 2048 kB $ ps -ef | grep "[o]ra_pmon_.*" | awk '{print $2}' | xargs -IQ grep 'huge.*dirty=' /proc/Q/numa_maps 60000000 default file=/SYSV00000000\040(deleted) huge dirty=1 mapmax=20 N0=1 $ ps -ef | grep "[o]ra_pmon_.*" | awk '{print $2}' | xargs -IQ grep 'SYSV' /proc/Q/numa_maps 60000000 default file=/SYSV00000000\040(deleted) huge dirty=1 mapmax=20 N0=1 60c00000 default file=/SYSV00000000\040(deleted) huge 6a400000 default file=/SYSV00000000\040(deleted) huge 6c400000 default file=/SYSV00000000\040(deleted) huge 6cc00000 default file=/SYSV00000000\040(deleted) huge 6d000000 interleave:0-1 file=/SYSV00000000\040(deleted) dirty=737 mapmax=20 active=128 N0=372 N1=365 86800000 interleave:0-1 file=/SYSVe8a8ec10\040(deleted) dirty=1 mapmax=20 N1=1 --//这样查询更为准确. $ ipcs ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 411860993 oracle 640 12582912 20 0x00000000 411893762 oracle 640 159383552 20 0x00000000 411926531 oracle 640 33554432 20 0x00000000 411959301 oracle 640 8388608 20 0x00000000 411992070 oracle 640 4194304 20 0x00000000 412024839 oracle 640 427819008 20 0xe8a8ec10 412057608 oracle 640 2097152 20 ------ Semaphore Arrays -------- key semid owner perms nsems 0x6aa88594 334462976 oracle 640 204 ------ Message Queues -------- key msqid owner perms used-bytes messages --//这样可以发现hugepages的共享内存段被分割好几段,实际上我这里是5段. $ sysresv IPC Resources for ORACLE_SID "book" : Shared Memory: ID KEY 411860993 0x00000000 411893762 0x00000000 411926531 0x00000000 411959301 0x00000000 411992070 0x00000000 412024839 0x00000000 412057608 0xe8a8ec10 Semaphores: ID KEY 334462976 0x6aa88594 Oracle Instance alive for sid "book" $ ps -ef | grep pmo[n] oracle 54880 1 0 08:50 ? 00:00:00 ora_pmon_book $ pmap -x 54880 | grep "SYSV\|shm\|^Address" Address Kbytes RSS Dirty Mode Mapping 0000000060000000 12288 0 0 rw-s- SYSV00000000 (deleted) 0000000060c00000 155648 0 0 rw-s- SYSV00000000 (deleted) 000000006a400000 32768 0 0 rw-s- SYSV00000000 (deleted) 000000006c400000 8192 0 0 rw-s- SYSV00000000 (deleted) 000000006cc00000 4096 0 0 rw-s- SYSV00000000 (deleted) 000000006d000000 417792 2948 2948 rw-s- [ shmid=0x188f0007 ] 0000000086800000 2048 4 4 rw-s- [ shmid=0x188f8008 ] --//这样看来如果处于混合模式,使用smem查看的经验也未必准确,最佳的方式是查看alert启动日志以及查询 --///proc/<spid>/numa_maps包含相关SYSV相关行信息.
[20191202]关于oracle实例是否使用hugepages问题.txt
来源:这里教程网
时间:2026-03-03 14:40:26
作者:
编辑推荐:
下一篇:
相关推荐
-
雷神推出 MIX PRO II 迷你主机:基于 Ultra 200H,玻璃上盖 + ARGB 灯效
2 月 9 日消息,雷神 (THUNDEROBOT) 现已宣布推出基于英
-
制造商 Musnap 推出彩色墨水屏电纸书 Ocean C:支持手写笔、第三方安卓应用
2 月 10 日消息,制造商 Musnap 现已在海外推出一款 Oce
热文推荐
- 最佳实践 | 数据库迁云解决方案选型 & 流程全解析
最佳实践 | 数据库迁云解决方案选型 & 流程全解析
26-03-03 - Oracle date 类型比较和String比较
Oracle date 类型比较和String比较
26-03-03 - OPPO用户怎么让手机变流畅?花1分钟关闭这4个设置,瞬间变流畅
OPPO用户怎么让手机变流畅?花1分钟关闭这4个设置,瞬间变流畅
26-03-03 - 4 个概念,1 个动作,让应用管理变得更简单
4 个概念,1 个动作,让应用管理变得更简单
26-03-03 - 如何分析及处理 Flink 反压?
如何分析及处理 Flink 反压?
26-03-03 - 基于 Flink 的实时数仓生产实践
基于 Flink 的实时数仓生产实践
26-03-03 - 中报背后的阿里影业:互联网影视如何沉淀平台方法论
中报背后的阿里影业:互联网影视如何沉淀平台方法论
26-03-03 - oracle 报大小写错误
oracle 报大小写错误
26-03-03 - oracle 函数
oracle 函数
26-03-03 - oracle
oracle
26-03-03
