Linux - Kernel Semaphore parameters

Source

1 - About

On Linux, A semaphore is a System V IPC object that is used to control utilization of a particular process.
Semaphores are a shareable resource that take on a non-negative integer value. They are manipulated by the P (wait) and V (signal) functions, which decrement and increment the semaphore, respectively. When a process needs a resource, a “wait” is issued and the semaphore is decremented. When the semaphore contains a value of zero, the resources are not available and the calling process spins or blocks (as appropriate) until resources are available. When a process releases a resource controlled by a semaphore, it increments the semaphore and the waiting processes are notified.
The Semaphore Kernel parameters

Semaphore	Description	Minimum
SEMMSL	maximum number of semaphores per array	128
SEMMNS	maximum semaphores system-wide
SEMOPM	maximum operations per semop call
SEMMNI	maximum arrays

2 - Articles Related

• Linux - Kernel Parameter Management (sysctl.conf)
• Timesten - Database Installation and configuration on Linux
• Linux - Directory /proc/sys/kernel/
• Linux - System V Shared Memory IPC
• Oracle Database - Installation 11g Release 2 (11.2) on Linux OEL 5 (X86)
• Oracle Database 11gR2 - Installation on Linux OEL 5 Update 5 (x86_64)
• Exalytics - Timesten Configuration
• Linux - IPCS command

Advertising

3 - How to

3.1 - Display them ?

This command displays the value of the semaphore parameters:

# /sbin/sysctl -a | grep sem

3.2 - Calculate them ?

• Calculate the minimum total semaphore requirements using the following formula:

sum (process parameters of all database instances on the system) + system and other application requirements

• Set semmns (total semaphores systemwide) to this total.
• Set semmsl (semaphores per set) to 256.
• Set semmni (total semaphores sets) to semmns / semmsl rounded up to the nearest multiple of 1024.

The following formula can be used as a guide, although in practice, SEMMNS and SEMMNU can be much less than SEMMNI * SEMMSL because not every program in the system needs semaphores.

3.3 - Set them ?

In the file, /etc/sysctl.conf

kernel.sem = 2200 6400 200 25

Where:

kernel.sem = SEMMSL SEMMNS SEMOPM SEMMNI

Then reboot or run this command:

# /sbin/sysctl -p

Advertising

4 - Documentation / Reference

• Semaphore (programming)
• Semaphore

Overriding the default Linux kernel 20-second TCP socket connect timeout

Source, thanks to author.

Whatever language or client library you're using, you should be able to set the timeout on network socket operations, typically split into a connect timeout, read timeout, and write timeout.
However, although you should be able to make these timeouts as small as you want, the connect timeout in particular has an effective maximum value for any given kernel. Beyond this point, higher timeout values you might request will have no effect - connecting will still time out after a shorter time.
The reason TCP connects are special is that the establishment of a TCP connection has a special sequence of packets starting with a SYN packet. If no response is received to this initial SYN packet, the kernel needs to retry, which it may have to do a couple of times. All kernels I know of wait an increasing amount of time between sending SYN retries, to avoid flooding slow hosts.
All kernels put an upper limit on the number of times they will retry SYNs. On BSD-derived kernels, including Mac OS X, the standard pattern is that the second SYN will be second 6 seconds after the first, then a third SYN 18 seconds after that, then the connect times out after a total of around 75 seconds.
On Linux however, the default retry cycle ends after just 20 seconds. Linux does send SYN retries somewhat faster than BSD-derived kernels - Linux supposedly sends 5 SYNs in this 20 seconds, but this includes the original packet (the retries are after 3s, 6s, 12s, 24s).
The end result though is that if your application wants a connect timeout shorter than 20s, no problem, but if your application wants a connect timeout longer than 20s, you'll find that the default kernel configuration will effectively chop it back to 20s.
Changing this upper timeout limit is easy, though it requires you to change a system configuration parameter and so you will need to have root access to the box (or get the system administrators to agree to change it for you).
The relevant sysctl is tcp_syn_retries, which for IP v4 is net.ipv4.tcp_syn_retries.
Be conservative in choosing the value you change it to. Like BSD, the SYN retry delays increase in time (albeit doubling rather than tripling), so a relatively small increase in the number of retries leads to a large increase in the maximum connect timeout. In a perfect world, there would be no problem with having a very high timeout because applications' connect timeouts will come into play.
However, many applications do not set an explicit connect timeout, and so if you set the kernel to 10 minutes, you're probably going to find something hanging for ages sooner or later when a remote host goes down!
I recommend that you set it to a value of 6, 7, or at most 8. 6 gives an effective connect timeout ceiling of around 45 seconds, 7 gives around 90 seconds, and 8 gives around 190 seconds.
To change this in a running kernel, you can use the /proc interface:

# cat /proc/sys/net/ipv4/tcp_syn_retries 
5
# echo 6 > /proc/sys/net/ipv4/tcp_syn_retries 

Or use the sysctl command:

# sysctl net.ipv4.tcp_syn_retries
net.ipv4.tcp_syn_retries = 5
# sysctl -w net.ipv4.tcp_syn_retries=6
net.ipv4.tcp_syn_retries = 6

To make this value stick across reboots however you need to add it to /etc/sysctl.conf:

net.ipv4.tcp_syn_retries = 6

Most Linux installations support reading sysctls from files in /etc/sysctl.d, which is usually better practice as it makes it easier to administer upgrades, so I suggest you put it in a file there instead.
(I see no reason you'd want to reduce this sysctl, but note that values of 4 or less all seem to be treated as 4 - total timeout 9s.)