Re: A comp.databases.oracle.server FAQ

From: FM <fabrizio.magni_at_mycontinent.com>
Date: Tue, 24 Aug 2004 08:48:16 +0200
Message-ID: <412ae4e9$2@x-privat.org>

Howard J. Rogers wrote:

> 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
>
>
>
>

/etc/sysctl.conf is the right place.
Place vm/disable_cap_mlock=1 and vm/nr_hugepages=2048 and test with syctl -p (gfaster than a reboot).

The number of huge pages should be related to you RAM and the pagesize (default is 2 MB).

Glad be have some useful stuff.
Your posts helped me more than a thousand times!

-- 
Fabrizio Magni

fabrizio.magni_at_mycontinent.com

replace mycontinent with europe

Received on Tue Aug 24 2004 - 01:48:16 CDT