사이드바
java:performance
문서의 이전 판입니다!
목차
Java Performance
- Is setting -Xmx==-Xms still considered harmful? - G1 GC에서는 Xmx==Xms로 두는게 좋다?
- VisualVM jconsole을 대체할 만한 JVM 분석툴.
- Java NIO의 DirectByteBuffer는 필요한 갯수만큼만 만들어서 사용하자 DirectByteBuffer가 사용하는 Bits.reverseMemory()가 System.gc()를 호출한다.
- Jolokia remote JMX with JSON over HTTP
Java World Java Performance Series
32bit/64bit 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을 무한정 늘리면 Full GC 시간 증가로 인해 오히려 성능 병목이 될 수 있다.
- 32bit JVM을 사용하고 2~4GB 이하의 Heap 설정을 사용하는게 나을 수 있다.
- JVM의 Heap을 증가시키기 보다는 JVM을 여러 대 띄운다.
- JVM을 여러개 띄울 수 없다면,
- Apache Direct Memory 혹은 Terracotta Big Memory 등을 사용해 외부에 메모리를 할당한다.
- GC 설정을 튜닝한다. 그러나 현재로서는 확실한 효과를 보장할 수 없을수도.
- Zing JVM Full GC를 하지 않는 JVM
JIT Compiler option
- 특정 메소드가 일정 횟수 있상 실행되면 JIT Compiler가 native 코드로 컴파일한다.
-XX:CompileThreshold가 그 횟수를 지정한다. 기본 1500이며, 너무 작게 주면 서버가 최초로 뜰 때, 컴파일하느라 너무 많은 시간을 소비한다. 따라서 애플리케이션에 따라 적정수를 지정해야 한다. 보통은 100 이상 정도가 적합하다 한다.-server -XX:+TieredCompilation: Java 7, Multi Core 환경에서 이 옵션을 주면 native 컴파일 속도가 향상 된다.
HashMap.get/getEntry, WeakHashMap.get/getEntry 에 대한 동시 접근은 CPU 사용률 증가(High 100%) 유발
HashMap.get/getEntry,WeakHashMap.get/getEntry에 대한 다중 쓰레드 동시접근은 CPU 사용률 증가를 유발한다.- 결론은 동시 접근이 필요할 경우에는
ConcurrentHashMap을 사용하라. - Beautiful race condition : HashMap get infinit loop within a particular bucket.
Selector.select() CPU 100%
java/performance.1441671430.txt.gz · 마지막으로 수정됨: 2015/09/08 08:47 저자 kwon37xi
별도로 명시하지 않을 경우, 이 위키의 내용은 다음 라이선스에 따라 사용할 수 있습니다: CC Attribution-Share Alike 4.0 International
