1. Hugepage Basic Concepts
A system process accesses memory through a virtual address, but the CPU must convert it to a physical memory address to actually access the memory.
To improve the efficiency of this conversion, the CPU caches the closest "virtual memory address and physical memory address" mappings and saves the
A Mapping Table (page table) maintained by the CPU.
Page table is a data structure model of the virtual memory system on the operating system that stores virtual addresses and physically
The corresponding relationship of the address. When we access the memory, we first Access "page table", then Linux again through the "page table" of the mapping
To access real physical memory (RAM or swap).
Under 32-bit systems, a process that accesses 1GB of memory will produce a 1M page table, and if it is on a 64-bit system, it will grow to 2M.
It is easy to calculate if an SGA is set to 60G, there are 1500 Oracle user processes, 64-bit Linux on the system, the largest page table
Memory consumption: 60*2*1500/1024=175g.
To maximize the speed of memory access, you need to save as many mappings as possible in the mapping table. And in Redhat Linux,
Memory is divided into pages (page), by default each page is 4K Bytes, which means that if the physical memory is large,
such as 64G, the mapping table entries will be very much, which will affect the efficiency of the CPU retrieval (the CPU needs to convert the virtual address to a physical address).
And based on the projections above, the page table consumes more memory than the physical memory.
Due to the memory size is fixed, in order to reduce the mapping table entries, you can only increase the size of the page. This increase in the internal
The size of the save page is in Linux 2.1, called the Big page; in the as 3/4 or later version, it is called Hugepage. If the system has a large number
Physical memory (greater than 8G), the hugepage should be used regardless of the 32-bit operating system or 64-bit.
2. Hugepage Basic Information view
In Linux, you can view Hugepage-related values by using the following command:
$ cat/proc/meminfo | grep Huge
hugepages_total:0
hugepages_free:0
hugepages_rsvd:0
hugepagesize:2048 KB
Typically, the Linux hugepage size is 2MB (different processor architectures may not be the same)
Number of pages in Hugepages_total:hugepage
Hugepages_free: Number of pages remaining
HUGEPAGES_RSVD: The number of page numbers that are reserved but not yet used
Hugepagesize: size per unit quantity
Note: Using Hugepage memory is shared memory, it will always pin in memory and will not be swapped out, which means using
Hugepage memory can not be used by other processes, so be sure to set this value reasonably, to avoid wasting. For use only
For Oracle servers, set the Hugepage_pool to a bit larger than the SGA size. The PGA is not shared memory and is used
Less than the hugepage.
HUGEPAGES_FREE-HUGEPAGES_RSVD part of the memory is wasteful and cannot be used by other programs. In practical applications,
Try to make hugepages_free-hugepages_rsvd=0
The amount of huge page,free memory that is set will be used. For example: Setting Sysctl vm.nr_hugepages=1024
After that, the free command can see that the memory of "2048MB" (1024*2m) is reduced. (This is also related to the size of the hugepagesize)
3. Benefits of Hugepage:
A. Improves the TLB hit ratio by significantly increasing the memory size that is covered by the page table that is stored in the CPU cache.
B. A subset of the TLB (translation lookaside Buffer) in the CPU cache is used to hold part of the page table to improve virtual memory
Address to the speed of the physical memory address translation. Because the page size is getting larger, the same size of the TLB, the size of the memory that is covered is also getting larger.
Improves the TBL hit rate, which is the speed of address translation.
C. Reduce the use of CPU sys. The use of the SYS portion of the CPU is reduced by increasing the hit ratio of the CPU's TLB.
D. Large pages will lock the SGA in RAM and will not be page out when memory is scarce
4. How to configure Hugepages
Depending on the following steps to configure the hugepages, modifying the hugepages requires restarting the machine.
1). You need to set the Memlock value (in kilobytes) in/etc/security/limits.conf, which is less than the memory size,
For example, if your memory size is 64G, you can set the following values:
* Soft Memlock 60397977
* Hard Memlock 60397977
This value is greater than the SGA requirement and is harmless.
If the Exadata machine, please refer to document 1284261.1 for parameter requirements.
2). re-login to root and Oracle user, check Memlock limit
$ ulimit-l
60397977
3). If you use 11G and later versions, AMM (automatic memory management) is turned on by default, but AMM and hugepages
is incompatible (because Hugepage is a shared memory and not suitable for the PGA), you must first turn off Amm.
4). Make sure that all of your instances have been started (including ASM) and then according to document 401749.1, hugepages_settings.sh
To evaluate the size of the hugepages that needs to be set.
$./hugepages_settings.sh
...
Recommended setting:vm.nr_hugepages = 1496
Note: You can also calculate the required hugepages size, in fact, Hugepages size> all of the SGA sizes
5). Edit/etc/sysctl.conf Settings vm.nr_hugepages parameters:
Vm.nr_hugepages = 1496
6). Stop the instance and restart the OS system
7). Check that the settings are in effect
After the system restarts, start all the databases and check the following command
# grep Hugepages/proc/meminfo
hugepages_total:1496
hugepages_free:485
hugepages_rsvd:446
hugepages_surp:0
hugepages_free< Hugepages_total not only shows that hugepages is in force, but also that HUGEPAGES_RSVD is not "0".
5. How do I control whether the database SGA uses hugepages?
Prior to 11.2.0.2, the SGA in DB can only choose to use all hugepages or do not use hugepages at all.
11.2.0.2 and later versions, Oracle added a new parameter, "Use_large_pages", to manage how the database uses Hugepages.
When 11.2.0.3, use_large_pages this parameter makes Oracle's behavior more flexible. If there is a situation where hugepage is under-allocated,
The SGA is available with those small pages. This guarantees that the database will work in extreme cases.
The Use_large_pages parameter has three values: "True" (default), "only", "false" and "Auto" (since 11.2.0.3 patchset).
a). The default value is "true" now, and if the system is set to Hugepages, the SGA will take precedence over hugepages and how much it is used.
11.2.0.2 If there is not enough hugepages, the SGA will not use Hugepages. This causes a ORA-4030 error because Hugepages has
is allocated from physical memory, but the SGA does not use it, but uses other parts of memory, resulting in insufficient memory resources. But in the 11.2.0.3 version of this
The use policy has been changed, and the SGA can be part of the hugepages, with the remainder using small pages. In this way, the SGA will have limited use of hugepages,
After Hugepages is exhausted, use regular sized pages.
b). If set to "false", the SGA will not use Hugepages
c). If set to "only" if the hugepages size is not sufficient, the DB instance cannot be started (preventing a memory overflow condition to occur).
D). After the 11.2.0.3 version, you can set it to "Auto". This option triggers the oradism process to reconfigure the Linux kernel to increase the hugepages
The quantity.
Reference:
http://hsbxxl.blog.51cto.com/181620/1075166
http://blog.csdn.net/herecles/article/details/16861743
Http://oracle.codemach.com/zai-linux-xia-wei-oracle-kai-qi-da-ye-hugepage.html
http://blog.itpub.net/17203031/viewspace-775004
Linux Hugepage, AMM and Use_large_pages for Oracle 11G (reprint)
