Print
카테고리: [ Web Application Server ]
조회수: 11431

1. 개요

성능이나 장애에 영향을 주는 WebLogic DB 연결 관련 설정이다.


2. 설정

2-1. Seconds to Trust an Idle Pool Connection

The number of seconds within the use of a pooled connection that WebLogic Server trusts that the connection is still viable and will skip connection testing.

If an application requests a connection within the time specified since the connection was tested or successfully used and returned to the connection pool, WebLogic Server skips the connection test before delivering it to an application (if TestConnectionsOnReserve is enabled).

WebLogic Server also skips the automatic refresh connection test if the connection was successfully used and returned to the connection pool within the time specified (if TestFrequencySeconds is specified).

This attribute is a tuning feature that can improve application performance by minimizing the delay caused by database connection testing, especially during heavy traffic. However, it can reduce the effectiveness of connection testing, especially if the value is set too high. The appropriate value depends on your environment and the likelihood that a connection will become defunct.

2-2. Test Frequency

특히 WAS와 DB 사이에 방화벽이 있을 때 주로 사용한다. (그 이유는 방화벽 Timeout에 의하여 DB Connection이 끊어질 수 있음)

The number of seconds between database connection tests. After every TestFrequencySeconds interval, unused database connections are tested using TestTableName. Connections that do not pass the test will be closed and reopened to re-establish a valid physical database connection. If the test fails again, the connection is closed.

If TestTableName is not set, the test will not be performed.

If set to 0 (the default), connections are not tested.

MBean: weblogic.management.configuration.JDBCConnectionPoolMBean

Attribute: TestFrequencySeconds

2-3. Connection Creation Retry Frequency

The number of seconds between attempts to create database connections when the connection pool is created. If you do not set this value, connection pool creation fails if the database is unavailable. If set and if the database is unavailable when the connection pool is created, WebLogic Server will attempt to create connections in the pool again after the number of seconds you specify, and will continue to attempt to create the connections until it succeeds. When set to 0 (the default), this feature is disabled.

MBean: weblogic.management.configuration.JDBCConnectionPoolMBean

Attribute: ConnectionCreationRetryFrequencySeconds

2-4. oracle.net.CONNECT_TIMEOUT

2-5. Statement Cache Size

The Statement Cache Size attribute determines the total number of prepared and callable statements to cache for each connection in each instance of the data source. By caching statements, you can increase your system performance. However, you must consider how your DBMS handles open prepared and callable statements. In many cases, the DBMS will maintain a cursor for each open statement. This applies to prepared and callable statements in the statement cache. If you cache too many statements, you may exceed the limit of open cursors on your database server.

For example, if you have a data source with 10 connections deployed on 2 servers, if you set the Statement Cache Size to 10 (the default), you may open 200 (10 x 2 x 10) cursors on your database server for the cached statements.

내용을 잘 보면 each connection 당 캐시되는 수이다. WebLogic Global의 캐시 제한 숫자가 아니다.

또 주의할 점이 있는데,

이와 유사하게 JEUS에도 설정이 있다.

Stmt Caching Size

JDBC 드라이버는 애플리케이션에서 PreparedStatement 를 요청할 때마다 파라미터로 넘어온 SQL 문장을 파싱하게 된다. 이 파싱 작업이 성능에 영향을 줄 수 있기 때문에 이를 피하기 위해서 JEUS 내부적으로 PreparedStatement 를 캐시하는 기능을 제공한다. 이 설정은 캐싱할 PreparedStatement 의 개수를 지정한다.

그런데 간혹 이 설정이 -1로 되어 있는 경우가 있다. 이는 캐싱 대상 PreparedStatement의 수가 무한대라는 것이다. 힙 메모리를 점유하여 OOM을 유발할 수 있으므로 반드시 적당한 수로 제한해야 한다.


3. 유형에 따른 접속 방식

3-1. non-RAC & non-XA

XA를 사용하지 않는 Multi Data Sources

 <url> jdbc : oracle : thin : @ lcqsol24 : 1521 : SNRAC1 </ url> 
 <driver-name> oracle.jdbc.OracleDriver </ driver-name>

3-2. non-RAC & XA

XA를 사용하는 Multi Data Source

