Hello everyone,
On Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
SHM parameters as:
oracle@ussstdb92
/home/oracle> /sbin/sysctl -a | grep shm
vm.hugetlb_shm_group = 0
error: permission denied on key 'kernel.cad_pid'
error: permission denied on key 'kernel.cap-bound'
kernel.shmmni = 4096
kernel.shmall = 4294967296
kernel.shmmax = 68719476736
I'm trying to see why there are multiple allocation from Oracle for 55G& 768M (why not in single segment) where
NAME TYPE VALUE
------------------------------------ -------------------------------- ------------------------------
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 120G
sga_target big integer 96G
oracle@ussstdb92
/home/oracle> ipcs
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00000000 3407874 root 644 80 2
0x00000000 3440644 root 644 16384 2
0x00000000 3473413 root 644 280 2
0x00000000 4325382 oracle 660 805306368 31
0x00000000 4358151 oracle 660 68719476736 31
0x3188d6d0 4390920 oracle 660 59326332928 31
With HugePages being used as :
oracle@ussstdb92
/home/oracle> grep -i huge /proc/meminfo
HugePages_Total: 61444
HugePages_Free: 43322
HugePages_Rsvd: 43319
Hugepagesize: 2048 kB
oracle@ussstdb92
/home/oracle>
Only 6G of huge pages are used, where even the shared pool is of 7GB (value in table below). Are Hugepages even being used at all ?
When I checked /proc/*/maps for the shmid I got the repeated process directories for all the Oracle shmid's as follows:
oracle@ussstdb92
/home/oracle> grep 4390920 /proc/*/maps
/proc/16188/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16190/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16193/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16197/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16199/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16201/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16203/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16205/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16207/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16209/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16211/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16213/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16215/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16217/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16219/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16221/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16223/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16225/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16227/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16229/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16237/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16239/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16241/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16243/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16247/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16261/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16263/maps:1090000000-1e60200000 rwxs 00000000 00:0d /4390920/ /12 (deleted)
/proc/16265/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/16267/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/17811/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
/proc/20269/maps:1090000000-1e60200000 rwxs 00000000 00:0d 4390920 /12 (deleted)
My question is:
- What does the key "0x0000" means ?
- What actually does "(deleted)" says ? That the part of shared segment this process was using should be destroyed after final detach ? Or if the whole shared segment (64G/55G) etc should be destroyed when no more processes are attached (this makes a bit sense, but would Oracle do that by itself ?)
- Why there's a usage of ~120GB when SGA shows just around 90G ?
- How do we determine how much memory is really used by this instance ? Considering the below SGA Usage:
COMPONENT CURRENT_SIZE
---------------------------------------------------------------- --------------
shared pool 7516192768
large pool 268435456
java pool 268435456
streams pool 536870912
DEFAULT buffer cache 93683974144
KEEP buffer cache 0
RECYCLE buffer cache 0
DEFAULT 2K buffer cache 0
DEFAULT 4K buffer cache 0
DEFAULT 8K buffer cache 0
DEFAULT 16K buffer cache 0
pmap of LGWR shows that to be 120G
oracle@ussstdb92
/home/oracle> ps -ef | grep lgwr
oracle 8482 2674 0 06:24 pts/1 00:00:00 grep lgwr
oracle 16215 1 0 02:47 ? 00:00:03 ora_lgwr_niku
oracle@ussstdb92
/home/oracle> pmap 16215 | tail
00002aaaad382000 1088K rwx-- /dev/zero
00002aaaad492000 1088K rwx-- /dev/zero
00002aaaad5a2000 832K rwx-- /dev/zero
00002aaaad672000 1088K rwx-- /dev/zero
00002aaaad782000 1088K rwx-- /dev/zero
00002aaaad892000 1088K rwx-- /dev/zero
00002aaaad9a2000 832K rwx-- /dev/zero
00007ffffffea000 84K rwx-- [ stack ]
ffffffffff600000 8192K ----- [ anon ]
total 126085512K
oracle@ussstdb92
Hope I made the questions/doubt/scenario are clear :)
thanks