¶Why isn't Oracle DB using any hugepages? Is there any issue with setting memlock value to unlimited when setting hugepages for oracle? Is it necessary to be equal to maximum SGA size of oracle database?
OS/Linux
[RHEL] What is an approprite memlock value in limits.conf when using hugepages for an Oracle DB on RHEL
SYPER
2014. 3. 8. 23:02
문제
환경
- Red Hat Enterprise Linux (RHEL)
- Oracle Database
- Red Hat Enterprise Linux (RHEL)
- Oracle Database
해결
¶Setting the memlock value to unlimited is fine for use with Oracle, it's just an upper boundary for the given user or group. Oracle will constrain itself to whatever you have configured. The amount of memory set aside for hugepages relative to the SGA size is adequate.
¶The Oracle DB will need to be enabled to use hugepages in order to see "HugePages_Rsvd" rise above 0 in /proc/meminfo. Automatic Shared Memory Management will need to be disabled (remove SGA_TARGET in the Oracle configuration) in order to use hugepages, however the DBA and/or DB vendor should have more authoritative input here.
¶Use the group of the user that the Oracle DB is running as in limits.conf.
¶Setting the memlock value to unlimited is fine for use with Oracle, it's just an upper boundary for the given user or group. Oracle will constrain itself to whatever you have configured. The amount of memory set aside for hugepages relative to the SGA size is adequate.
¶The Oracle DB will need to be enabled to use hugepages in order to see "HugePages_Rsvd" rise above 0 in /proc/meminfo. Automatic Shared Memory Management will need to be disabled (remove SGA_TARGET in the Oracle configuration) in order to use hugepages, however the DBA and/or DB vendor should have more authoritative input here.
¶Use the group of the user that the Oracle DB is running as in limits.conf.
근본 원인
- The root cause of the issue appears to be the use of an invalid @group name in limits.conf.
- The root cause of the issue appears to be the use of an invalid @group name in limits.conf.
진단 단계
¶Oracle DB is currently using ~22G for SGA:
# ipcs -m | grep oraram
0xac2e99a0 655361
oraramlive640 23624417280 39
¶memlock limit set higher than SGA:
# grep memlock /etc/security/limits.conf
# - memlock - max locked-in-memory address space (KB)
@dba soft memlock unlimited
@dba hard memlock unlimited
¶Hugepages enabled and number Free is sufficient for SGA (2048KiB * 15360 = 30GiB); MemTotal is greater than HugePages_Total. However, no hugepages are in use (HugePages_Rsvd=0):
# egrep "MemTotal|Huge" /proc/meminfo
MemTotal: 263638128 kB
HugePages_Total: 15360
HugePages_Free:
15360
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
¶sysctl's are sufficient:
kernel.shmmax = 32212254720
kernel.shmmni = 4096
kernel.msgmni=2878
kernel.msgmax=8192
kernel.msgmnb=65535
kernel.shmall = 32954766
¶Oracle DB is currently using ~22G for SGA:
# ipcs -m | grep oraram 0xac2e99a0 655361 oraramlive640 23624417280 39¶memlock limit set higher than SGA:
# grep memlock /etc/security/limits.conf # - memlock - max locked-in-memory address space (KB) @dba soft memlock unlimited @dba hard memlock unlimited¶Hugepages enabled and number Free is sufficient for SGA (2048KiB * 15360 = 30GiB); MemTotal is greater than HugePages_Total. However, no hugepages are in use (HugePages_Rsvd=0):
# egrep "MemTotal|Huge" /proc/meminfo MemTotal: 263638128 kB HugePages_Total: 15360 HugePages_Free: 15360 HugePages_Rsvd: 0 Hugepagesize: 2048 kB¶sysctl's are sufficient:
kernel.shmmax = 32212254720 kernel.shmmni = 4096 kernel.msgmni=2878 kernel.msgmax=8192 kernel.msgmnb=65535 kernel.shmall = 32954766
Hugepages are not incompatible with "Automatic Shared Memory Management" as the article says. They are incompatible with Automatic Memory Managagment (AMM, memory_taget).