사용자 도구

사이트 도구


java:performance

차이

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

차이 보기로 링크

양쪽 이전 판 이전 판
다음 판
이전 판
다음 판 양쪽 다음 판
java:performance [2015/09/08 08:47]
kwon37xi
java:performance [2018/03/06 15:38]
kwon37xi [32bit/64bit JVM]
줄 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]]
  
 ===== Java World Java Performance Series ===== ===== Java World Java Performance Series =====
줄 32: 줄 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을 무한정 늘리지 말 것 =====
줄 70: 줄 66:
   * [[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://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)]]   * [[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.txt · 마지막으로 수정됨: 2020/09/17 23:00 저자 kwon37xi