Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: A comp.databases.oracle.server FAQ

Re: A comp.databases.oracle.server FAQ

From: Howard J. Rogers <hjr_at_dizwell.com>
Date: Tue, 24 Aug 2004 16:36:16 +1000
Message-ID: <412ae1e1$0$3928$afc38c87@news.optusnet.com.au>


FM wrote:

> Howard J. Rogers wrote:
>
>

>>>
>>>Have you tried echo "1" > /proc/sys/vm/disable_cap_mlock?
>>>
>>>It didn't worked for me but I was on SLES9 and on a x86-64 architecture.
>> 
>> 
>> No, I haven't tried that. I have no experience with SLES9 at all, so I
>> don't doubt you. The thing I was talking about is rather different, I
>> think, since it has to do with a new feature of the 2.6 kernel which is
>> enabled by default called HUGETLBFS. You have to set an environment
>> variable, DISABLE_HUGETLBFS=1, before invoking tools such as dbca... but
>> you can't (apparently) just stick it in as part of your usual environment
>> variable set. It needs to be in a wrapper script called 'oracle'. Details
>> in the Google archive for this group (search for the thread "Help: 10g on
>> Fedora Core 2, ORA-27125")
>> 
>> Regards
>> HJR

>
> Testing now on SuSE Linux Enterprise Server 9:
>
> echo 2048 > /proc/sys/vm/nr_hugepages
>
> (Test if all is ok with /cat/proc/meminfo).
>
> mount a hugetlb file system:
>
> I have this in my fstab
> hugetlbfs /dev/hugetlbfs hugetlbfs
> mode=0777,uid=59,gid=55 0 0
>
> where uid is my oracle10g user and gid my dba group.
>
> (have a look at hugetlbpage.txt in your kernel sources).
>
> echo "1" > /proc/sys/vm/disable_cap_mlock
>
> This last command should allow every user to use the hugetlbfs (from
> kernel 2.6.7 there is a /proc/sys/vm/hugetlb_shm_group).
>
> Then open the instance. The DISABLE_HUGETLBFS=1 (and the wrapper)
> shouldn't be necessary anymore.
>
> Look in /proc/meminfo to check in oracle is using the hugetlb.

This is good stuff!

Now, obviously you don't want to be echoing into /proc every time after a reboot. So what's the permanent fix?

I realise you could stick the echo command into a startup script, but I've always disliked doing that. Used to do it that way, for example, for the kernel parameters -until I discovered /etc/sysctl.conf, which seems to me to be the "right" place for persistent configuration changes like that.

This disable_cap_mlock seems to me to be in exactly the same league. So instead of echoing into /proc, can you add a line to sysctl.conf (or an equivalent on appropriate distros) to achieve the same result? If so, what would it be? For example, echo 250 3200 128 100 > sem became kernel.sem=250 32000 etc etc etc. Would it therefore be kernel.disable_cap_mlock=1 or something?? (almost certainly not, but you get the idea of what I'm after, I hope).

I'd test it myself, except I am clueless at anything more strenuous than C:\

:-)
Regards
HJR Received on Tue Aug 24 2004 - 01:36:16 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US