사용자 도구

사이트 도구


java:performance

차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

차이 보기로 링크

양쪽 이전 판 이전 판
다음 판
이전 판
java:performance [2018/03/06 15:36]
kwon37xi [Java Performance]
java:performance [2018/03/06 15:39] (현재)
kwon37xi
줄 35: 줄 35:
   * [[http://​www.javaworld.com/​javaworld/​jw-11-2012/​121107-jvm-performance-optimization-low-latency-garbage-collection.html|JVM performance optimization,​ Part 4: C4 garbage collection for low-latency Java applications]]   * [[http://​www.javaworld.com/​javaworld/​jw-11-2012/​121107-jvm-performance-optimization-low-latency-garbage-collection.html|JVM performance optimization,​ Part 4: C4 garbage collection for low-latency Java applications]]
   * [[http://​www.javaworld.com/​javaworld/​jw-03-2013/​130301-jvm-performance-optimization-java-scalability.html|JVM performance optimization,​ Part 5: Is Java scalability an oxymoron? - JavaWorld]]   * [[http://​www.javaworld.com/​javaworld/​jw-03-2013/​130301-jvm-performance-optimization-java-scalability.html|JVM performance optimization,​ Part 5: Is Java scalability an oxymoron? - JavaWorld]]
-===== 32bit/64bit JVM ===== 
-  * [[http://​plumbr.eu/​blog/​should-i-use-32-or-64-bit-jvm|Should I use a 32- or a 64-bit JVM?]] : 32bit JVM의 성능이 더 좋다. 
-  * 64bit JVM은 32bit 보다 30~40%의 Heap을 더 사용한다. 따라서 더 많은 메모리 할당이 필요하고,​ GC할 때 더 많은 시간이 걸린다. 
-  * 32bit JVM의 제약 
-    * 리눅스 : 최대 2GB Heap, hugemem 커널의 경우 3GB 
-    * 윈도우 : 최대 1.5GB Heap, ''/​3GB''​ 부트 플래그가 있고 JRE가 ''/​LARGEADDRESSAWARE''​ 옵션으로 컴파일 됐을 경우 3GB 
-    * Mac OS X : 3.8GB 
  
 ===== JVM의 Heap을 무한정 늘리지 말 것 ===== ===== JVM의 Heap을 무한정 늘리지 말 것 =====
   * [[http://​plumbr.eu/​blog/​increasing-heap-size-beware-of-the-cobra-effect|Increasing heap size – beware of the Cobra Effect]]   * [[http://​plumbr.eu/​blog/​increasing-heap-size-beware-of-the-cobra-effect|Increasing heap size – beware of the Cobra Effect]]
   * JVM Heap을 무한정 늘리면 Full GC 시간 증가로 인해 오히려 성능 병목이 될 수 있다.   * JVM Heap을 무한정 늘리면 Full GC 시간 증가로 인해 오히려 성능 병목이 될 수 있다.
-  * 32bit JVM을 사용하고 2~4GB 이하의 Heap 설정을 사용하는게 나을 수 있다. 
   * JVM의 Heap을 증가시키기 보다는 JVM을 여러 대 띄운다.   * JVM의 Heap을 증가시키기 보다는 JVM을 여러 대 띄운다.
   * JVM을 여러개 띄울 수 없다면,   * JVM을 여러개 띄울 수 없다면,
줄 58: 줄 50:
   * ''​-XX:​CompileThreshold''​ 가 그 횟수를 지정한다. 기본 1500이며, 너무 작게 주면 서버가 최초로 뜰 때, 컴파일하느라 너무 많은 시간을 소비한다. 따라서 애플리케이션에 따라 적정수를 지정해야 한다. 보통은 **100** 이상 정도가 적합하다 한다.   * ''​-XX:​CompileThreshold''​ 가 그 횟수를 지정한다. 기본 1500이며, 너무 작게 주면 서버가 최초로 뜰 때, 컴파일하느라 너무 많은 시간을 소비한다. 따라서 애플리케이션에 따라 적정수를 지정해야 한다. 보통은 **100** 이상 정도가 적합하다 한다.
   * ''​-server -XX:​+TieredCompilation''​ : Java 7, Multi Core 환경에서 이 옵션을 주면 native 컴파일 속도가 향상 된다.   * ''​-server -XX:​+TieredCompilation''​ : Java 7, Multi Core 환경에서 이 옵션을 주면 native 컴파일 속도가 향상 된다.
 +
 +===== Linux Tuning =====
 +  * [[linux:​performance|Linux Performance]]
 +  * 기본적으로 ''​swappiness=1''​로 스왑 가능성을 줄이고 file과 process 제약을 풀어준다.<​code>​
 +ulimit -n 32768 -u 32768
 +</​code>​
  
 ===== HashMap.get/​getEntry,​ WeakHashMap.get/​getEntry 에 대한 동시 접근은 CPU 사용률 증가(High 100%) 유발 ===== ===== HashMap.get/​getEntry,​ WeakHashMap.get/​getEntry 에 대한 동시 접근은 CPU 사용률 증가(High 100%) 유발 =====
java/performance.1520319998.txt.gz · 마지막으로 수정됨: 2018/03/06 15:36 저자 kwon37xi