RE: sga attach linux hugemem /proc/#/maps
Date: Fri, 26 Sep 2008 08:59:55 -0400
Message-ID: <BAY141-DAV138B0417E4A41E1FBDF076A6470@phx.gbl>
Message-ID: <F626BA5035746548AF2DF3E71FEB5257220877BA82@MBX01.bell.corp.bce.ca>
I did get sidetracked. Their actual error is ora-4030 out of process memory which points to PGA not SGA.
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Bobak, Mark
Sent: September 25, 2008 11:59 PM
To: Jon.Crisler_at_usi.com; ganstadba_at_hotmail.com; 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,
-Mark
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.
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[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
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 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
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
ora_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.
--
http://www.freelists.org/webpage/oracle-l
Received on Fri Sep 26 2008 - 07:59:55 CDT