Memory and 11gr2 and Linux

For large SGA sizes, HugePages can give substantial benefits in virtual memory management. Without HugePages, the memory of the SGA is divided into 4K pages, which have to be managed by the Linux kernel.

Using HugePages, the page size can be increased to any value between 2MB and 256MB, thereby reducing the total number of pages to be managed by the kernel and therefore reducing the amount of memory required to hold the page table in memory.

In addition to these changes, the memory associated with HugePages does not get swapped out, which forces the SGA to stay resident. The savings in memory and resources of page management make HugePages a great addition for Oracle 11g systems running on x86-64 architectures.

Note. Automatic Memory Management (AMM) is not compatible with HugePages, so apart from ASM instances and small unimportant databases, you will probably have no need for AMM on a real system. Instead, Automatic Shared Memory Management and Automatic PGA Management should be used as they are compatible with HugePages.

This command can show the current HugePage usage. The default HugePage size is 2MB on Oracle Linux 5.x and as you can see from the output below, by default no HugePages are defined.

grep HugePages /proc/meminfo

Oracle and hugepages

Failure to properly configure amount of hugepages on your Linux box and your instance may silently revert to 4k memory pages resulting in excessive paging/swapping.

Since there is a parameter use_large_pages that controls hugepages allocation behavior. This parameter is not hidden, however there is nothing in public documentation but some notes on metalink (USE_LARGE_PAGES To Enable HugePages In 11.2 [ID 1392497.1]) and blog posts from Oracle guys.

This parameter can have three distinct values and defaults to use_large_pages=true.

In default value preserves old behavior – if there are less hugepages then total allocated SGA – Oracle will write a warning message to alert.log and will go on with normal pages.

With  use_large_pages=only Oracle will check during the startup if there’s enough preallocated large pages and if there isn’t – will not proceed starting up  with a message like

Specified value of sga_max_size is too small, bumping to 94220845056 ****************** Large Pages Information ***************** Parameter use_large_pages = ONLY Large Pages unused system wide = 43000 (84 GB) (alloc incr 256 MB)

Large Pages configured system wide = 43000 (84 GB)

Large Page size = 2048 KB ERROR:  Failed to allocate shared global region with large pages, unix errno = 12. Aborting Instance startup.

ORA-27137: unable to allocate Large Pages to create a shared memory segment ACTION:  Total Shared Global Region size is 88 GB. Increase the number of  unused large pages to atleast 44932 (88 GB) to allocate 100% Shared Global  Region with Large Pages. ***********************************************************

With use_large_pages=false Oracle obviously will not use any of the large pages even if there are enough of them.

In the default behavior has changed – now with use_large_pages=true and less then SGA hugepages Oracle will allocate part of the SGA with them and the resting part with normal 4k pages. In alert.log it will look like

Specified value of sga_max_size is too small, bumping to 94220845056 ****************** Large Pages Information ***************** Total Shared Global Region in Large Pages = 84 GB (95%) Large Pages used by this instance: 42881 (84 GB) Large Pages unused system wide = 119 (238 MB) (alloc incr 256 MB) Large Pages configured system wide = 43000 (84 GB) Large Page size = 2048 KB

RECOMMENDATION:  Total Shared Global Region size is 88 GB. For optimal performance,  prior to the next instance restart increase the number  of unused Large Pages by atleast 1929 2048 KB Large Pages (3858 MB)  system wide to get 100% of the Shared  Global Region allocated with Large pages ***********************************************************

So there is one trap less, but I hope Oracle will be certified for RHEL6 very soon, so we’ll have a transparent hugepages feature that will make this nice new parameter obsolete ).

Leave a Reply

Your email address will not be published. Required fields are marked *