Java의 -Xms 및 -Xmx 옵션의 트레이드 오프 속도

Java의 -Xms 및 -Xmx 옵션의 트레이드 오프 속도

---

이 두 명령이 주어지면

ㅏ:

$ java -Xms10G -Xmx10G myjavacode input.txt

비:

$ java -Xms5G -Xmx5G myjavacode input.txt

두 가지 질문이 있습니다.

1. 명령 A는 매개 변수와 함께 더 많은 메모리를 예약하므로 A가 B보다 빠르게 실행됩니까?
2. 어떻게 -Xmx및 -Xms실행 과정과 내 프로그램의 출력에 영향을?

---

Java가 사용하는 GC에 따라 다릅니다. 병렬 GC는 더 큰 메모리 설정에서 더 잘 작동 할 수 있습니다. 그래도 저는 전문가가 아닙니다.

일반적으로 메모리가 클수록 GC 처리가 덜 필요합니다. 쓰레기를위한 공간이 많습니다. 그러나 GC와 관련하여 GC는 더 많은 메모리에서 작업해야하므로 속도가 느려질 수 있습니다.

---

-Xmx인수는 힙이 JVM 도달 할 수있는 최대 메모리 크기를 정의합니다. 프로그램을 잘 알고로드 상태에서 어떻게 수행되는지 확인하고 그에 따라이 매개 변수를 설정해야합니다. 값이 낮 으면 OutOfMemoryExceptions 가 발생 하거나 프로그램의 힙 메모리가 최대 힙 크기에 도달하는 경우 성능이 매우 저하 될 수 있습니다 . 프로그램이 전용 서버에서 실행중인 경우 다른 프로그램에 영향을주지 않으므로이 매개 변수를 더 높게 설정할 수 있습니다.

-Xms인수는 JVM의 초기 힙 메모리 크기를 설정합니다. 이것은 프로그램을 시작할 때 JVM이이 양의 메모리를 즉시 할당한다는 것을 의미합니다. 이것은 프로그램이 처음부터 많은 양의 힙 메모리를 소비하는 경우에 유용합니다. 이것은 JVM이 지속적으로 힙을 증가시키는 것을 방지하고 거기에서 약간의 성능을 얻을 수 있습니다. 이 매개 변수가 도움이 될지 모르겠다면 사용하지 마세요 .

요약하면 이것은 프로그램의 메모리 동작만을 기반으로 결정해야하는 절충안입니다.

---

어떤 경우에는 너무 많은 메모리가 프로그램 속도를 늦출 수 있다는 것을 발견했습니다.

예를 들어 부하가 증가함에 따라 느리게 실행되는 최대 절전 모드 기반 변환 엔진이 있습니다. 우리가 db에서 객체를 얻을 때마다 hibernate는 다시는 사용되지 않을 객체에 대한 메모리를 확인하는 것으로 나타났습니다.

해결책은 세션에서 이전 개체를 제거하는 것이 었습니다.

스튜어트

---

1. 할당은 항상 OS에 따라 다릅니다. 너무 많은 메모리를 할당하면 결국 스왑에로드 된 부분이 생길 수 있으며 이는 실제로 느립니다.
2. 프로그램이 더 느리거나 더 빠르게 실행되는지 여부는 VM이 ​​처리하고 정리해야하는 참조에 따라 다릅니다. GC는 버려진 개체를 찾기 위해 할당 된 메모리를 쓸 필요가 없습니다. 객체와 참조 매핑으로 할당 한 메모리 양을 알고 있습니다. 따라서 청소는 물체의 크기에 따라 달라집니다. 프로그램이 두 경우 모두 동일하게 작동하는 경우 VM이 OS에서 제공하는 메모리를 할당하려고 할 때와 스왑을 사용하는 경우 (다시 1로 이어짐) VM 시작시 성능에 영향을 미칩니다.

---

메모리 할당이 속도에 어떤 영향을 미치는지 말하기는 어렵습니다. JVM이 사용하는 가비지 콜렉션 알고리즘에 따라 다릅니다. 예를 들어 가비지 수집기가 전체 수집을 수행하기 위해 일시 ​​중지해야하는 경우 실제로 필요한 것보다 메모리가 10 개 더 많으면 수집기에 정리할 가비지 10 개가 더 있습니다.

Java 6을 사용하는 경우 jdk의 bin 디렉토리에있는 jconsole을 사용하여 프로세스에 연결하고 수집기가 어떻게 작동하는지 확인할 수 있습니다. 일반적으로 수집가는 매우 똑똑하고 조정을 할 필요가 없지만 필요한 경우 수집 프로세스를 추가로 조정하는 데 사용할 수있는 다양한 옵션이 있습니다.

---

> C:\java -X

-Xmixed           mixed mode execution (default)
-Xint             interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by ;>
                  set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by ;>
                  append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by ;>
                  prepend in front of bootstrap class path
-Xnoclassgc       disable class garbage collection
-Xincgc           enable incremental garbage collection
-Xloggc:<file>    log GC status to a file with time stamps
-Xbatch           disable background compilation
-Xms<size>        set initial Java heap size
-Xmx<size>        set maximum Java heap size
-Xss<size>        set java thread stack size
-Xprof            output cpu profiling data
-Xfuture          enable strictest checks, anticipating future default
-Xrs              reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni       perform additional checks for JNI functions
-Xshare:off       do not attempt to use shared class data
-Xshare:auto      use shared class data if possible (default)
-Xshare:on        require using shared class data, otherwise fail.

-X옵션은 예고없이 변경이 아닌 표준 될 수 있습니다.

(복사 붙여 넣기)

---

This was always the question I had when I was working on one of my application which created massive number of threads per request.

So this is a really good question and there are two aspects of this:
1. Whether my Xms and Xmx value should be same
       - Most websites and even oracle docs suggest it to be the same. However, I suggest to have some 10-20% of buffer between those values to give heap resizing an option to your application in case sudden high traffic spikes OR a incidental memory leak.

2. Whether I should start my Application with lower heap size
       - So here's the thing - no matter what GC Algo you use (even G1), large heap always has some trade off. The goal is to identify the behavior of your application to what heap size you can allow your GC pauses in terms of latency and throughput.
              - For example, if your application has lot of threads (each thread has 1 MB stack in native memory and not in heap) but does not occupy heavy object space, then I suggest have a lower value of Xms.
              - If your application creates lot of objects with increasing number of threads, then identify to what value of Xms you can set to tolerate those STW pauses. This means identify the max response time of your incoming requests you can tolerate and according tune the minimum heap size.

참고URL : https://stackoverflow.com/questions/1043817/speed-tradeoff-of-javas-xms-and-xmx-options