Memory management is a part of system performance tuning. High-performance computing, database systems, big data platforms and virtualization technologies are developing rapidly. Traditional memory paging mechanisms have encountered performance bottlenecks in these application scenarios. Large page memory is designed to address this bottleneck situation. By increasing page size, reducing the number of page table entries and TLB hit overhead, it enhances memory access efficiency and overall system performance. What is the principle of large page memory? What are the actual application scenarios?
In the traditional memory paging mechanism, the size of each page is usually 4KB. In a 64-bit architecture, if the physical memory is 128GB, it will be divided into more than 30 million pages. This will lead to a sharp increase in page table entries, thereby causing frequent page table look-ups and TLB (Translation Lookaside Buffer) refreshing problems. TLB is a small cache in the CPU used to accelerate virtual address translation. Its size is limited, and its hit rate directly affects the efficiency of the CPU's access to memory. A large number of small pages cause frequent TLB misses, thereby increasing the CPU burden and slowing down the system performance. Huge Page, which is usually 2MB or even 1GB (Gigantic Page) in size, significantly reduces the number of page table entries and improves TLB hit rate by increasing the capacity of each page.
The Linux kernel supports multiple large Page memory mechanisms. The most common ones are static pre-allocated large pages (HugeTLB) and Transparent Huge pages (THP for short). HugeTLB requires system administrators to configure a fixed number of large-page memory areas in advance through parameters, which is suitable for scenarios such as databases that have strict requirements for memory scheduling. In contrast, THP is automatically decided by the kernel whether to merge consecutive small pages into large ones without user intervention, which is more convenient. However, it is also prone to cause performance fluctuations, so it should be used with caution in combination with specific scenarios.
Configuring HugeTLB usually requires administrators to pre-define the number of required large pages. For example, to configure 2048 2MB large pages, the following command can be executed:
echo 2048 > /proc/sys/vm/nr_hugepages
This will allocate 4GB of large page memory for application binding use. If a program is developed using the libhugetlbfs library, its memory allocation can be directed to the large page area through a specific API, thereby bypassing the conventional paging mechanism. Meanwhile, the successfully allocated large pages can be viewed through the following command:
cat /proc/meminfo | grep HugePages
Including key indicators such as total volume, used, and remaining pages. During system initialization, default large page memory requirements can also be passed through kernel startup parameters. For example, the following parameters can be added in GRUB:
default_hugepagesz=2M hugepagesz=2M hugepages=2048
The transparent large page mechanism is enabled by default in modern Linux systems. When there is sufficient memory, the kernel will automatically merge small pages into large pages. However, since this process involves background memory defragmentation and page merging operations, it may cause CPU cycle competition and unstable delays. In some delay-sensitive scenarios (such as real-time computing, financial systems, and live video services), it is recommended to close transparent large pages to avoid interference. The following command can be used:
echo never > /sys/kernel/mm/transparent_hugepage/enabled
In addition, it is necessary to understand the extent to which different hardware platforms support large-page memory. Some older servers or embedded architectures may not support 1GB large pages. Therefore, it is necessary to verify whether the CPU and motherboard have the corresponding capabilities before deployment. Intel's x86_64 architecture has supported Large pages of 2MB and 1GB since the early Nehalem series. Enabling Large Page Support through BIOS or UEFI Settings is usually the first step to ensure compatibility.
When optimizing the memory usage strategy of large pages, the actual load type should be given particular attention. For example, for the Java Virtual Machine (JVM), the Heap space is large and GC is frequent. Therefore, enabling large pages reasonably can significantly reduce memory fragmentation and improve GC efficiency. It can be enabled through the following JVM parameters:
-XX:+UseLargePages
For database services such as MySQL and PostgreSQL, it is recommended to combine the HugeTLB and NUMA strategies, manually bind the data page allocation area, and avoid cross-node access to further improve cache hit rate and CPU affinity. In a KVM virtualization environment, the Hypervisor can also use large pages to improve the performance of virtual memory mapping, but it must be ensured that the host machine has reserved sufficient large page resources; otherwise, it will lead to startup failure or significant performance degradation.
It should be noted that excessive pre-allocation of large page Memory may lead to the failure of allocation by other processes in the system, thereby triggering the OOM (Out of Memory) problem. Therefore, during the optimization process, aggressive configuration should be avoided. It is recommended to make gradual adjustments and observe the system behavior in combination with monitoring data. In the case of failed large page allocation, it can usually be diagnosed through the following command:
dmesg | grep -i huge
The system log will record the reasons for the failure of large page applications, such as severe fragmentation and tight memory. In this case, it can be considered to release fragmented areas through regular page box Compaction or by restarting the system. For the production environment, regularly defragmentation memory in combination with crontab scheduled tasks has become a routine for maintaining a healthy large-page environment.
Overall, large page memory can improve access efficiency and optimize CPU performance, mainly by reducing the page surface level, increasing TLB hit rate, and alleviating performance degradation caused by TLB misses. Large pages have become an important acceleration means in high-load environments such as databases, middleware, and virtualization systems. However, everyone needs to accurately configure, rationally allocate and deeply monitor the system, and optimize it in combination with the actual situation, so as to maximize the value of large page memory!