Database Reference
In-Depth Information
Memory Starvation
Memory starvation in a cluster node can cause stability issues in a RAC cluster. Elevated process priority protects
the background process from CPU starvation but does not prevent memory starvation issues. Memory starvation of
an LMS process can lead to higher latency for global cache wait events in other nodes. Further, memory starvation
of Grid Infrastructure daemons can lead to node reboots. It is a recommended practice to design cluster nodes with
sufficient memory and avoid memory starvation.
Virtual memory swappiness is an important attribute to consider in a Linux kernel. This kernel parameter affects
swapping behavior. As Linux kernel version 2.6.18 improves swapping daemons throughput, you should upgrade the
kernel to at least version 2.6.18. If you cannot upgrade the kernel to at least 2.6.18, then the vm.swappiness kernel
parameter is an important parameter to consider. If the parameter is set to a lower value, then pages will be kept in
memory as long as possible. If the vm.swappiness parameter is set to a higher value, then the pages will be swapped
more aggressively. If you are using a version prior to 2.6.18 kernels, you should reduce the vm.swappiness kernel
parameter to a lower value such as 30 (default is 60).
We also recommend that you implement HugePages in the Linux platform. At the time of this writing, Oracle
has made HugePages as one of the important ways to improve the stability of a RAC cluster. With HugePages, two
important benefits can be achieved:
•
SGA is locked in memory. Linux kernel daemons have fewer pages to scan during memory
starvation. Locking SGA also protects from paging.
•
Further, default page size of memory mapping is 4KB in the Linux platform. Pointers to these
pages must be maintained in page table entries, and so page table entries can easily grow to a
few gigabytes of memory. With the HugePages feature, page size is increased to 2MB and the
page table size is reduced to a smaller size.
HugePages and Automatic memory management (AMM) do not work together. We recommend you use
HugePages instead of AMM to improve RAC stability.
SGA size
If the data blocks are already residing in local SGA, then access to those buffers is in the range of microseconds.
Thus, it is important to keep SGA size bigger in a database with OLTP workload. It is a best practice to increase the
SGA size when you convert the database to RAC.
If the application workload is mostly Decision Support System (DSS) or Data Warehouse type, then keep PGA
bigger and buffer cache smaller, as PX server processes read blocks directly into the PGA (Program Global Area).
The parameter pga_aggregate_target is
not
a hard limit and the sum of PGA allocated by the database processes
can far exceed the pga_aggregate_target parameter. This unintended excessive memory usage can induce memory
starvation in the server and lead to performance issues. Release 12c introduces pga_aggregate_limit parameter and
the total PGA used by the database cannot exceed the pga_aggregate_limit value. If the database have allocated
pga_aggregate_limit amount of PGA, then the process with largest PGA allocation is stopped until the PGA size falls
below the pga_aggregate_limit value. Therefore, in 12c, you can avoid excessive memory swapping issues by setting
pga_aggregate_limit to an optimal value.
It is advisable to keep the SGA size as big as possible without inducing memory starvation, as discussed earlier.
Database nodes with ample physical memory are essential while converting a database to a RAC database. More
memory can also reduce unnecessary CPU usage, which can be beneficial from a licensing point of view.
Filesystem Caching
For Oracle database software and Grid Infrastructure software, the file system must have caching enabled. Without
file system caching, every access to binary file pages (software binary pages are accessed frequently from an executing
UNIX process) will lead to a disk access. This excessive disk reads induces latency in the executable, leading to
instance reboot or even node reboot.
