RE: sga attach linux hugemem /proc/#/maps

From: Michael McMullen <>
Date: Fri, 26 Sep 2008 08:59:55 -0400
Message-ID: <BAY141-DAV138B0417E4A41E1FBDF076A6470@phx.gbl>
Message-ID: <>

I did get sidetracked. Their actual error is ora-4030 out of process memory which points to PGA not SGA.

-----Original Message-----

From: [] On Behalf Of Bobak, Mark
Sent: September 25, 2008 11:59 PM
To:;; Oracle-L Subject: RE: sga attach linux hugemem /proc/#/maps

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: [] On Behalf Of Crisler, Jon [] Sent: Thursday, September 25, 2008 10:37 PM To:; 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.

-----Original Message-----

[] On Behalf Of Michael McMullen Sent: Thursday, September 25, 2008 11:12 AM To: 'Oracle-L'
Subject: sga attach linux hugemem /proc/#/maps

cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 4)

Uname -a
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 - 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 dba's
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:00

     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

         Again, the first number (50000000) shows the hex address where
         the SGA will be attached.

-- Received on Fri Sep 26 2008 - 07:59:55 CDT

Original text of this message