"huge pages" 를 기준으로 대용량 메모리를 할당 했을때를 목표로 한다
센트 7 "huge pages"가 2M다
# cat /proc/meminfo | grep Huge HugePages_Total: 10 HugePages_Free: 10 HugePages_Rsvd: 0 Hugepagesize: 2048 kB
튜닝할때 이 부분이 가장 묘할듯 OS를 넘나들면서 옵션을 조정해야 한다.
아티클을 봤을때
16G Heap을 지정하려면 Hugepagesize도 같이 튜닝이 필요하므로
앞서 JVM 옵션만 가지고 튜닝하던것 + OS 튜닝도 같이 계산에 고려해야 한다.
Large pages are also known as "huge pages" on Linux/x86 and have a size of 2MB.
Let's assume you want a 16G Java heap. That means you need 16G / 2M = 8192 huge pages.
First assign at least 16G (8192 pages) of memory to the pool of huge pages. The "at least" part is important, since enabling the use of large pages in the JVM means that not only the GC will try to use these for the Java heap, but also that other parts of the JVM will try to use them for various internal data structures (code heap, marking bitmaps, etc). In this example we will therefore reserve 9216 pages (18G) to allow for 2G of non-Java heap allocations to use large pages.
Configure the system's huge page pool to have the required number pages (requires root privileges):
Note that the above command is not guaranteed to be successful if the kernel can not find enough free huge pages to satisfy the request. Also note that it might take some time for the kernel to process the request. Before proceeding, check the number of huge pages assigned to the pool to make sure the request was successful and has completed.
NOTE! If you're using a Linux kernel >= 4.14, then the next step (where you mount a hugetlbfs filesystem) can be skipped. However, if you're using an older kernel then ZGC needs to access large pages through a hugetlbfs filesystem.
Mount a hugetlbfs filesystem (requires root privileges) and make it accessible to the user running the JVM (in this example we're assuming this user has 123 as its uid).
Now start the JVM using the
-XX:+UseLargePages option.
If there are more than one accessible hugetlbfs filesystem available, then (and only then) do you also have to use
-XX:ZPath to specify the path to the filesystems you want to use. For example, assume there are multiple accessible hugetlbfs filesystems mounted, but the filesystem you specifically want to use it mounted on /hugepages, then use the following options.
NOTE! The configuration of the huge page pool and the mounting of the hugetlbfs file system is not persistent across reboots, unless adequate measures are taken.
==================
참고
http://openjdk.java.net/projects/zgc/
https://wiki.openjdk.java.net/display/zgc/Main
JEP 333 ZGC A Scalable Low-Latency Garbage Collector (Experimental) (JDK-8197831)
hotspot/gc
The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector (JEP 333). It is designed to meet the following goals:
- Pause times do not exceed 10 ms
- Pause times do not increase with the heap or live-set size
- Handle heaps ranging from a few hundred megabytes to multi terabytes in size
At its core, ZGC is a concurrent garbage collector, meaning that all heavy lifting work (marking, compaction, reference processing, string table cleaning, etc) is done while Java threads continue to execute. This greatly limits the negative impact that garbage collection has on application response times.
ZGC is included as an experimental feature. To enable it, the
-XX:+UnlockExperimentalVMOptions option will therefore need to be used in combination with the -XX:+UseZGC option.
This experimental version of ZGC has the following limitations:
- It is only available on Linux/x64.
- Using compressed oops and/or compressed class points is not supported. The
-XX:+UseCompressedOopsand-XX:+UseCompressedClassPointersoptions are disabled by default. Enabling them will have no effect. - Class unloading is not supported. The
-XX:+ClassUnloadingand-XX:+ClassUnloadingWithConcurrentMarkoptions are disabled by default. Enabling them will have no effect. - Using ZGC in combination with Graal is not supported.
