Kernel parameters problem (512 mb RAM)

Question

Hi,
I've installed Oracle on RedHat 5.2 (2.0.36) on a machine with
512 mb memory.
First I've recompiled the kernel how Oracle says and basing in
some documents (like
http://jordan.fortwayne.com/oracle/oralinux.html). Of course I've
saved a copy of the old kernel. The linux was ok, the command
ipcs -l shows the new values of the kernel parameters, but Oracle
didn't start. I've restored the copy of the kernel, the ipcs -l
shows the old values and now Oracle is running, with a SGA of
almost 300 mb.
Is there some problem in that? Will the machine loose performance
because the miminum values of the kernel parameters?
Best regards,
Ari
null

Answer 1

Ari Arantes (guest) wrote:
: Hi,
: I've installed Oracle on RedHat 5.2 (2.0.36) on a machine with
: 512 mb memory.
: First I've recompiled the kernel how Oracle says and basing in
: some documents (like
: http://jordan.fortwayne.com/oracle/oralinux.html). Of course
I've
: saved a copy of the old kernel. The linux was ok, the command
: ipcs -l shows the new values of the kernel parameters, but
Oracle
: didn't start. I've restored the copy of the kernel, the ipcs -
l
: shows the old values and now Oracle is running, with a SGA of
: almost 300 mb.
: Is there some problem in that? Will the machine loose
performance
: because the miminum values of the kernel parameters?
: Best regards,
: Ari
I have a setup similar to yours (384 MB instead of 512 MB),
and I spent some time looking at the parameters.
You CANNOT use the value for SHMMAX from the Oracle manual!
As it says at http://jordan.fortwayne.com/oracle/oralinux.html
"Should you decided to change these parameters, if you set
the SHMMAX to what Oracle says, you are telling the system
to allow a shared memory segment to grow as large as 4 Gigs.
Many users have reported problems setting the value this
high."
Sounds like you are another one of those users, eh?
If you read on down, the guy who wrote that web page never
used over 128 MB for SHMMAX. I'd take a strong hint from that.
=====
Oracle wants you to use 4GB-1 as the SHMMAX value. That
equates to (1<<32)-1. As we shall see, that is not allowed
without "breaking the rules" for the i386 architecture.
If you carefully read through the header file, you will find
out that the **actual maximum value** for SHMMAX is 256 MB.
You can tell this two ways. Take a look at the file at:
/usr/src/linux/include/asm/shmparam.h
Near the top of the file is:
/* address range for shared memory attaches if
no address passed to shmat() */
#define SHM_RANGE_START 0x50000000
#define SHM_RANGE_END 0x60000000
Note that the above is 256 MB (0x10000000), or (1<<28). This
is one potential source of trouble. I don't know if some other
files someplace else in the kernel specify uses for address
ranges adjacent to the above range, which I take to be the
"practical maximum" without redefining that range. Personally,
I wouldn't want to mess with the above unless I **really**
knew what I was doing (and I'll be the first to admit I don't).
=====
Farther down you will see some more lines (not together)
that look like this:
#define SHMID_BITS 7
#define SHMIDX_BITS 15
* SHMID_BITS + SHMIDX_BITS must be <= 24 on the i386 and
* SHMMAX <= (PAGE_SIZE << SHMIDX_BITS).
#define SHMMAX 0x2000000 /* max shared seg
size (bytes) */
Now, 7 + 15 is 22, so you could go up a couple of bits if you
had to. To avoid making the table any larger, I would suggest:
#define SHMIDX_BITS 17
But, 17 turns out to produce a result larger than the "practical
maximum" (256 MB) above. To see why takes a little more
explaining.
And if you don't change this at all, then the maximum possible
value for SHMMAX is 4096 [the PAGE_SIZE) << 15 [_SHM_IDX_BITS],
or rather (1<<27).
Now, that is exactly half of the (1<<28) "practical maximum" I
mentioned above.
So, if you always want the maximum amount of shared memory,
then change the definition of SHMMAX to the following:
#define SHMMAX (PAGE_SIZE<<_SHM_IDX_BITS) /* max shared seg
size (bytes) */
That gives you 128 MB in and of itself (as compared with 32 MB
as Red Hat 5.2 is delivered).
If you want the full 256 MB that is allowed for in the memory
map, then you need to also change:
#define SHMIDX_BITS 16
The above value is **exactly** what is recommended on the web
page you were following (above).
If you want to keep going up, you will need to change the
memory space allocated for shared memory as defined by
SHM_RANGE_START and SHM_RANGE_END, something I advise against.
=====
Even on a machine with 512 MB of "real" memory, I find it hard
to believe that there would be any substantial benefit to
having a maximum shared memory space greater than 256 MB. The
reason is that Oracle can use multiple shared memory spaces.
It requires a minimum of ten (10), according to the installation
manual, but the Red Hat 5.2 distribution supplies SHMMNI (128)
of them. That will allow each Oracle process to have a total
of up to 32 GB of shared memory (128 times 256 MB) and all it
asks for is 40 GB (10 times 4 GB), so it has plenty, IMHO.
=====
Let me say a few more words about the web page you were using
for configuration advice. That person actually **reduced** the
amount of shared memory segments by specifying **lower values**
for SHMMNI and SHMSEG (not to mention the semaphores).
I'd **STRONGLY** recommend **NOT CHANGING** those other values!
Its my understanding that Oracle can make up for the smaller
maximum shared memory segment size by using more shared memory
segments. So, if you reduce those, you are essentially shooting
yourself in the foot by taking away what you are giving with
increasing the maximum segment size.
=====
Good luck, and may this farce be with you!
null