Chapter 17. Using Very Large Memory (VLM)

This chapter does not apply to x86-64 (64 bit) systems.

With hugemem kernels on 32 bit systems, the SGA size can be increased but not significantly as shown at Section 16.3, “Oracle 10g SGA Sizes in Red Hat Enterprise Linux 3, 4 or 5”. Note the hugemem kernel is always recommended on systems with large amounts of RAM, see Section 2.2, “32 bit Architecture and the hugemem Kernel”. This chapter shows how the SGA can be significantly increased using VLM on 32 bit systems.

Starting with Oracle9i Release 2 the SGA can theoretically be increased to about 62 GB (depending on block size) on a 32 bit system with 64 GB RAM. A processor feature called Page Address Extension (PAE) provides the capability of physically addressing 64 GB of RAM. However, it does not enable a process or program to address more than 4GB directly or have a virtual address space larger than 4GB. Hence, a process cannot attach to shared memory directly if it has a size of 4GB or more. To address this issue, a shared memory file system (memory-based file system) can be created which can be as large as the maximum allowable virtual memory supported by the kernel. With a shared memory file system processes can dynamically attach to regions of the file system allowing applications like Oracle to have virtually a much larger shared memory on 32 bit systems. This is not an issue on 64 bit systems.

For Oracle to use a shared memory file system, a feature called Very Large Memory (VLM) must be enabled. VLM moves the database buffer cache part of the SGA from the System V shared memory to the shared memory file system. It is still considered one large SGA but it consists now of two different OS shared memory entities. It is noteworthy to say that VLM uses 512MB of the non-buffer cache SGA to manage VLM. This memory area is needed for mapping the indirect data buffers (shared memory file system buffers) into the process address space since a process cannot attach to more than 4GB directly on a 32 bit system. For example, if the non-buffer cache SGA is 2.5 GB, then you will only have 2 GB of non-buffer cache SGA for shared pool, large pool, and redo log buffer since 512MB is used for managing VLM. If the buffer cache is less than 512 MB, then the init.ora parameter VLM_WINDOW_SIZE must be changed to reflect the size of the database buffer cache. However, it is not recommended to use VLM if db_block_buffers is not greater than 512MB.

In Red Hat Enterprise Linux 3, 4 and 5 there are two different memory file systems that can be used for VLM:

Note that the shmfs file system is available in Red Hat Enterprise Linux 3 but not in Red Hat Enterprise Linux 4 or 5:

$ cat /etc/redhat-release
Red Hat Enterprise Linux AS release 3 (Taroon Update 6) 
$ egrep "shm|tmpfs|ramfs" /proc/filesystems
nodev   tmpfs 
nodev   shm 
nodev   ramfs 
$

$ cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 2)
$ egrep "shm|tmpfs|ramfs" /proc/filesystems
nodev   tmpfs
nodev   ramfs
$

This means that if you try to mount a shmfs file system in Red Hat Enterprise Linux 4 or 5, you will get the following error message:

mount: fs type shm not supported by kernel

The difference between shmfs and tmpfs is you do not need to specify the size of the file system if you mount a tmpfs file system.