[prev in list] [next in list] [prev in thread] [next in thread] 

List:       suse-oracle
Subject:    RE: [suse-oracle] Shared Memory, Bigpages
From:       "Bedard, Joe" <Joe.Bedard () asc ! asrc ! com>
Date:       2005-04-28 22:13:55
Message-ID: A313B75F36EE434CA8AA742AA45F31D40C45A934 () asc-anc-exch ! corp ! ad ! asrc ! com
[Download RAW message or body]

> on i386, using shmfs, the limit is 62GB (metalink note #260152.1).


It is true that Linux can use up to 64 Gigabytes of physical memory on
32-bit x86 system.

However, the address space of 32-bit x86 processors is only 4 GB large.
That means that, if you have a large amount of physical memory, not all
of it can be "permanently mapped" by the
kernel. The physical memory that's not permanently mapped is called
"high memory".

Memory over 4GB's requires a hardware hack of sorts invented by Intel
(PAE) that extends the memory map to 36-bit thus allowing 64GB of total
memory.  There are some major draw backs to this.

PAE uses indirect pointers to the higher memory locations, so there is a
CPU and RAM hit for using this, about 3-6% on average.
PAE mapped memory is accessible only to the CPU and not individual
processes, thus the use of the shared memory file system to access the
memory for Oracle. (adding even more performance hits)
The memory overhead for the added Page table entries to use facilitate
64GB of RAM under PAE are located in the 32-bit 4GB area and can fill up
an already crowded 32-bit memory map.

The most elegant method of achiving large SGA's without cramping the OS
and the PGA area is to use a 64-bit environment.  32-bit x86 has a 3GB
user and 1GB kernel space while x86_64 64-bit is something like 512GB
user / 512GB kernel.  (Andi Kleen, correct me if I am wrong)


-----Original Message-----
From: Magni Fabrizio [mailto:Fabrizio.Magni@rasnet.it] 
Sent: Thursday, April 28, 2005 11:35 AM
To: Alexei Roudnev; Mark.Neis@gisa.de; suse-oracle@suse.com
Subject: RE: [suse-oracle] Shared Memory, Bigpages
Importance: Low

Yep, at a redhat "hands-on" seminar.

I wouldn't replicate it in a production system.

But testing something new is enjoyable. :)

Good night
Fabrizio

PS: Personally I believe that using the memory in such a way is a waste
of money since x86-64 are fair common nowadays.

> -----Original Message-----
> From: Alexei Roudnev [mailto:Alexei_Roudnev@exigengroup.com]
> Sent: Thursday, April 28, 2005 9:17 PM
> To: Magni Fabrizio; Mark.Neis@gisa.de; suse-oracle@suse.com
> Subject: Re: [suse-oracle] Shared Memory, Bigpages
> 
> 
> Did anyone tried it? Can we place a quota from these metalink on the 
> web site (into Ora @ SuSe documentation)?
> 
> 
> ----- Original Message -----
> From: "Magni Fabrizio" <Fabrizio.Magni@rasnet.it>
> To: "Alexei Roudnev" <Alexei_Roudnev@exigengroup.com>; 
> <Mark.Neis@gisa.de>; <suse-oracle@suse.com>
> Sent: Thursday, April 28, 2005 12:04 PM
> Subject: RE: [suse-oracle] Shared Memory, Bigpages
> 
> 
> Alexei,
> on i386, using shmfs, the limit is 62GB (metalink note #260152.1).
> 
> Fabrizio
> 
> 
> > -----Original Message-----
> > From: Alexei Roudnev [mailto:Alexei_Roudnev@exigengroup.com]
> > Sent: Thursday, April 28, 2005 8:45 PM
> > To: Mark.Neis@gisa.de; suse-oracle@suse.com; Magni Fabrizio
> > Subject: Re: [suse-oracle] Shared Memory, Bigpages
> >
> >
> > Then, they should use x86_64 or itanium or PowerPC linux.
> >
> > i386 Oracle shows SGA limit as approx 1.6Gb (1.7 in theory,
> > and 2.5 with few
> > tricks, but it is dangerous to change).
> >
> > ----- Original Message ----- 
> > From: <Mark.Neis@gisa.de>
> > To: <suse-oracle@suse.com>; <Fabrizio.Magni@rasnet.it>
> > Sent: Thursday, April 28, 2005 1:12 AM
> > Subject: RE: [suse-oracle] Shared Memory, Bigpages
> >
> >
> > > Hi Fabrizio,
> > >
> > > you wrote:
> > > > Bigpages are not going to help you.
> > > > They where introduced to decrease the overhead to have to
> > many pages
> > > > mapped in memory.
> > >
> > > I had assumed so from what I read on the web, ok.
> > >
> > >
> > > > shmfs could be a solution but you would hit a performance
> > issue (never
> > > > tried myself: only listened some  "horror stories").
> > >
> > > I didn't, so good you mention it. It sounds plausible, though.
> > >
> > >
> > > > Just out of curiosity: what do you wish to achieve?
> > >
> > > I'm just trying to meet the requirements of our DBAs as good as
> > > possible. They'd like to have large shm segments for the database
> > > of some special geo-data app. On Solaris, they used to configure
> > > Oracle to use  one large shm segment (almost total RAM), and now
> > > they wanted to do it alike on Linux.
> > >
> > > Well, 4 GB will have to suffice.
> > >
> > > Mark
> > >
> > > -- 
> > > To unsubscribe, email: suse-oracle-unsubscribe@suse.com
> > > For additional commands, email: suse-oracle-help@suse.com
> > > Please see http://www.suse.com/oracle/ before posting
> > >
> > >
> >
> >
> 
> 

-- 
To unsubscribe, email: suse-oracle-unsubscribe@suse.com
For additional commands, email: suse-oracle-help@suse.com
Please see http://www.suse.com/oracle/ before posting


-- 
To unsubscribe, email: suse-oracle-unsubscribe@suse.com
For additional commands, email: suse-oracle-help@suse.com
Please see http://www.suse.com/oracle/ before posting

[prev in list] [next in list] [prev in thread] [next in thread]