It would be nice if following setting were default directly in kernel: +++ This bug was initially created as a clone of Bug #1056547 +++ Description of problem: kernel.shmmax and kernel.shmall default values are too low Version-Release number of selected component (if applicable): initscripts-9.49.12-2 How reproducible: always Steps to Reproduce: 1. install rhel 7 2. sysctl -a Actual results: kernel.shmmax = 33554432 kernel.shmall = 2097152 Expected results: kernel.shmmax and kernel.shmall should be set to more appropriate values as they are in rhel6: kernel.shmmax = 68719476736 kernel.shmall = 4294967296 Additional info:
Starting with the 3.16 kernel, the default limits for both of those values are raised to ULONG_MAX - 2^24 in the kernel already. That is the maximum size the upstream kernel developers felt safe with. See commit: commit 060028bac94bf60a65415d1d55a359c3a17d5c31 Author: Manfred Spraul <manfred> Date: Fri Jun 6 14:37:42 2014 -0700 ipc/shm.c: increase the defaults for SHMALL, SHMMAX System V shared memory a) can be abused to trigger out-of-memory conditions and the standard measures against out-of-memory do not work: - it is not possible to use setrlimit to limit the size of shm segments. - segments can exist without association with any processes, thus the oom-killer is unable to free that memory. b) is typically used for shared information - today often multiple GB. (e.g. database shared buffers) The current default is a maximum segment size of 32 MB and a maximum total size of 8 GB. This is often too much for a) and not enough for b), which means that lots of users must change the defaults. This patch increases the default limits (nearly) to the maximum, which is perfect for case b). The defaults are used after boot and as the initial value for each new namespace. Admins/distros that need a protection against a) should reduce the limits and/or enable shm_rmid_forced. Unix has historically required setting these limits for shared memory, and Linux inherited such behavior. The consequence of this is added complexity for users and administrators. One very common example are Database setup/installation documents and scripts, where users must manually calculate the values for these limits. This also requires (some) knowledge of how the underlying memory management works, thus causing, in many occasions, the limits to just be flat out wrong. Disabling these limits sooner could have saved companies a lot of time, headaches and money for support. But it's never too late, simplify users life now. Further notes: - The patch only changes default, overrides behave as before: # sysctl kernel.shmall=33554432 would recreate the previous limit for SHMMAX (for the current namespace). - Disabling sysv shm allocation is possible with: # sysctl kernel.shmall=0 (not a new feature, also per-namespace) - The limits are intentionally set to a value slightly less than ULONG_MAX, to avoid triggering overflows in user space apps. [not unreasonable, see http://marc.info/?l=linux-mm&m=139638334330127] Signed-off-by: Manfred Spraul <manfred> Signed-off-by: Davidlohr Bueso <davidlohr> Reported-by: Davidlohr Bueso <davidlohr> Acked-by: Michael Kerrisk <mtk.manpages> Acked-by: KOSAKI Motohiro <kosaki.motohiro.com> Signed-off-by: Andrew Morton <akpm> Signed-off-by: Linus Torvalds <torvalds> If those values aren't acceptable, then it's up to userspace to change them as suggested in the original bug report.