First off, those enormous values you're seeing for shared memory limits aren't an error—they're totally normal for 64-bit Linux systems like Oracle Linux 7.6. Let me break down why they're so big and what they mean for your Oracle 11g installation:

Why the numbers are so large #

On 64-bit architectures, the kernel parameters controlling shared memory (SHMMAX and SHMALL) are often set to the theoretical maximum possible values allowed by the 64-bit address space, rather than matching your physical RAM (8GB in your case). This is intentional because:

• The OS will only allocate shared memory up to the amount of physical RAM available (plus swap, if configured). Setting these limits high removes artificial barriers without wasting memory.
• Oracle 11g on 64-bit systems benefits from having these upper bounds set to the maximum, as it allows flexibility in configuring the System Global Area (SGA) without hitting kernel-level limits.

What each parameter means #

Let's map the ipcs -l output to the underlying kernel parameters:

• max seg size (kbytes): This corresponds to kernel.shmmax, which defines the largest single shared memory segment the OS will allow. The value you see (18014398509465599) is roughly 2^64 / 1024—this is the maximum possible size for a single segment on a 64-bit system.
• max total shared memory (kbytes): This comes from kernel.shmall, which is the total number of shared memory pages available system-wide. When converted to kilobytes (using your system's page size), it gives that massive number. Again, this is the theoretical maximum total shared memory the OS can address.

What this means for your 8GB system #

You don't need to adjust these parameters for your Oracle 11g installation. As long as you configure your Oracle SGA to a reasonable size (typically 4-6GB, leaving enough RAM for the OS and other processes), the kernel will happily allocate the required shared memory without issue. The huge limits just mean you won't hit a wall if you need to increase the SGA later (as long as you have the physical RAM to support it).

If you want to verify the underlying kernel parameters, you can run this command:

sysctl -a | grep shm

Your ipcs -l output for reference #

[chy@myserver ~]$ ipcs -l
------ Messages Limits --------
max queues system wide = 32000
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 18014398509465599
max total shared memory (kbytes) = 18014398442373116
min seg size (bytes) = 1
------ Semaphore Limits --------
max number of arrays = 32000
max semaphores per array = 32000
max semaphores system wide = 1024000000
max ops per semop call = 500
semaphore max value = 32767

内容的提问来源于stack exchange，提问作者chy