RE: sga attach linux hugemem /proc/#/maps
- From: "Bobak, Mark" <Mark.Bobak@xxxxxxxxxxxx>
- To: "Jon.Crisler@xxxxxxx" <Jon.Crisler@xxxxxxx>, "ganstadba@xxxxxxxxxxx" <ganstadba@xxxxxxxxxxx>, Oracle-L <oracle-l@xxxxxxxxxxxxx>
- 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,
-Mark
________________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx [oracle-l-bounce@xxxxxxxxxxxxx] On Behalf
Of Crisler, Jon [Jon.Crisler@xxxxxxx]
Sent: Thursday, September 25, 2008 10:37 PM
To: ganstadba@xxxxxxxxxxx; 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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] 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.
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
database
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)
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
