Linux, SHMMAX and Oracle
Bill Buchan
I'm installing Oracle 8i on Linux. According to the installation notes,
Oracle recommends setting setting the kernel parameter to 0.5 * the
physical memory.
Currently my value is set at 32Mb (0x2000000), and real memory is 1Gb so
it would seem that I should increase it.
However the comments in the file /usr/src/linux/include/asm/shmparam.h
recomment _not_ changing it, as people rely on it.
Also, I've never recompiled a kernel before (and it frightens me!) so
I'd rather just put Oracle on and come back and do this later if
required.
My question then is, what is the effect of not upping this parameter and
recompiling? Will I be limiting the maximum size of SGA I can define?
People have told me not to worry about it, but I worry about why I
shouldn't worry about it...
Any information gratefully received.
Thanks
- Bill.
Michael Heiming
Hello,
from another reply I wrote some weeks ago,
[]
I've done this for Adabas RDBMS which really did speed it up.
I edited /usr/src/linux/include/asm/shmparam.h
-#define SHMMAX 0x2000000 /* max shared seg size (bytes) */
+#define SHMMAX 0x8000000 /* max shared seg size (bytes) */
/* Try not to change the default shipped SHMMAX - people rely on it */
and recompiled the kernel.
[]
There are some tools like top who display shared somehow wrong if you
change SHMMAX,
but asuming you are running only your DB on this machine, I wouldn't be to
concernd about this.
As you should have no other progs running, relying on SHMMAX., but I have
no expirience on SHMMAX and Oracle.
A kernel compile speeds you machine up, you get a newer kernel (2.4.x), as
most distros
don't come with the new version, these days. You can set special params for
your CPU, that general
precompiled kernels most times miss, as they are made to run on many
different CPU.
Read the Kernel-HowTo and Documentation/Changes that comes with every
kernel source tarball.
http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html
Good luck
Michael Heiming
Thank god it's friday today...
Nuno Souto
<wbu...@uk.noha-systems.com> wrote:
>Currently my value is set at 32Mb (0x2000000), and real memory is 1Gb so
>it would seem that I should increase it.
Yes. But not in a hurry.
>
>However the comments in the file /usr/src/linux/include/asm/shmparam.h
>recomment _not_ changing it, as people rely on it.
Weird. Im not aware of any requirement anywhere for a default SHMMAX?
Other than h/w or OS limitations.
>
>Also, I've never recompiled a kernel before (and it frightens me!) so
>I'd rather just put Oracle on and come back and do this later if
>required.
Which you can do. Get heaps of info on the "recompile the kernel
bit", then do it once you are confident.
>
>My question then is, what is the effect of not upping this parameter and
>recompiling?
If you're running on segmented memory architecture (Intel + most of
the RISC chips), you slow down a bit if your SGA is across multiple
segments. Basically, SHMMAX defines the biggest segment of shared
memory that will be allocated. The size of the SGA is divided by this
and that defines the number of allocations needed to create the SGA.
Addressing across segments in this h/w architecture is expensive.
That's all.
>Will I be limiting the maximum size of SGA I can define?
In theory yes. In practice, no. The OS will allocate as many
"chunks" of SHMMAX size up to the number in SHMSEG. Which will be a
larger number than you need.
>People have told me not to worry about it, but I worry about why I
>shouldn't worry about it...
That's a worry.
<G>
Cheers
Nuno Souto
nso...@bigpond.net.au.nospam
http://www.users.bigpond.net.au/the_Den/index.html
Ville Karaila
>On Fri, 16 Feb 2001 10:27:02 +0000, Bill Buchan
><wbu...@uk.noha-systems.com> wrote:
>>However the comments in the file /usr/src/linux/include/asm/shmparam.h
>>recomment _not_ changing it, as people rely on it.
>Weird. Im not aware of any requirement anywhere for a default SHMMAX?
>Other than h/w or OS limitations.
I think there is no alternative method to increase size on shared
memory segment.. :(
>>Also, I've never recompiled a kernel before (and it frightens me!) so
>>I'd rather just put Oracle on and come back and do this later if
>>required.
>Which you can do. Get heaps of info on the "recompile the kernel
>bit", then do it once you are confident.
And actually you have to recompile and link the dbms, so compiling
kernel is nothing.. ;) On Oracle 8i (8.1.5) you have to change
location of shm area which is allocated in an assembler file, which
can be generated by tool included.. This was a common procedure on
solaris versions, but I think I was first person (at least in finland)
to do this for linux version above.. I can say I was not quite happy
to do that but don't worry. You can always restore binaries from
backup.. :^)
>>Will I be limiting the maximum size of SGA I can define?
>In theory yes. In practice, no. The OS will allocate as many
>"chunks" of SHMMAX size up to the number in SHMSEG. Which will be a
>larger number than you need.
Only limitation is that the SGA "fragments" while all processes see the
same address space (at least I figured out that way?), so if you
increase the limit, it is more likely that there exists a _large_
enough segment.
--
VK
Nuno Souto
wrote:
>
>>Which you can do. Get heaps of info on the "recompile the kernel
>>bit", then do it once you are confident.
>
>And actually you have to recompile and link the dbms, so compiling
>kernel is nothing.. ;) On Oracle 8i (8.1.5) you have to change
>location of shm area which is allocated in an assembler file, which
>can be generated by tool included.. This was a common procedure on
>solaris versions, but I think I was first person (at least in finland)
>to do this for linux version above.. I can say I was not quite happy
>to do that but don't worry. You can always restore binaries from
>backup.. :^)
>
Not if you just change SHMMAX. That's the max size of a single segment
of shared memory. You don't need to re-link the kernel if that
changes, it will just use it. At least in all the UNIXs I've worked
with, would surprise me if that was the case with Linux?
>
>Only limitation is that the SGA "fragments" while all processes see the
>same address space (at least I figured out that way?), so if you
>increase the limit, it is more likely that there exists a _large_
>enough segment.
Yes. More or less what happens. The more the SGA "fragments" across
segments, the more impact on performance. But we're talking a very
small factor, only relevant in very heavily used systems (although I
once read somewhere that in some versions of Solaris this is a *big*
problem).
Ville Karaila
>On 19 Feb 2001 10:33:55 GMT, kar...@korppi.cs.tut.fi (Ville Karaila)
>wrote:
>>
>>>Which you can do. Get heaps of info on the "recompile the kernel
>>>bit", then do it once you are confident.
>>
>>And actually you have to recompile and link the dbms, so compiling
>>kernel is nothing.. ;) On Oracle 8i (8.1.5) you have to change
>>location of shm area which is allocated in an assembler file, which
>>can be generated by tool included.. This was a common procedure on
>>solaris versions, but I think I was first person (at least in finland)
>>to do this for linux version above.. I can say I was not quite happy
>>to do that but don't worry. You can always restore binaries from
>>backup.. :^)
>>
>Not if you just change SHMMAX. That's the max size of a single segment
>of shared memory. You don't need to re-link the kernel if that
>changes, it will just use it. At least in all the UNIXs I've worked
>with, would surprise me if that was the case with Linux?
Hmm.. I mean re-linking DBMS.. But I think that might be neccessary on
only some systems. It depends on SHM usage. But, on RH 6.0 or 6.2 that was
neccessary while the absolute location of the oracle SHM block is
hard-wired. I don't know why, but that is matter on linux 8.1.5. Maybe later
versions do that less braindead way.. ;)
And if I remember correct, linux (at least 2.0.x ?) must be recompiled
and linked if SHMMAX changes. At least to be on safe side.. :(
>>
>>Only limitation is that the SGA "fragments" while all processes see the
>>same address space (at least I figured out that way?), so if you
>>increase the limit, it is more likely that there exists a _large_
>>enough segment.
>Yes. More or less what happens. The more the SGA "fragments" across
>segments, the more impact on performance. But we're talking a very
>small factor, only relevant in very heavily used systems (although I
>once read somewhere that in some versions of Solaris this is a *big*
>problem).
This is another reason to tune the starting point and size a bit.
While usually size is expected to be 32M, you can safely start oracle
SHM block on 64M and have one nice continuous block of 2Gb easily..
--
VK
Nuno Souto
wrote:
>
>>Not if you just change SHMMAX. That's the max size of a single segment
>>of shared memory. You don't need to re-link the kernel if that
>>changes, it will just use it. At least in all the UNIXs I've worked
>>with, would surprise me if that was the case with Linux?
>
>Hmm.. I mean re-linking DBMS.. But I think that might be neccessary on
>only some systems. It depends on SHM usage. But, on RH 6.0 or 6.2 that was
>neccessary while the absolute location of the oracle SHM block is
>hard-wired. I don't know why, but that is matter on linux 8.1.5. Maybe later
>versions do that less braindead way.. ;)
>
>And if I remember correct, linux (at least 2.0.x ?) must be recompiled
>and linked if SHMMAX changes. At least to be on safe side.. :(
>
Sorry, I didn't explain myself correctly. The situation with other
UNIXes I know of is that you don't need to recompile the (ORACLE)
kernel when you change the SHMMAX. But you still need to
re-compile/re-link the UNIX kernel!
Ville Karaila
Well.. It is not absolutely neccessary on linux either, but if there
is a conflict, recompilation is only solution. :(
--
VK