Oracle Exadata - Huge Pages - In the context of Exadata - Oracle Linux - Oracle Exadata Huge Pages!
Oracle Exadata - Huge Pages - In the context of Exadata - Oracle Linux - Oracle Exadata Huge Pages!
Huge Pages: In the context of Exadata:
Oracle Huge Pages - Enabling Huge Pages makes it possible for the operating system to support memory pages greater than the default (usually 4 KB). Using very large page sizes can improve system performance by reducing the amount of system resources required to access page table entries.
Huge Pages : In the context of Exadata
Note: This article is focused on the Linux/x86 platform. Other platforms have different configurations for Huge Pages but the core concepts remain the same.
Memory is an important resource for running any software on a system but is even more important for running Oracle Database. Memory plays an important role in database performance because keeping data in memory leads to higher database performance. Oracle In-Memory Database places even more data into a system's main memory instead of relying on storage I/O. Modern applications need databases to deliver lower latency and higher throughput than ever before. Large scale databases often extend into the petabyte range, while I/O latency needs have pushed into the range of microseconds Due to these ever-increasing demands, it has become even more important to fit frequently accessed data in system memory. Advancements in technology with higher number of processor cores and faster networks make it evident that systems are pushing into the range where terabytes of memory are required. Let us see how memory is organized in these large-scale systems.
System Memory - How is it organized?
Memory is organized in blocks known as pages. A page in Linux x86-based systems is 4K in size (4096 bytes), with total memory stretching into terabytes. A system with 1 gigabyte of memory has 256,000 pages using a 4K page size. All of these pages are managed by the memory management unit (MMU) of the CPU. Consider for example, a system that has 1 TB (terabyte) of memory using the standard 4K (4096 bytes) page size. That system will have to manage more than 268 million pages! The overhead for the MMU to manage that many pages will degrade performance.
Page Entries - How are they managed?
The MMU can manage large amounts of memory only by using large numbers of page table entries in the MMU, which introduces high amounts of performance overhead. One alternative is to increase the page size from 4K bytes to something larger to reduce the number of page table entries. However, this approach would waste memory for applications that work perfectly well with 4K page sizes. The solution is to use separate memory allocations for structures like the Oracle System Global Area (SGA) that require large amounts of memory, leaving conventional 4K pages for other uses. This is where Huge Pages comes into play.
How to calculate number of Huge Pages:
Memory configuration for databases is critical for optimal performance. In Oracle database, there is shared memory that contains the SGA (System Global Area) and private memory that contains the PGA (Process Global Area). OLTP (online transaction processing) workloads typically require more data in the Buffer Cache (an area of the SGA) for fastest access. Data Warehouse or Analytic workloads typically offload more work to Exadata Storage Servers and need more private memory in the PGA.
Although SGA sizes can vary depending on the type of workload such as OLTP vs. Analytics, Oracle Databases perform optimally when the entire SGA resides in Huge Pages. The appropriate size of the SGA is system-dependent and is limited by resources available on the system. The proper number of Huge Pages is based on the aggregate size of all SGAs for Databases running on the system. Using a Huge Page size of 2M, an SGA sized at 50G (51200M) will require 51200/2 = 25600 Huge Pages. For the sake of simplicity, Oracle recommends adding extra Huge Pages to account for byte offset and page alignment requirements.
Oracle Database will use the SGA size (specified in the spfile.ora) to calculate the number of Huge Pages required. Oracle will fit the SGA in the Huge Pages and/or standard 4K pages depending on the parameter setting for USE_LARGE_PAGES.
What are the options for USE_LARGE_PAGES?
The parameter USE_LARGE_PAGES has several options outlined in the manual as follows:
FALSE: With this setting database instance will not use Huge Pages. This setting is not recommended for use with large SGA sizes because better performance can be achieved using Large Pages (also known as Huge Pages).
TRUE: This setting allows Oracle databases to use a combination of Large Pages and 4K pages, by allocating as many Large Pages as possible before allocating 4K pages. This setting is not recommended for use with large SGA sizes because better performance can be achieved by using Large Pages exclusively using the ONLY setting.
AUTO: This setting is intended as a convenience to eliminate the need for coordination between DBA and SysAdmin. Oracle recommends using the ONLY setting instead. The AUTO setting uses SGA sizes to determine the number of large pages required in the Operating System and automatically configures as many Huge Pages as possible. The SGA of each database may use a combination of Huge Pages and 4K pages, so this setting is not recommended.
ONLY: This parameter value was introduced to make sure all the SGA will reside in Huge Pages. Oracle recommends this setting for consistent performance. Databases will fail to start if there aren’t sufficient Huge Pages available, but this is preferred over databases starting with a sub-optimal configuration.
AUTO_ONLY: As with AUTO, this setting is intended as a convenience to eliminate the need for coordination between DBA and SysAdmin. This setting automatically determines the number of Huge Pages required to fit each SGA, and the SGA will only reside in Huge Pages. Oracle recommends using the ONLY setting.
Note for Exadata Systems:
To maximize performance and stability, Oracle recommends always using large memory pages for the SGA, setting Huge Pages in advance, and using USE_LARGE_PAGES=ONLY for optimal system performance. Oracle automation tools use the setting USE_LARGE_PAGES=ONLY. This includes databases created using Oracle Exadata Deployment Assistant (OEDA) and databases created on a cloud-based Exadata deployment (using Exadata Database Service). The Oracle Exadata Configuration check utility (ExaChk) also checks for this setting and recommends
USE_LARGE_PAGES=ONLY as well.
When USE_LARGE_PAGES=ONLY, the database fails to start if insufficient large pages are available to contain the SGA. In this case, the system administrator must configure the operating system to ensure enough large pages are available to cover all databases, or SGA sizes need to be decreased to stay within the number of Huge Pages available.
Conclusion:
Exadata in on-premises and Cloud deployments is a consolidation platform that enables massive scalability and terabytes of system memory. The standard Linux memory page size is 4K, which is not appropriate for massive SGA sizes of modern high performance Oracle Databases on Exadata. Oracle recommends using large pages for SGA memory exclusively through the setting USE_LARGE_PAGES=ONLY on all Exadata systems.
Reference:
https://blogs.oracle.com/exadata/post/huge-pages-in-the-context-of-exadata
Cheers!
Ramesh Kumar Krishnamoorthy
Connect me on:
Blog: https://www.oralgwr.com/
LinkedIn: https://www.linkedin.com/in/ramesh-kumar-krishnamoorthy-3a67ba69/
Twitter: https://twitter.com/sachinrameshdba
Facebook: https://www.facebook.com/rameshkumar.krishnamoorthy.9/
Facebook Page: https://www.facebook.com/oraclef1
Instagram: https://www.instagram.com/oraclef1_1
YouTube: https://www.youtube.com/@oraclef1
Post a Comment: