저도 당연히 많으면 장땡이라고 무조건 크게 힙 잡아두면 성능이 좋아질 거라고 생각했습니다. 왜냐하면 단순하게 생각해도 GC가 덜 일어날테니까요. 하지만 그게 아니더군요.
상세한 것은 폴딩 참고~~
펼쳐두기..
힙이 크게 되면 당연히 GC가 새로운 객체에 대해 공간을 회수할 필요가 있어질 때까지 더 많은 객체를 메모리에 존재하도록 만들어 주지요.
하지만 여기에는 치명적인 약점이 있습니다. 바로 GC가 대기하도록 그만큼 시간을 주는 것이 됩니다. 만약 이렇게 GC가 대기하는 기간이 길어지게 된다면, GC는 탱탱 놀고 있다가 한꺼번에 많은양의 GC를 처리해야 하게 됩니다. 결국 꿩 잡으려다가 꿩도 놓치고 알도 놓치게 됩니다.
관련 내용은 -Xconcgc, -Xincgc 옵션에 대한 내용입니다. 그 내용은 직접 찾아서 보시길 바랍니다.
암튼 요지는 무조건 큰 힙 할당이 반드시 최적 성능을 주는 게 아니라는 겁니다. ㅎ_ㅎ;;
아무래도 직접 찾아서 해봐라니 무책임 하군요! ㅋ_ㅋ;; 돌이 날아오는 듯 하여 달아 둡니다.
-Xincgc는 점진적 혹은 연속적 GC라고 불립니다. JDK에 의해서 사용되는 점진적 GC 알고리즘은 Train 알고리즘입니다. 이 알고리즘은 힙의 신세대와 구세대 사이의 새로운 힙 섹션을 만들게 됩니다. 이들 힙 섹션들은 기차(비유 입니다)들로 나눠지고, 이렇게 나눠진 각각은 또다시 차량(비유죠)들로 나눠지게 됩니다. 각각의 차량들은 따로 따로 회수 될 수 있습니다. 효과적으로, 각각의 기차의 차량은 분할된 세대들을 구성하며, 이게 의미하는 바는 오래된 참조와 새로운 참조가 기록되어져야 할 뿐 아니라, 오래된 기차들에서 새로운 기차, 오래된 차량에서 새로운 차로의 참조 또한 반드시 기록되어져야 한다는 뜻입니다. 이것은 눈에 띄는 여분의 작업을 복제자와 GC에게 생성하도록 하지만, 좀 더 짧은 GC 대기를 가능하게 합니다.
정리 하자면, 각각의 객체와 객체의 컬렉션인 기차가 연속적으로 연결되어서 기록되기 때문에 그것을 연결하는 과정(Tracking)에서 복제자(mutator)와 GC가 하는 일이 늘어나지만, 정보가 기록됨으로 인해서 GC를 빠르게 수행할 수 있게 된다는 뜻입니다. 다만 CPU 사용 시간은 늘어나겠죠.
여기를 참고 했습니다. http://www-128.ibm.com/developerworks/java/library/j-jtp11253/
-Xconcgc의 경우에는 병행 GC라고 불립니다. 이것은 GC 알고리즘을 비동기적으로 실행 중인 Application 쓰레드의 중단을 방지하는 방식으로 변경하는 매개변수입니다. 물론 CPU 점유 시간이 더 차지되기 때문에 전체 GC 시간은 증가하게 되지만, 멀티 프로세서(말하자면 CPU Core가 1개 이상) 시스템에서는 효과적입니다. 이에 관련된 매개변수에는 -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC가 있습니다.
정답은 없고, 힙크기를 변경해가면서 시스템을 프로파일링을 한 후에 적정치를 결정해야 합니다. 이 내용은 생성되는 객체 수, 클래스 로드 수에 따라 GC가 효율적으로 이뤄지도록 설정을 하면 되는 부분입니다. 테스트가 장땡이지요;;
결론은? 삽질 ㅠㅠ
No comments:
Post a Comment