Re: Machine's high load when HIGHMEM is enabled

[Gerrit Huizenga <gh@us.ibm.com>]

Oracle usually likes its SGA locked in memory, so if it is
set to request 800 MG of RAM on a 1 GB machine, I think you
have tuned Oracle to be requesting too much SGA for your
hardware.

gerrit

In message <3DDA070F.CF2047BF@digeo.com>, > : Andrew Morton writes:
> vasya vasyaev wrote:
> > 
> > Hi again,
> > 
> > Let me try to explain what is this all about...
> > 
> > Box has 1 GB of RAM, it's running oracle database.
> > After some disk activity disk cache has 400 Mb, so 600
> > Mb is free
> 
> And the other 400 megabytes will be freed up on demand.
> 
> > Oracle is tuned for using of 800 Mb of RAM for SGA (as
> > shared memory segment), so Oracle needs 800 Mb of RAM
> > to be free before it's start, right ?
> 
> No...  If that were so, you'd never be able to start any
> applications.
> 
> > So when oracle starts it can't allocate this 800 Mb
> > for SGA and fails to start...
> 
> Well, maybe Oracle is failing to start.  But maybe that's
> not for the reasons you are assuming.
> 
> > Where is a problem - in kernel which can't reduce disk
> > cache to allow allocating of shared memory segment or
> > in oracle ?
> 
> If Oracle requests 800 megabytes from the kernel, it will get it.
> It won't be able to mlock it (I'm guessing here).
>  
> > BTW, free doesn't show that shared memory is in use
> > when oracle is started and requested shared memory
> > segment is allocated (and ipcs shows it).
> 
> Yup, the "shared" accounting is always zero.  Maybe we should
> fix that, or remove it.
>  
> > We need to control disk cache to reduce it as much as
> > possible because it's not needed for oracle, much
> > better is to allow oracle to control the RAM
> > for it's use.
> > 
> > As to compare, on solaris we mount ufs with
> > "forcedirectio" mount option, which tells not to use
> > disk cache.
> 
> Please ensure that the failure is not some Oracle-specific setup
> thing, and then provide specific details on the problem which you
> are observing.  The assumptions which you are making may not be
> correct.
> 
> Thanks.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/