Large Pages说明
sun文档： http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html
说白了，就是在操作系统级别上，针对进程的虚拟内存空间，使用大内存页，避免频繁的进行页换入换出，出现系统抖动。同样使用大内存分页，也会有一些负面影响，两快大内存分页之间会出现一些内存碎片，从而影响整体系统的性能，当一旦没有足够的大内存块时，整个OS下系统进程又会将原先的大内存打散恢复默认的内存分页。
Linux下如何配置large Page
If the output shows the three "Huge" variables then your system can support large page memory, but it needs to be configured. If the command doesn't print out anything, then large page support is not available. To configure the system to use large page memory, one must log in as root, then:
Increase SHMMAX value. It must be larger than the Java heap size. On a system with 4 GB of physical RAM (or less) the following will make all the memory sharable:
Specify the number of large pages. In the following example 3 GB of a 4 GB system are reserved for large pages (assuming a large page size of 2048k, then 3g = 3 x 1024m = 3072m = 3072 * 1024k = 3145728k, and 3145728k / 2048k = 1536):
Note the /proc values will reset after reboot so you may want to set them in an init script (e.g. rc.local or sysctl.conf).
参数配置
sun jdk :
sun文档： http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html
说白了，就是在操作系统级别上，针对进程的虚拟内存空间，使用大内存页，避免频繁的进行页换入换出，出现系统抖动。同样使用大内存分页，也会有一些负面影响，两快大内存分页之间会出现一些内存碎片，从而影响整体系统的性能，当一旦没有足够的大内存块时，整个OS下系统进程又会将原先的大内存打散恢复默认的内存分页。
摘自sun文档的原话 写道
A Translation-Lookaside Buffer (TLB) is a page translation cache that holds the most-recently used virtual-to-physical address translations. TLB is a scarce system resource. A TLB miss can be costly as the processor must then read from the hierarchical page table, which may require multiple memory accesses. By using bigger page size, a single TLB entry can represent larger memory range. There will be less pressure on TLB and memory-intensive applications may have better performance.
However please note sometimes using large page memory can negatively affect system performance. For example, when a large mount 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. Also please note for a system that has been up for a long time, excessive fragmentation can make it impossible to reserve enough large page memory. When it happens, either the OS or JVM will revert to using regular pages.
However please note sometimes using large page memory can negatively affect system performance. For example, when a large mount 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. Also please note for a system that has been up for a long time, excessive fragmentation can make it impossible to reserve enough large page memory. When it happens, either the OS or JVM will revert to using regular pages.
Linux下如何配置large Page
Large page support is included in 2.6 kernel. Some vendors have backported the code to their 2.4 based releases. To check if your system can support large page memory, try the following:
1.cat /proc/meminfo | grep Huge
2.HugePages_Total: 0
3.HugePages_Free: 0
4.Hugepagesize: 2048 kB
If the output shows the three "Huge" variables then your system can support large page memory, but it needs to be configured. If the command doesn't print out anything, then large page support is not available. To configure the system to use large page memory, one must log in as root, then:
Increase SHMMAX value. It must be larger than the Java heap size. On a system with 4 GB of physical RAM (or less) the following will make all the memory sharable:
1.echo 4294967295 > /proc/sys/kernel/shmmax Specify the number of large pages. In the following example 3 GB of a 4 GB system are reserved for large pages (assuming a large page size of 2048k, then 3g = 3 x 1024m = 3072m = 3072 * 1024k = 3145728k, and 3145728k / 2048k = 1536):
1.echo 1536 > /proc/sys/vm/nr_hugepages Note the /proc values will reset after reboot so you may want to set them in an init script (e.g. rc.local or sysctl.conf).
参数配置
sun jdk :
- -XX:LargePageSizeInBytes=128m
- -XX:+UseLargePages
jrockit jdk :
效果
摘录校长的测试结果： 写道
这个设置， 目前观察下来的结果是EDEN区域收集明显速度比较快， 最多几个ms, 但是，对于FGC， 大约需要0。9， 但是发生时间非常的长， 应该是影响不大。 但是对于非web应用的中间件服务, 这个设置很要不得, 可能导致很严重延迟效果.这时需要搭配cms，加速old区的并发收集
