벽보고 욕이라도 하자: 5월 2016

commonDBCP와 TomcatDBCP는 다르다

Parameter 자체가 비슷하기는 하지만 다르기 때문에 설정시 꼭 확인하고 적용해야 함

인터넷에서 일반적으로 DBCP라고 올라온 설정들은 대부분이 commonDBCP이나 섞여 있기 때문에

인터넷 내용은 설정을 이해 하는데 사용하고 실제 적용값은 반드시 공식 사이트에서 확인할 것

common DBCP 1.4 : https://commons.apache.org/proper/commons-dbcp/api-1.4/index.html
common DBCP 2.x : https://commons.apache.org/proper/commons-dbcp/configuration.html
tomcat DBCP 7 : https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html (tomcat 7 버젼 기준, 8버젼은 너님이 공부하세요 ㅋㅋㅋ)

또한 common DBCP는 V1.4 까지와 V2.0 이상에서 설정이 꽤나 다르므로 주의한다.

위 common DBCP 사이트 정보는 V2.0이상의 설정을 설명한다.

V1.4까지는 문서가 없고 JAVA Doc 문서를 참고해서 알아서 해야한다 (OSS의 아름다움... -.-;;)

tomcat에서 commonDBCP를 기반으로 성능을 개선해서 tomcat에 넣어둔 DB Pool을 Tomcat DBCP라고 부르고

결정적으로 commonDBCP는 Single Thread로 동작하여 20~30 TPS 넘는 사이트에서는 connection 성능 장애가 필수로 발생하나

tomcatDBCP는 MultiThread로 동작하여 성능문제는 일부 개선된다.

그래도 Enterprise WAS DBPool보다 성능이나 설정복잡도 부분에서 좋지 않다.
(tomcat DB Pool설정은 전문가 아니면 이해하기 너무 복잡하다)

설정값 참조
https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html

tomcat connection Pool 설정 sample과 설명을 달아본다.

<Resource auth="Container" driverClassName="com.edb.Driver"
name="jdbc/kwonDS"
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"

# 최대 100개 생성, 초기 50개 생성해서 제거되더라도 50개(생성), 더 만들어져도 50개(제거)로 유지되도록 설정
# 보통 성능때문에 100개 생성하면 100개 무조건 유지 하도록 설정하곤 하는데 이러한 경우 WAS의 적절한 DB Connection 사용지표확인이 어렵다.
# 지표 설정을 위해 초기에는 적당하게 initialSize 설정을 잡아서 갯수가 넘어가면 내 WAS의 적정한 Connection 사용수치를 확인하도록 하고
# 확실히 안정상태의 갯수가 확인되면 그 값으로 MaxActive로 WAS에서 처리하는 수준을 Fix하도록 한다.
# 의견이 분분한데 OverSize는 결국 DB에 불필요한 Connection 부하를 주기 때문에 튜닝값은 운영자가 지표모니터링을 통하여 설정해야만 한다.
# WAS Thread가 꽉차고 connection이 100개 이상 사용된다면 이미 장애상태이다. 이걸 더 늘리면 WAS장애를 DB장애 까지 확장시키게된다.
# WAS 엔지니어는 DB를 보호하기 위한 목적으로 튜닝을 적절히 통제하는 미덕(?)이 필요하다.
# WAS는 문제 생기면 내렸다 올리면 되지만 DB는 맛이 가면 여럿이 힘들다....

#def : 100
maxActive="100"
#def : 10
initialSize="50"
#def : maxActive
maxIdle="50"
#def : initialSize
minIdle="50"

#simple config)
#maxActive="50"
#initialSize="50"

