SHMMAX + how effected kernel parameter that not set correctly by mistake

Question

few words about shared memory

Shared memory allows processes to access common structures and data by placing them in shared memory segments. It is the fastest form of inter-process communication available since no kernel involvement occurs when data is passed between the processes. In fact, data does not need to be copied between the processes.

we notice that value in redhat machines is huge as the following

 cat /proc/sys/kernel/shmmax
 17446744003692774391

 sysctl -a | grep kernel.shmmax
 kernel.shmmax = 17446744003692774391

when I calculated to Giga its - 16248546544.17632

is it logical? , do we miss something here

machines are with 64G and 16 CPU and are use in hadoop cluster

Answer 1

The default value for shmmax is

#define SHMMAX (ULONG_MAX - (1UL << 24))

This is an upper bound, chosen to be as large as possible while limiting the risk of overflow:

SHMMNI, SHMMAX and SHMALL are default upper limits which can be modified by sysctl. The SHMMAX and SHMALL values have been chosen to be as large possible without facilitating scenarios where userspace causes overflows when adjusting the limits via operations of the form "retrieve current limit; add X; update limit". It is therefore not advised to make SHMMAX and SHMALL any larger. These limits are suitable for both 32 and 64-bit systems.

The value is fine as-is; it is set correctly, there is no mistake.