Troubleshooting 스레드사용법

문제해결 방안 1.

1. 쓰레드의 생성과 소멸은 구현되어 있으나, 작업중인 쓰레드가 있으면 소멸시키지 못하여 그 쓰레드는 waiting 상태로 남는다. 

2. 그럼 쓰레드가 실행된것을 확인 후 소멸을 구현하자.  => 실행된 것을 확인하고 소멸시키는 과정의 수행시간이 1초 이상걸려 발송이 지연되는 현상

3. 쓰레드 소멸 실행 후 일정시간뒤에 여전히 작업중으로 소멸되지 못하면 강제로 소멸시킨다. => 소멸시키는 과정에서 새로운 작업요청이 들어올 경우 RejectedExecutionException 발생할 가능성

4. 이 상황을 모니터링하기 위해 쓰레드에 이름을 부여한다.  =>  thread - XXX 형식의 이름 부여하여, 쓰레드 모니터링 비교적 쉬워짐

5. 쓰레드가 정상작동했는지 여부는 예상되는 작업건수와, 최종 쓰레드에서 실행한 작업건수가 동일한지 카운트로 비교한다. => Exception 발생시 동일하지 않음

6. waiting중인 쓰레드가 없는지 확인한다. => 정상

 

테스트 조건

JDK1.8

Heap 1024MB, NewRatio:2

발송 120만건씩 동시 3건의 메세지 멀티쓰레드 최대100개로 발송, 루프 5번

 

테스트 결과

1. 현재버전 테스트  => 쓰레드의 Live 갯수(5279)와 peak 갯수(5279) 확인

 

2. 쓰레드 생성~종료 수정 테스트  => 쓰레드의 Live 갯수(105)와 peak 갯수(110) 확인, Total Started Thread(12074) 확인

 

또다른 문제발생

쓰레드의 생성과 소멸에 대한 자원낭비가 있음

쓰레드가 실행된 후 소멸에 대한 시점 정의때문에 RejectedExecutionException 가능성 있음

쓰레드 실행 후 리턴값을 받아 소멸시킬 경우, 실행 속도가 느려짐.

 

 

 

문제해결 방안 2.

1. 쓰레드 풀링기법으로, 일정갯수의 쓰레드를 생성하여 풀에 저장하고, 사용시에는 풀에서 꺼내쓰고 그 외에는 idle 상태가 된다

2. 쓰레드풀의 갯수 최대값 지정함

3. 쓰레드가 증가하여 병목현상이 발생해도 저장된 풀링에 한해서만 발생하는 현상이므로, 다른 작업에 영향을 미치지 않는다.

4. 업무성격에 따라 쓰레드풀을 나누어 사용하는것이 바람직

 

테스트 조건

JDK1.8

Heap 2048MB, NewRatio:2

120만건씩 동시 3건의 메세지 멀티쓰레드 최대20개로 발송, 루프 5번

 

테스트 결과

1. 쓰레드풀링 테스트  => 쓰레드의 Live 갯수(129)와 peak 갯수(134) 확인, Total Started Thread(2600) 확인 

문제해결1번의 2번 스샷과 비교하면 total thread의 갯수 차이를 확인 할 수 있다. 

즉, 매번 생성~소멸 의 과정을 만들지 않고 일정갯수의 쓰레드를 생성하여 running~waiting 상태를 반복하여 1번방법의 문제를 해결함.

조건 : 쓰레드 대기상태와, 빠른 실행에 따른 전송결과를 메모리에 일정시간 보관하고 있는 로직을 염두하면 넉넉한 HeapMemory 용량 설정고려

 

 

 

2번 방안 적용 후 라이브 한대씩 적용하여 모니터링

 

14번 서버에 먼저 적용!

 결과 1) 쓰레드 생성~종료 없어지므로 실행 속도 2배 빨라짐

 

1) 수정 전 그래프

• 수정전 7일동안의 메모리 현황 그래프

 

 

2) 수정 후 그래프

• 
• 
  
• 수정 후 6일동안의 메모리 현황 그래프 
• 4/21 서버 재시작 후 초기 메모리 사용이 필요한 데이터 로드 이후, 안정적인것을 확인할 수 있음.