사용자 도구

사이트 도구


java:performance

차이

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

차이 보기로 링크

양쪽 이전 판 이전 판
다음 판
이전 판
java:performance [2015/08/10 13:29]
kwon37xi
java:performance [2020/09/17 23:00] (현재)
kwon37xi
줄 25: 줄 25:
   * [[http://www.infoq.com/presentations/jvm-optimization|JVM Optimization 101]]   * [[http://www.infoq.com/presentations/jvm-optimization|JVM Optimization 101]]
   * [[https://github.com/ScottOaks/JavaPerformanceTuning|Examples for O'Reilly & Associates Java Performance Tuning: The Definitive Guide]]   * [[https://github.com/ScottOaks/JavaPerformanceTuning|Examples for O'Reilly & Associates Java Performance Tuning: The Definitive Guide]]
 +  * [[http://www.baeldung.com/java-jvm-warmup|How to Warm Up the JVM]]
 +  * [[https://engineering.linkedin.com/garbage-collection/garbage-collection-optimization-high-throughput-and-low-latency-java-applications|Garbage Collection Optimization for High-Throughput and Low-Latency Java Applications]]
 +  * [[https://apacheignite.readme.io/docs/jvm-and-system-tuning|Garbage Collection Tuning]]
 +  * [[https://docs.gigaspaces.com/latest/production/production-jvm-tuning.html|JVM Tuning]]
 +  * [[http://xmlandmore.blogspot.com/2014/09/jdk-8-thread-stack-size-tuning.html|Xml and More: JDK 8: Thread Stack Size Tuning]]
  
 ===== Java World Java Performance Series ===== ===== Java World Java Performance Series =====
줄 32: 줄 37:
   * [[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을 여러개 띄울 수 없다면,
줄 50: 줄 47:
     * [[http://www.azulsystems.com/products/zing/virtual-machine|Zing JVM]] Full GC를 하지 않는 JVM     * [[http://www.azulsystems.com/products/zing/virtual-machine|Zing JVM]] Full GC를 하지 않는 JVM
  
-===== HashMap.get, HashMap.getEntry 에 대한 동시 접근은 CPU 사용률 증가(High 100%) 유발 ===== +===== JIT Compiler option ===== 
-  * ''HashMap.get'', ''HashMap.getEntry''에 대한 다중 쓰레드 동시접근은 CPU 사용률 증가를 유발한다. +  * [[http://www.javacodegeeks.com/2012/10/warming-up-your-jvm-superfast.html|Warming Up Your JVM - Superfast Production Servers and IDEs]] 
-  * 동시 접근이 필요할 경우에는 ''ConcurrentHashMap''을 사용하라.+  * 특정 메소드가 일정 횟수 있상 실행되면 JIT Compiler가 native 코드로 컴파일한다. 
 +  * ''-XX:CompileThreshold'' 가 그 횟수를 지정한다. 기본 1500이며, 너무 작게 주면 서버가 최초로 뜰 때, 컴파일하느라 너무 많은 시간을 소비한다. 따라서 애플리케이션에 따라 적정수를 지정해야 한다. 보통은 **100** 이상 정도가 적합하다 한다. 
 +  * ''-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/getEntryWeakHashMap.get/getEntry 에 대한 동시 접근은 CPU 사용률 증가(High 100%) 유발 ===== 
 +  * ''HashMap.get/getEntry'', ''WeakHashMap.get/getEntry''에 대한 다중 쓰레드 동시접근은 CPU 사용률 증가를 유발한다. 
 +  * **결론은 동시 접근이 필요할 경우에는 ''ConcurrentHashMap''을 사용하라.**
   * [[http://mailinator.blogspot.kr/2009/06/beautiful-race-condition.html|Beautiful race condition]] : HashMap get infinit loop within a particular bucket.   * [[http://mailinator.blogspot.kr/2009/06/beautiful-race-condition.html|Beautiful race condition]] : HashMap get infinit loop within a particular bucket.
   * [[http://stackoverflow.com/questions/4034141/java-high-cpu-usage|Java - High cpu usage]]   * [[http://stackoverflow.com/questions/4034141/java-high-cpu-usage|Java - High cpu usage]]
줄 58: 줄 67:
   * [[http://stackoverflow.com/questions/3429420/why-java-util-hashmap-getentry-can-block-my-program|multithreading - why java.util.HashMap.getEntry can block my program?]]   * [[http://stackoverflow.com/questions/3429420/why-java-util-hashmap-getentry-can-block-my-program|multithreading - why java.util.HashMap.getEntry can block my program?]]
   * [[http://javaeesupportpatterns.blogspot.kr/2012/02/hashmapget-high-cpu-case-study.html|HashMap.get High CPU]]   * [[http://javaeesupportpatterns.blogspot.kr/2012/02/hashmapget-high-cpu-case-study.html|HashMap.get High CPU]]
 +  * [[http://www.adam-bien.com/roller/abien/entry/endless_loops_in_unsychronized_weakhashmap|Endless Loops In Unsychronized WeakHashMap]]
 +
 +===== Selector.select() CPU 100% =====
 +  * [[http://knight76.tistory.com/entry/Apache-Mina-%EC%82%AC%EB%A1%80%EC%97%90%EC%84%9C-%EB%B3%B8-Selectorselect-%EC%9D%B4%EC%8A%88-cpu-100-%ED%8A%80%EB%8A%94-%ED%98%84%EC%83%81|Apache Mina 사례에서 본 Selector.select() 이슈- cpu 100% 튀는 현상]]
 +  * [[http://stackoverflow.com/questions/20475290/why-does-select-consume-so-much-cpu-time-in-my-program|java - Why does select() consume so much CPU time in my program? - Stack Overflow]]
 +  * [[http://bugs.java.com/view_bug.do?bug_id=6693490|Bug ID: JDK-6693490 (se) select throws "File exists" IOException under load (lnx)]]
 +
 +
java/performance.1439180953.txt.gz · 마지막으로 수정됨: 2015/08/10 13:29 저자 kwon37xi