<url> jdbc : oracle : thin : @ lcqsol24 : 1521 : SNRAC1 </ url> 
<driver-name> oracle.jdbc.xa.client.OracleXADataSource </ driver-name>

3-3. RAC & non-XA

XA를 사용하지 않는 Service 방식

driver-name="oracle.jdbc.OracleDriver"
url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=RAC1)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=Service_1)(INSTANCE_NAME=DB_02)))"

3-4. RAC & XA

XA를 사용하는 Service 방식

driver-name="oracle.jdbc.xa.client.OracleXADataSource"
url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=RAC1)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=Service1)(INSTANCE_NAME=DBase1)))"

3-5. RAC + XA 주의점

Oracle RAC는 XA 내의 모든 데이터베이스 작업을 동일한 Oracle 인스턴스로 라우팅해야한다. 따라서 로드 밸런싱 옵션은 OFF해야 한다.


4. CTF vs TAF

WebLogic에서 TAF 사용 시 이슈가 있다. 다음은 Oracle 홈페이지에서 발췌한 내용임.

Although Oracle RAC offers JDBC connect-time failover features, for most configurations, Oracle recommends using WebLogic JDBC multi data sources to handle failover instead. While connect-time failover does not provide the ability to pre-create connections to alternate RAC nodes, multi data sources have multiple connections available at all times to handle failover. For more information see Using Multi Data Sources with Oracle RAC.
Transparent Application Failover (TAF) is not supported for any WLS data source. TAF, as delivered via JDBC is currently not transparent. It is documented to affect some ongoing query results and PreparedStatements in unpredictable and unrecoverable ways. TAF JDBC requires specific recovery code at the application level and affects the integrity of statements that WebLogic might be caching.

5. GridLink Data Sources

그런데 GridLink라는 데이터 소스가 등장했다. 아마 WebLogic 12c 부터 나온 것 같은데, 이제까지 알아본 바에 의하면,

중요한 것은 WebLogic 문서 상에 CTF 방식이 Deprecated 되었다고 나온 것이다. (https://docs.oracle.com/cd/E24329_01/web.1211/e24367/connecttime.htm#JDBCA491)


6. WEB-WAS Plug-in 설정

사실 이 설정은 DB 연결 설정은 아니지만 고려해야 할 내용이기에 추가한다.

6-1. Idempotent

WebLogic Plug-in이 제공하는 설정으로 default는 ON으로 되어 있다. 이 설정은 WLIOTimeSecs 내에 서버가 응답하지 않으면 (READ_ERROR_FROM_SERVER) Failover 해서 처리하겠다는 것이다.

그런데 이 설정을 ON으로 하면 데이터 혹은 서비스가 이중으로 처리될 수 있으므로 설정에 주의해야 한다. 개인적으로는 OFF를 선호한다.

6-2. Timeout

WEB-WAS 제품 및 플러그인에 따라 다르겠지만 장기 수행 쿼리의 경우가 문제될 수 있다.

예를 들어 WAS-DB간 쿼리 타임아웃이 설정되어 있는데, WEB-WAS간 타임아웃(socket_time 등)이 그보다 더 작게 되어 있고, 이 타임아웃에 의해 retry되게 설정되어 있다면 중복 수행의 가능성이 존재한다.

6-3. Keepalive

WEB-WAS 플러그인 설정 시 Keepalive가 디폴트 false인 경우가 있다. (예를 들어 앞단이 prefork 방식의 Apache HTTP Server) 이러면 웹 서버 단에서 CLOSE_WAIT이 많이 발생할 수 있으므로 Keepalive 옵션 설정을 확인한다.

 


7. 기타 OS / Network 설정

7-1. TCP NODELAY

네트워크 통신 중 패킷 수를 줄이기 위해 Nagle 알고리즘을 적용하는 것에 대한 설정이다. OS 커널 파라미터 혹은 애플리케이션 Socket 옵션을 통해 설정한다.

응답시간이 중요한 시스템의 경우에는 오히려 부작용이 생길 수 있다. OS에 따라 다를 수 있겠는데 대부분 disable이다. NODELAY 설정을 enable하면 패킷당 크기는 줄어들지만 초당 패킷 수는 증가할 것이다.

7-2. Network


8. 진단 지표

8-1. 이중화

8-2. WAS-DB

8-3 설정

8-4 로그 및 모니터링