Wednesday, August 26, 2009

What about Kernel Parameters?

Edit /etc/sysctl.conf to edit the kernel parameters required for Applications


vi /etc/sysctl.conf

# semaphores in kernel.sem: semmsl semmns semopm semmni

kernel.sem = 256 32000 100 142

kernel.shmmax = 2288490188

kernel.shmmni = 4096

kernel.shmall = 3279547

fs.file-max = 327679

net.ipv4.ip_local_port_range = 1024 65000

kernel.msgmax = 8192

kernel.msgmni = 2878

kernel.msgmnb = 65535

net.core.rmem_default = 262144

net.core.rmem_max = 262144

net.core.wmem_default = 262144

net.core.wmem_max = 262144

SHMMAX


The SHMMAX parameter is used to define the maximum size (in bytes) for a

shared memory segment and should be set large enough for the largest SGA size.

If the SHMMAX is set incorrectly (too low), it is possible that the Oracle SGA

(which is held in shared segments) may be limited in size. An inadequate

SHMMAX setting would result in the following:

ORA-27123: unable to attach to shared memory segment

You can determine the value of SHMMAX by performing the following:

# cat /proc/sys/kernel/shmmax

33554432

As you can see from the output above, the default value for SHMMAX is 32MB.

This is often too small to configure the Oracle SGA. I generally set the SHMMAX

parameter to 2GB.

NOTE: With a 32-bit Linux operating system, the default maximum size of the SGA is 1.7GB.

This is the reason I often set the SHMMAX parameter to 2GB since it requires a larger value for SHMMAX.


On a 32-bit Linux operating system, without Physical Address Extension (PAE), the physical

memory is divided into a 3GB user space and a 1GB kernel space. It is therefore possible to

create a 2.7GB SGA, but you will need make several changes at the Linux operating system

level by changing the mapped base. In the case of a 2.7GB SGA, you would want to set the

SHMMAX parameter to 3GB.

This is method I use most often.

This method sets the SHMMAX on startup by inserting the

following kernel parameter in the /etc/sysctl.conf startup file:

# echo "kernel.shmmax=2147483648" >> /etc/sysctl.conf

•If you wanted to dynamically alter the value of SHMMAX without rebooting the machine, you

can make this change directly to the /proc file system. This command can be made

permanent by putting it into the /etc/rc.local startup file:


# echo "2147483648" > /proc/sys/kernel/shmmax

•You can also use the sysctl command to change the value of SHMMAX:

# sysctl -w kernel.shmmax=2147483648

SHMMNI

We now look at the SHMMNI parameters. This kernel parameter is used to set the

maximum number of shared memory segments system wide. The default value for

this parameter is 4096. This value is sufficient and typically does not need to be

changed.

You can determine the value of SHMMNI by performing the following:

# cat /proc/sys/kernel/shmmni

4096

SHMALL

Finally, we look at the SHMALL shared memory kernel parameter. This parameter

controls the total amount of shared memory (in pages) that can be used at one

time on the system. In short, the value of this parameter should always be at least:

ceil(SHMMAX/PAGE_SIZE)

The default size of SHMALL is 2097152 and can be queried using the following

command:


# cat /proc/sys/kernel/shmall

2097152

From the above output, the total amount of shared memory (in bytes) that can be

used at one time on the system is:

SM = (SHMALL * PAGE_SIZE)

= 2097152 * 4096

= 8,589,934,592 bytes

The default setting for SHMALL should be adequate for our Oracle installation.

NOTE: The page size in Red Hat Linux on the i386 platform is 4096 bytes. You can, however,

use

bigpages which supports the configuration of larger memory page sizes.

fs.file-max

------------------

When configuring our Linux database server, it is critical to ensure that the maximum number

of file handles is large enough. The setting for file handles designate the number of open files

that you can have on the entire Linux system.

Use the following command to determine the maximum number of file handles for the entire

system:

# cat /proc/sys/fs/file-max

103062

Oracle recommends that the file handles for the entire system be set to at least 65536. In

most cases, the default for Red Hat Linux is 103062

This is method I use most often. This method sets the maximum number of file handles

(using the kernel parameter file-max) on startup by inserting the following kernel parameter in

the /etc/sysctl.conf startup file:

# echo "fs.file-max=65536" >> /etc/sysctl.conf

•If you wanted to dynamically alter the value of all semaphore kernel parameters without

rebooting the machine, you can make this change directly to the /proc file system. This

command can be made permanent by putting it into the /etc/rc.local startup file:

# echo "65536" > /proc/sys/fs/file-max

NOTE: It is also possible to query the current usage of file handles using the following

command:

# cat /proc/sys/fs/file-nr

1140 0 103062

In the above example output, here is an explanation of the three values from the file-nr

command:

•Total number of allocated file handles.

•Total number of file handles currently being used.

•Maximum number of file handles that can be allocated. This is essentially the value of filemax

- (see above).

NOTE: If you need to increase the value in /proc/sys/fs/file-max, then make sure that the

ulimit is set properly. Usually for 2.4.20 it is set to unlimited. Verify the ulimit setting my

issuing the ulimit command:

# ulimit

unlimited

net.ipv4.ip_local_port_range

--------------------------------------

The /proc/sys/net/ipv4/ip_local_port_range defines the local port range that is used by TCP

and UDP traffic to choose the local port. You will see in the parameters of this file two

numbers: The first number is the first local port allowed for TCP and UDP traffic on the server,

the second is the last local port number. For high-usage systems you may change its default

parameters to 32768-61000 -first-last.

The default setup for the ip_local_port_range parameters under Red Hat Linux is: "1024

4999"

To change the values of ip_local_port_range, type the following command on your terminal:

[root@deep] /# echo "32768 61000" >/proc/sys/net/ipv4/ip_local_port_range

You must restart your network for the change to take effect.

[root@deep] /# /etc/rc.d/init.d/network restart

kernel.msgmni

--------------------

msg queues I use message queue's to pass messages around. I use the same queue to

send and receive messages. This is actually very bad (now that I think about it), cause you

might fill up the queue, and cause a deadlock (hmm, that appears to be happening!). anyway

to increase the sizes put bigger sizes into

/proc/sys/kernel/msgmax

The max number of bytes per message (redhat 7.2 default = 8192)

/proc/sys/kernel/msgmnb

The total size of the queue. (redhat 7.2 default = 16384)

/proc/sys/kernel/msgmni

Number of messages. (redhat 7.2 default = 16)

Basically these low numbers make message queues pretty useless in a high traffic

application. Probably you can just up these numbers to be pretty large

msgmax: ( default 2048 )

The parameter "msgmax" is the maximum number of bytes that can be in

any one message. msgsnd() will give the error EINVAL if a message is

longer than this.

msgmnb: ( default 4096 )

The parameter "msgmnb" is the maximum number of message bytes that

can be on any one queue at a given time. If a message would cause a

queue to grow larger than this, that msgsnd() would either block

until space was available, or would give the error EAGAIN if user

specified non-blocking mode. For obvious reasons "msgmnb" must be at

least as large as "msgmax", however, it is probably good to set it to

some integral number of "msgmax." This way, a few messages of the

maximum size could be queued at any time. However, making "msgmnb"

too large compared to the total bytes available for messages (see

below) may allow one queue to hog the message system.

msgmni: ( default 50 )

The parameter "msgmni" is the number of message queue ids available

to the system. Each message queue requires one id. msgget() gives

the error ENOSPC if all the ids have been used up.

Contributed by:Vinay, Kalyan and Varun

1 comment: