Example: A shared memory configuration that is logically overcommitted

When the sum of the physical memory currently used by the shared memory partitions is less than or equal to the amount of memory in the shared memory pool, the memory configuration is logically overcommitted. In a logically overcommitted memory configuration, the shared memory pool has enough physical memory to contain the memory used by all shared memory partitions at one point in time.

The following figure shows a server with shared memory configuration that is logically overcommitted.

Figure 1. A server with a shared memory configuration that is logically overcommitted

The figure shows a shared memory pool of 16.25 GB that is shared among three shared memory partitions. The hypervisor uses a small portion (0.25 GB) of the shared memory pool to manage the shared memory resources. The figure also shows one paging VIOS partition that owns all of the physical storage in the system. The physical storage contains a paging space device for each shared memory partition. The paging VIOS partition does not use the memory in the shared memory pool, but rather receives dedicated memory of 1 GB. Of the remaining system memory, 1 GB is reserved for the hypervisor so that it can manage other system resources, and 13.75 GB is free memory that is available for system growth. For example, you can dynamically add more memory to the shared memory pool or you can create additional dedicated memory partitions.

Shared memory partition 1 is assigned 12 GB of logical memory, Shared memory partition 2 is assigned 8 GB of logical memory, and Shared memory partition 3 is assigned 4 GB of logical memory. Together, the shared memory partitions are assigned 24 GB of logical memory, which is more than the 16.25 GB allocated to the shared memory pool. Therefore, the memory configuration is overcommitted.

Shared memory partition 1 currently uses 8 GB of physical memory, Shared memory partition 2 currently uses 4 GB of physical memory, and Shared memory partition 3 currently uses 4 GB of physical memory. Together, the shared memory partitions currently use 16 GB of physical memory, which is equal to the amount of physical memory available to them in the shared memory pool. Therefore, the memory configuration is logically overcommitted. In other words, the shared memory pool contains enough physical memory for the hypervisor to allocate unused memory pages to shared memory partitions that need them. All of the memory currently used by the shared memory partitions resides in the shared memory pool.