간단하게 설명하자면 과부하는 

자바내에 있는 GC 즉 가비지 컬렉터 기능이 정상적으로 수행되지 않는것으로부터 발생한다.

GC(가비지 컬렉터)란 자바에서 현재 쓰지 않는 메모리들을 자동으로 청소해주는 역활을 한다고 보면 된다.

 

GC가 정상적으로 되지 않는것에는 2가지의 이유가 있다.

1. 소스내부의 코딩 문제

2. 메모리할당이 잘못됨

 

 

1번의 문제는 소스내부 코딩이 잘못되서 다 쓴것이지만 GC가 청소를 못시켜주게됨 -> 반복 -> 과부하

(프@메에서 다수 발생되는 문제)

 

2번의 문제는 메모리할당이 잘못됨

가끔식 보면 XMS 4G XMX 4G 할당하는 얘들 있던데 그냥 둘다 지우셈

자신에게 맞는 GC방법으로 튜닝만 해도 과부하는 어느정도 막음 (1번문제 제외)

 

 

자 그럼 1번문제는 어떻게 해결해야 될까

자바는 우리에게 아주 좋은 해결책인 VisualVM을 주고갔다.

Java폴더-jdk-bin폴더 보면 jvisulvm이 있다.

가보면 visualGC기능도 있고 Sampler로도 현재 내가 사용하는 메모리나 CPU에서 가장 많이 불러오는것이 무엇인지 알수있다.

또한 덤프기능도 있는데 덤프를 한뒤 메모리에널라이즈라는 툴으로 분석하는것으로도 과부하를 잡을수 있지만

현역개발자들도 분석이 어렵다고 한다.

 

구버전의 경우 과부하의 원인은 쓰레드다.

대부분이 이용하는 화이트스타팩이라는건 자바의 기본코어를 이용하는데,

이 노답새끼들이 중요한게 뭐냐면 누가 접속할때마다 소켓을 생성한다.

그 과정에서 누군가의 소켓하나가 문제가난다면?

특히 많은 동접을 소유하고있는곳에서는 기본소켓을 쓰면 과부하가 일어날수밖에 없으니

구버전 대규모를 키우고싶다면 소켓부터 갈아치워라.

 

고버전의 경우 과부하의 원인은 소스코딩이다.

JVISUALVM으로 샘플러를 통해 CPU와 메모리에서 불러들이는것만으로도 확인해서 찍어맞추기로 소스코딩의 문제를 바로잡으면 좋겠지만 운이나쁠경우 메모리에널라이즈까지 써서 분석해야될 경우도 있다.

출처 : http://gamezone.live/?mid=board_RYMI94&page=2&document_srl=378496