Should I enable large page support for Java?
SOLUTION 已验证 - 已更新 2016年二月3日23:45 -
环境
- Java
问题
- Should I enable large page support for Java?
决议
Enabling large page support can provide performance improvements with large heaps (> 4GB). However, there are trade-offs to consider.
Pros
- In Linux, the mapping of physical memory frames and virtual memory pages is stored in the Page Table. Page Table lookups are very expensive, so the information is cached in the Translation Lookaside Buffer (TLB). A viirtual memory address is first looked up in the TLB to find the corresponding physical memory address, and if it is not found (a TBL miss) then the expensive Page Table lookup is done. When page sizes are large, a single TLB entry can span a larger memory area, resulting in reduced TLB misses.
- Large page shared memory is locked into memory and cannot be swapped to disk, so it guards against swapping, which is unacceptable for Java application performance.
Cons
-
Large pages can sometimes negatively impact system performance. For example, when a large amount of memory is pinned by an application, it may create a shortage of regular memory and cause excessive paging in other applications and slow down the entire system.
-
For a system that has been up for a long time, excessive fragmentation can make it impossible to reserve enough large page memory, and the OS may revert to using regular pages. This effect can be minimized by allocating the entire heap on startup (e.g. setting
-Xms
=-Xmx
,-XX:PermSize
=-XX:MaxPermSize
and-XX:InitialCodeCacheSize
=-XX:ReserverCodeCacheSize
). - The default sizes of memory areas (e.g. the permanent generation or code cache with OpenJDK or Sun JDK) might be larger as a result of using a large page if the large page size is larger than the default sizes for these memory areas.