Re: A comp.databases.oracle.server FAQ

From: Howard J. Rogers <hjr_at_dizwell.com>
Date: Wed, 25 Aug 2004 17:37:08 +1000
Message-ID: <412c41a1$0$6809$afc38c87@news.optusnet.com.au>

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 Received on Wed Aug 25 2004 - 02:37:08 CDT