RE: sga attach linux hugemem /proc/#/maps
Date: Thu, 25 Sep 2008 23:59:27 -0400
Hmmm...seems to me, the SGA attach address is something that you don't really have control over.
If you're concerned about hugepage config, you can 'cat /proc/meminfo'. Towards the bottom of the list will be "Hugepages Total" and "Hugepages free". If total > 0, you've got them configured, and if free<total, then you're actually using them. If you're in the situation where you've got hugepages configured, but they're not being used, i.e. total=free, the first thing I'd check for is whether the oracle user has memlock limits defined in /etc/security/limits.conf. If not, that will prevent Oracle from using the hugepages, even if they're configured.
Also, reading the /proc pseudo-filesystem directly is both painful and cumbersome. Try using the pmap command instead: pmap -x <pid of pmon process>
This will easily and clearly display the process memory map, and show the SGA's shared memory segments. (Look for one or more lines with 'shmid=xxxx').
Hope that helps,
From: oracle-l-bounce_at_freelists.org [oracle-l-bounce_at_freelists.org] On Behalf Of Crisler, Jon [Jon.Crisler_at_usi.com] Sent: Thursday, September 25, 2008 10:37 PM To: ganstadba_at_hotmail.com; Oracle-L
Subject: RE: sga attach linux hugemem /proc/#/maps
I cannot explain your findings, but I have played with this many times and found it to be dangerous and unreliable. Its better to use 64 bit Red Hat 4 and Oracle 64 bit, and if needed turn on hugepages.
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Michael McMullen Sent: Thursday, September 25, 2008 11:12 AM To: 'Oracle-L'
Subject: sga attach linux hugemem /proc/#/maps
Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
Linux xxxxxxx01 2.6.9-67.0.7.ELhugemem #1 SMP Wed Feb 27 04:59:22 EST 2008
i686 athlon i386 GNU/Linux
SQL*Plus: Release 10.2.0.3.0 - Production on Thu Sep 25 10:59:54 2008
Due to a corporate reorg I'm helping out a group that used to have 3
and is now down to one. No documentation/build books to check out. The developers have asked me to look at a problem. I've thinked they've side tracked me because I don't have access to their metalink CSI# yet and haven't been able to check out their tar. They've asked me to verify the SGA
is attached properly because they set up hugemem.
I've been following note #211424.1 and it looks like it's o.k.
That note led me to note #270382.1
This article will assist you on verify the current SGA attach address
b. If an instance is running, check it's attach address:
i. Get the pid of its PMON process. For example:
$ ps -ef | grep ora_pmon_EMR920W3 emrdbms 20355 1 0 01:28 ? 00:00:00ora_pmon_EMR920W3
ii. Now check the map address of the SysV shared memory segment using
the pid of the PMON process found above:
$ grep deleted /proc/20355/maps 50000000-50400000 rw-s 00000000 00:04 156663874 /SYSV00000000 (deleted) (...) Again, the first number (50000000) shows the hex address where the SGA will be attached.
I get multiple entries. I've checked other databases on other servers
running both the same redhat version and I only get one entry. This
does have multiple _pool_size parameter set and I just now noticed that they
must have alter system privs and are changing things on the fly. This has
now officially moved to not my responsibility but anyways can anyone explain
why there are multiple entries in /proc/#/maps. The server was rebooted yesterday.
grep delete /proc/6371/maps
12000000-1f200000 rw-s 00000000 00:06 622597 /SYSV8695b0a8 (deleted) 20000000-21000000 rw-s 00000000 00:06 65536 /SYSV00000000 (deleted) 21000000-8e000000 rw-s 00000000 00:06 196609 /SYSV00000000 (deleted) 8e000000-c5000000 rw-s 00000000 00:06 327682 /SYSV00000000 (deleted) c5000000-e0000000 rw-s 00000000 00:06 458755 /SYSV00000000 (deleted) e0000000-ee000000 rw-s 00000000 00:06 589828 /SYSV00000000 (deleted)
http://www.freelists.org/webpage/oracle-l Received on Thu Sep 25 2008 - 22:59:27 CDT