Shared Memory Calculator
Calculate System V or POSIX shared memory segment size requirements for applications.
Inputs
Total Shared Memory Needed (MB)
2,048.00
As % of Total RAM
12.50%
Recommended kernel.shmmax (bytes)
536,870,912
Recommended kernel.shmall (pages)
524,288
sysctl Command
sysctl -w kernel.shmmax=536870912 kernel.shmall=524288
Step by step
Values used
Number of Shared Memory Segments = 4; Size per Segment (MB) = 512; System Page Size (KB) = 4; Total System RAM (MB) = 16,384
shmall in pages
shmall_pages = ceil(total_shm_bytes / page_size)
Total Shared Memory Needed (MB)
= 2,048.00
As % of Total RAM
= 12.50
Recommended kernel.shmmax (bytes)
= 536,870,912
Recommended kernel.shmall (pages)
= 524,288
sysctl Command
= sysctl -w kernel.shmmax=536870912 kernel.shmall=524288
How it works
System V shared memory (used heavily by databases like PostgreSQL for shared_buffers) is bounded by two kernel limits: kernel.shmmax (the largest single segment allowed, in bytes) and kernel.shmall (the total shared memory system-wide, in pages). Applications that request a segment larger than shmmax, or a total exceeding shmall, fail to allocate shared memory at startup — a common cause of database startup failures after increasing configured buffer sizes without also raising these kernel limits.
Formula
shmall in pages
shmall_pages = ceil(total_shm_bytes / page_size)
- B
- total shared memory requested
- p
- system page size
Frequently Asked Questions
Why did PostgreSQL fail to start after I increased shared_buffers?
The most common cause is the requested segment exceeding kernel.shmmax, or the cumulative shared memory exceeding kernel.shmall — both must be raised via sysctl (and typically /etc/sysctl.conf for persistence) before increasing an application's shared memory configuration beyond the current limits.
What's the difference between System V shared memory and POSIX shared memory?
System V shm (shmget/shmat) is the older API governed by kernel.shmmax/shmall/shmmni; POSIX shared memory (shm_open, typically backed by tmpfs under /dev/shm) is governed instead by the size of the /dev/shm mount. Modern applications increasingly prefer POSIX shm, but many established databases still use System V shm.
How do I check current System V shared memory usage?
`ipcs -m` lists active shared memory segments with their sizes and attaching processes, and `ipcs -lm` shows the current kernel limits (shmmax, shmall, shmmni) for comparison against what your applications need.