Re: A comp.databases.oracle.server FAQ

From: FM <fabrizio.magni_at_mycontinent.com>
Date: Wed, 25 Aug 2004 17:34:31 +0200
Message-ID: <412cb1b8$2@x-privat.org>

Howard J. Rogers wrote:

> FM wrote:
>
>
>

>>>>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: I'd like to thank you very much again for this suggested fix for
> the 10g - 2.6 kernel issue.
>
> Now that I've had a chance to test it to destruction, I am delighted to
> report that it all works perfectly.
>
> What's more, your fix feels an infinitely more professional solution than
> renaming a file and writing a wrapper script.
>
> For anyone following, Fabrizio's workaround(TM) simply means
> the /etc/sysctl.conf file for a 10g installation now reads:
>
> kernel.shmall = 2097152
> kernel.shmmax = 2147483648
> kernel.shmmni = 4096
> kernel.sem = 250 32000 100 128
> fs.file-max = 65536
> net.ipv4.ip_local_port_range = 1024 65000
> vm/disable_cap_mlock=1
> vm/nr_hugepages=2048
>
> That's actually *all* it reads in Suse 9.1, since there's nothing else in
> there at all (straight after installation I'm talking about). On a Fedora
> machine, there's some other bits and pieces that are already put there...
> so that little lot above is simply tacked onto the end of whatever's
> already there. And then Fedora 2 works, as well.
>
> Brilliant.
> HJR
>
>
>
>
>

Your summarization power is brilliant!

Now I have to update my documentation... :)

-- 
Fabrizio Magni

fabrizio.magni_at_mycontinent.com

replace mycontinent with europe

Received on Wed Aug 25 2004 - 10:34:31 CDT