사이드바
java:database:hikaricp
문서의 이전 판입니다!
HikariCP
주의점
- HikariCP는 시간에 매우 민감하다. 서버의 시간을 NTP로 동기화해야만 한다. 안그러면 Pool Wait 시간이 무한정 늘어나거나 하는 현상이 발생할 수 있다.
- 가상 머신 사용시에 Supervisor의 시간에 의존하면 안되고 VM 자체가 NTP 동기화가 돼 있어야만 한다.
- Do not rely on hypervisor settings to “synchronize” the clock of the virtual machine. Configure time-source synchronization inside the virtual machine.
- 이는 시간에 민감하게 작동하는 모든 Java 애플리케이션/라이브러리와 상관이 있다.
- maxlifetime 은 항상 DB가 접속을 끊는 시간(MySQL의 경우
wait_timeout) 값 보다 짧아야만 한다- Tomcat JDBC Pool이나 DBCP - Java Connection Pool와는 달리 중간중간 idle 커넥션에 대한 연결 유지 기능이 없기 때문
Performance Tuning
leak detection
leakDetectionThreshold0이면 검출하지 않음.
- 특정 시간 이내에 커넥션이 반환이 안 되면 connection leak 으로 판단하고 leak 을 일으킨 stack trace 를 로그로 남기는 기능이 있음.
- 단, 이것은 진짜 leak이 아니고 지정 시간이 지나도 쿼리가 계속 실행될 경우, leak-detection 으로 판단하기도 하기 때문에 혼란을 줄 수 있다. * 따라서 이 값을
maxLifeTime보다 작게 주는 것이 좋다. ===== 참고 ===== * HikariCP는 test-while-idle과 같은 커넥션 갱신 기능이 없을까? *test-while-idle로 접속을 장시간 유지하지 말고max-lifetime을 짧게 줘서 커넥션을 새로 맺게 하자. *max-lifetime이 DB의wait_timeout보다 더 적은 값이라는 것(2~3초 정도 짧게)을 확인해야한다.**- HikariCP는 max-lifetime에 의한 커넥션 교체를 별도 쓰레드에서 성능저하 없이 부드럽게 수행한다.
-
- MySQL Replication(or Aurora Cluster)와 HikariCP 문제
- master 다운되고 그 상태 유지시에 slave도 작동을 안함.
- 이 문제를 조금이나마 피하려면
max-lifetime을 짧게 주면 될 듯.
- #657 idleTimeout does not appear to be being honoured : Pool의
minIdle == maxPoolSize인 경우에는idleTimeout값은 의미가 없어서 무시된다.
java/database/hikaricp.1628225149.txt.gz · 마지막으로 수정됨: 2021/08/06 13:45 저자 kwon37xi
별도로 명시하지 않을 경우, 이 위키의 내용은 다음 라이선스에 따라 사용할 수 있습니다: CC Attribution-Share Alike 4.0 International
