Edit /etc/sysctl.conf to edit the kernel parameters required for Applications
# 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
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
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
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
You can determine the value of SHMMNI by performing the following:
# cat /proc/sys/kernel/shmmni
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:
The default size of SHMALL is 2097152 and can be queried using the following
# cat /proc/sys/kernel/shmall
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,
bigpages which supports the configuration of larger memory page sizes.
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
# cat /proc/sys/fs/file-max
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
# 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
•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:
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
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
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
The max number of bytes per message (redhat 7.2 default = 8192)
The total size of the queue. (redhat 7.2 default = 16384)
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
Java Web Start provides a browser-independent architecture.. No dependency on Browser make or version for launching forms in EBS. Java a...
Adop phases 1) prepare - Starts a new patching cycle. Usage: adop phase=prepare 2) Apply - Used to apply a patch to the ...
In a multi-node environment, we have seen issues where one of the nodes gets abandoned due to few issues. Main cause is -- One of the ...
Below Pre-upgrade steps on 12.2 servers can be done well in advance before the actual upgrade downtime. Pre-upgrade Steps on 12.2 =========...