2020. 7. 29. 18:00ㆍDateBase
현재 이메일 배치를 돌면서 문제가 발생하는 상황이 나타남. 이것에 대하여 hikariPC 옵션들을 찾아보고 알아봤음
참고 자료
1. 우리와 비슷한 상황에서 커넥션 누수를 스텝 바이 스텝으로 해결한 블로그
https://do-study.tistory.com/97
2. hikariCP 옵션들을 정리한 블로그
https://jamong-icetea.tistory.com/212
https://effectivesquid.tistory.com/entry/HikariCP-세팅시-옵션-설명
3. HikariCP 옵션 설정 정보
https://pkgonan.github.io/2018/04/HikariCP-test-while-idle
4. wait_time 설정 정보
https://knight76.tistory.com/entry/30031445050
5. max_connections 구하는식
https://qastack.kr/dba/1229/how-do-you-calculate-mysql-max-connections-variable
6. DB 옵션값 (wait_time 등 설정 법)
http://www.linuxchannel.net/docs/mysql-timeout.txt
위의 정보를 참고하여 정리
-
maxLifetime 조정 : 보통은 디비의 wait_timeout 설정값을 hikariCP의 maxLifetime 보다 길게 잡고있는것을 권장함
우리 서버의 상황 : hikariCP의 maxLifetime = 1800000 (30분)
DB의 wait_timeout = 28800 (8시간) # 모두 기본 설정값이다.
그렇기에 알맞는 값을 찾는게 우선
2. hikariCP 옵션 추가
위의 두 옵션이 유용할 것 같아 옵션을 추가하는 방법도 생각을 하였다.
하지만 idleTimeout의 경우 전제 조건이 있는데 최적의 사용을 위한다면 minimumidle을 설정 하지 않는것이 좋다는 글을 봐서 이 옵션은 패스 하고 leakDetectionThreshold만 추가 하는 것이 좋다고 생각.
추후 추가하려 했지만 이미 BaseDataSourceConfig.java 에 500초로 설정되어 있음 - 너무 긴 상황
6번 사이트를 참고하여 DB의 wait_time을 구한 후 maxLifeTime을 wait_time - 3초 정도 하면 될 것으로 생각
(3번의 내용 중)
현재 DB의 max_connection이 4030 이지만 너무 크기도 하고 실제 사용량을 확인해보니 최대 : 247
(6번 사이트의 내용 중)
이 값을 참고하여 max_connection을 넉넉잡고 500으로 했을 경우 wait_time 값은 141.442 정도 나온 것으로 확인
wait_time = 141초
maxLifeTime = 138초
leakDetectionThreshold = maxLifeTime보다 작게 설정하면 될것, leakDetectionThreshold 값 같은 경우 얼마로 설정 하라는 글이 없어 정확한 값은 못 봤음 (대부분 2초 ~ 1분 정도 설정함)
테스트
테스트는 환경설정이라 톡데브(및 알파)에서 못해도 2주 정도는 테스트를 해야한다고 생각함.