# 사용자가 getConnection 한 이후 대기 시간, def: 30000 (30 seconds)
# connection 부족시 대기하는 시간과 관련 있음,
# 이 값이 너무 길면 이미 connection 부족증상임에도 사용자가 과도하게 대기 하는 증상이 발생하여 오히려 좋지 않음,
# 사용자가 기다려 줄 수 있는 시간 이상으로 설정하면 오히려 좋지 않고
# 너무 짧으면 불필요한 오류가 발생됨 (Eviction작업 시간이 오래 걸리거나, WAS Full GC등)
# 일반적으로 값을 5~10 초 정도로 줄이는 것이 좋음, 밀리면 그냥 에러내고 튕겨내는게 버티기에라도 도움이 된다.
# 개인취향으로는 5초까지 줄이기도 하지만 WAS Full GC가 종종 걸려서 끊어지는 경우가 있어서 보수적으로 10초 정도 합니다.(GC튜닝필요!)
` # 30초 --> 10초 (10000)
maxWait="10000"

# 정리 작업을 수행할 간격을 설정함 def : 5000 (5 seconds)
# 정리 작업은 나름 비용이 높은 작업이므로 특히나 commonDBCP에서 너무 빈번하게 수행하면 성능저하의 위험이있다
# tomcatDBCP는 이 부분을 개선해서 꽤날 짧은 시간단위로 수행(기본 5초)한다.
# 너무 하지 않으면 혹시 발생하는 잘못된 커넥션이 정리되지 못하는 경우가 있음
# 일반적으로 오염된 커넥션이 만들어지는 경우가 흔하지 않고 발생하더라도 근본 원인을 해결하는 것이 권장됨
# commonDBCP는 기본 비활성(-1)
# tomcatDBCP는 기본 활성(5000) <== tomcat의 자신감!!! 5초!
#
# tomcatDBCP에서는 이 값이 너무 짧은 경우 testWhileIdl이 true인 경우
# DB에 너무 많은 select sql이 전달 되므로 적절히 늘리는게 좋다. (저는 개인 취향으로 60초 정도 합니다.)
#
# WAS/DB사이에 방화벽 정책이 있는 경우라면 F/W에서 idle상태의 TCP를 끊어버릴 수 도 있는데
# 이 경우 이 값을 F/W Timeout보다 짧게 설정하여 수행하고 그때 testWhileIdle 설정을 사용하여 끊어지지 않도록 설정할 수 있다.
timeBetweenEvictionRunsMillis="60000"

# common DBCP에서 한번에 정리 작업대상으로 체크할 커넥션 수
# Eviction(정리) 작업은 비용이 높은 작업이다. 별도의 Thread가 구동되어 작업하고
# 특히나 이 작업시간동안 DB Pool에 Lock이 걸린다. (getConnection하면 먹통됨) 너무 크게 하면 안됨
# tomcatDBCP는 이 설정을 쓰지 않는다.
# numTestsPerEvictionRun=

# 정리작업 수행시 설정값 보다 오랜시간 Idel로 판단되면 해당 Connection을 회수한다 default : 60000 (60 seconds)
# 자원회수를 목적으로 설정하므로 생성된 connection이 정리되지 않기 원한다면 이 값을 -1로 설정한다.
minEvictableIdleTimeMillis="-1"

# connection 대여시에 SQL로 connection 검증함 def : false
# APP에서 getConnection할때 connection을 확인해서 제공함, 성능은 조금 떨어질 수 있음
# connection의 안정성이 개선이 되지않을때 설정을 하기는 하지만 평소에 이정도로 체크 하지 않는다.
# 이 설정을 켜서 문제가 해결된다면 방화벽이나 중간단계에서 끊어지거나 DB의 Timeout값을 확인해 보고
# 그 값보다 짧은 간격으로 testwhiledIdle이 수행되도록 하는것을 권장
testOnBorrow="false"
# connect시 SQL을 수행해서 확인한다. def : false
# init시 또는 minIdle 등에 의해 connection이 생성될때 SQL까지 날려본다. 이건 좀 오바다 싶습니다.
testOnConnect="false"

# 보통 이 설정으로 connection 검증을 몰아서 처리하는 것을 권장함, 이런저럭 설정을 섞으면 복잡해지고 문제발생시 파악이 어렵
# def : false
# 활성화시 timeBetweenEvictionRunsMillis 간격으로 수행되는 정리작업시 connection에 SQL을 보내서 확인을 하고 이상이 있으면 제거
# 이기능을 사용하면 DB timout, 방화벽 timeout, APP의 잘못된 connection 제어 등에 의한 문제를 회피할 수 있다.
# 쿼리는 timeBetweenEvictionRunsMillis 에 의해 eviction thread가 수행될 때 동작되므로 상관관계를 고려한다.
# 이 설정(test관련 모든 설정)은 아래 validationQuery 나 validatorClassName 를 설정하지 않으면 동작을 안합니다.
testWhileIdle="true"

# val 쿼리는 DB마다 조금씩 다르지만 공통적인 사항은 select 쿼리만 (함수도 안됨) 허용한다. 이상한 쿼리 넣지 맙시다.
validationQuery="SELECT 1"

#상기 select로 제한된 쿼리외에 정말 나름의 쿼리를 수행하고 싶은 경우 was에서 제공하는 인터페이스를 사용하여 checker를 만들수 있다
#org.apache.tomcat.jdbc.pool.Validator interface를 구현해서 등록할 수 있는데 어지간한 상황아니면 쓰지 않는다.
#JBoss 와 같은 Enterprise WAS에서는 DB마다 적절한 checker class를 미리 만들어서 제공한다
#commonDBCP에는 없고 tomcatDBCP는 지원한다. (Enterprise WAS는 지원함)
#각 WAS에서제공하는 interface를 구현해야 하므로 일반적으로 잘 사용되지는 않는다.
#validatorClassName=

# 이상상태(오래 수행중인)시 제거 작업 활성화 default : false
removeAbandoned="false"
# 정리작업수행시 커넥션이 설정시간 이상 수행상태이면 제거함(수행시간 기준으로 무조건 끊어짐) default : 60(60 Sec)
# APP에서 수행하는 SQL중 가장 오래 수행되는 SQL을 추정하여 그 값 이상으로 설정해야 함
# 빨리 정리하겠다고 너무 짧으면 그저 시간이 좀 더 걸리는 정상적인 처리도 끊어질 수 있음
# 이 기능은 일반적으로 수행하지 않는다.(문제가 발생해도 확인이 안됨, SQL튜닝이 근본원인 해결)
removeAbandonedTimeout="180"

# 기본 비활성상태이지만 활성화 한 경우 문제가 있어도 확인이 안되는경우가 있으므로
# 로그를 남겨서 시간이 넘어가서 끊어지는 내용을 남기도록 로그를 설정한다
logAbandoned="false"

username="yckwon"
password="XXXXX"
type="javax.sql.DataSource"
url="jdbc:edb://192.168.0.100:xxx/kwonDB" />

.이상

벽보고 욕이라도 하자

2016년 5월 8일 일요일

tomcat DBCP 설정과 commonDBCP일부 내용

2016년 5월 3일 화요일

PICASA(피카사)사 사라졌다 Orz ㅠ.ㅠ

FeedBurner FeedCount

통계(whos.amung.us)