연결 풀 설정

이 페이지에서 연결 풀 설정을 구성할 수 있습니다.

이 관리 콘솔 페이지는 JDBC 데이터 소스 및 JMS 큐 연결 팩토리(통합, 큐 또는 토픽 연결 팩토리)에 공통입니다. 경로는 자원 유형에 종속되지만, 이 페이지를 보기 위해 일반적으로 자원 유형 인스턴스를 선택하고 연결 풀을 클릭하십시오. 예를 들어 다음과 같습니다.
문제점 방지 문제점 방지: 연결 풀링은 애플리케이션 클라이언트에서 지원되지 않습니다. 애플리케이션 클라이언트는 데이터베이스를 직접 호출하며 데이터 소스를 통해 이동하지 않습니다. 애플리케이션 클라이언트에서 getConnection() 요청을 사용하려면 Rational® Application Developer 또는 어셈블리 도구로 애플리케이션 클라이언트 배치 디스크립터에서 JDBC 제공자를 구성하십시오. 애플리케이션 클라이언트와 데이터베이스 사이에 연결이 설정됩니다. 애플리케이션 클라이언트에는 연결 풀이 없으나 클라이언트 배치 디스크립터에서 JDBC 제공자 설정을 구성할 수 있습니다. gotcha

연결 제한시간

이 간격 후에 연결 요청 제한시간이 초과되어 ConnectionWaitTimeoutException이 발생하는 간격(초)을 지정합니다.

이 값은 사용 가능한 풀에 사용 가능한 연결이 없고 새 연결을 작성할 수 없을 때 연결 요청이 대기하는 초 수를 표시합니다. 이는 보통 특정 연결 풀 내의 최대 연결 수에 도달했기 때문에 발생합니다.

예를 들어 연결 제한시간이 300으로 설정되고 최대 연결 수만큼 사용 중인 경우, 풀 관리자는 실제 연결이 사용 가능하게 될 때까지 300초 동안 기다립니다. 실제 연결이 해당 시간 안에 사용 가능하게 되지 않는 경우 풀 관리자는 ConnectionWaitTimeout 예외를 시작합니다. 대부분의 경우, getConnection() 메소드를 재시도해서는 안 됩니다. 더 오랜 대기 시간이 요구되는 경우, 연결 제한시간 설정값을 늘려야 합니다. 애플리케이션에서 ConnectionWaitTimeout 예외가 발생할 경우, 예상되는 애플리케이션의 연결 풀 사용을 검토하고 연결 풀 및 데이터베이스를 적절히 조정하십시오.

연결 제한시간이 0으로 설정되면, 풀 관리자는 연결이 사용 가능하게 될 때까지 필요한 만큼 기다립니다. 이러한 상황은 애플리케이션이 트랜잭션을 완료하고 풀에 연결을 리턴하거나, 연결 수가 최대 연결 수 미만이고 새 실제 연결이 작성되는 경우에 발생합니다.

최대 연결 수가 0으로 설정되면, 무한 개수의 실제 연결이 사용 가능하며 연결 제한시간 값은 무시됩니다.

정보
데이터 유형 Integer
단위
기본값 180
범위 0 - 최대 정수

최대 연결 수

이 풀에 작성할 수 있는 실제 연결의 최대 수를 지정하십시오.

이들은 백엔드 자원에 대한 실제 연결입니다. 이 수에 도달하면, 새 실제 접속이 작성되지 않습니다. 요청자는 현재 사용 중인 실제 접속이 풀로 리턴되거나 ConnectionWaitTimeoutException 오류가 표시될 때까지 대기합니다. 예를 들어 최대 연결 수 값이 5로 설정되고 실제 연결 5건을 사용 중이면, 풀 관리자는 실제 연결의 연결 제한시간으로 지정한 시간만큼 대기합니다.

잠재적으로 백엔드(예: DB2® 데이터베이스 또는 CICS® 서버)에서 연결을 요청할 수 있는 연결 풀의 수를 아는 것이 최대 연결 수 특성에 대한 값을 결정하는 데 도움이 됩니다.

[AIX Solaris HP-UX Linux Windows][IBM i] 동일한 데이터 소스 구성 또는 J2C 연결 팩토리 구성을 사용하는 다중 독립형 애플리케이션 서버의 경우, 각 서버에 대해 별도의 실제 연결 풀이 존재합니다. 이러한 동일한 애플리케이션 서버를 복제하는 경우, WebSphere Application Server(기본)가 각 복제본에 대해 별도의 연결 풀을 구현합니다.

[z/OS] 동일한 자원에 액세스하는 하위(servant) 수를 고려하십시오. 런타임 시에 이 수가 필수적으로 최대 연결 수 설정을 곱합니다. 하위(servant)가 동일한 JDBC 데이터 소스 또는 J2C 연결 팩토리 구성을 시작하는 경우, WebSphere Application Server(기본)가 모든 하위(servant)에 해당되는 실제 연결 풀을 구현합니다. 따라서 동일한 연결 풀이 각 하위(servant)에 독립적으로 존재합니다. 최대 연결 수 설정은 해당 풀 중 하나에 각각 적용됩니다.

[AIX Solaris HP-UX Linux Windows][IBM i] 이러한 연결 풀은 모두 동일한 데이터 소스 또는 연결 팩토리 구성에 해당됩니다. 따라서 이러한 연결 풀은 모두 잠재적으로 동시에 동일한 백엔드 자원에서 연결을 요청할 수 있습니다. 이 콘솔 패널에 설정할 수 있는 단일 최대 연결 수 값은 해당 연결 풀 모두에 적용됩니다. 결론적으로 높은 최대 연결 수 값을 설정하면 백엔드 자원을 초과하는 연결 요청이 로드될 수 있습니다.

[z/OS] 잠재적으로 해당 하위(servant) 내에서 데이터소스 또는 연결 팩토리가 필요한 모든 애플리케이션이 동시에 자원을 사용하려고 시도할 수 있습니다. 따라서 해당되는 연결 풀은 동시에 동일한 백엔드에서 연결을 요청할 수 있습니다. 데이터베이스 또는 기타 엔터프라이즈 정보 시스템(EIS)을 초과하는 연결 요청 로드를 발생시킬 수 있는 최대 연결 수 값을 설정하지 마십시오.

정보
데이터 유형 Integer
기본값 10
범위 0 - 최대 정수

최대 연결 수가 0으로 설정되면, 연결 제한시간 값이 무시됩니다.

팁: 성능을 개선하려면 연결 풀 값을 웹 컨테이너의 최대 스레드 풀 연결 값보다 낮게 설정하십시오. 이 설정을 구성하려면, 서버 > 서버 유형 > WebSphere Application Sever > server > 스레드 풀을 클릭하고 웹 컨테이너 특성을 수정하십시오. 설정 값이 낮으면(예: 연결 10-30건)이 설정 값이 높을 때(예: 100)보다 성능이 더 좋습니다.

Tivoli® Performance Viewer를 사용하여 풀에서 최적 연결 수를 찾을 수 있습니다. 동시 대기자 수가 0보다 크지만, 프로세서 로드가 100%에 가깝지 않으면 연결 풀 크기 증가를 고려하십시오. 사용률이 보통 워크로드보다 계속 낮으면, 풀의 연결 수를 줄이는 것이 좋습니다.

최소 연결 수

유지보수해야 하는 실제 최소 연결 수를 지정합니다.

연결 풀의 크기가 최소 연결 풀 크기 이하일 경우, 미사용 제한시간 스레드는 실제 연결을 버리지 않습니다. 그러나 풀은 단지 최소 연결 풀 크기가 유지되도록 하기 위해 연결을 작성하지 않습니다. 또한 유효 제한시간의 값을 설정한 경우, 최소 풀 크기 설정에 관계 없이 기간이 만기된 연결이 버려집니다.

예를 들어 최소 연결 값을 3으로 설정하고 실제 연결을 하나 작성하면, 미사용 제한시간 스레드는 이 연결을 버리지 않습니다. 동일한 토큰에 의해 스레드는 최소 연결 수 설정에 도달하기 위해 두 개의 추가 실제 연결을 자동으로 작성하지 않습니다.

정보
데이터 유형 Integer
기본값 1
범위 0 - 최대 정수

Reap 시간

풀 유지보수 스레드 실행 사이의 간격(초)을 지정합니다.

예를 들어 Reap 시간이 60으로 설정되는 경우 풀 유지보수 스레드는 60초마다 실행합니다. Reap 시간 간격은 미사용 제한시간 및 유효 제한시간 설정의 정확성에 영향을 미칩니다. 간격이 작을수록 정확성은 더 큽니다. 풀 유지보수 스레드가 사용 가능한 경우, Reap 시간을 미사용 제한시간 및 유효 제한시간보다 작게 설정해야 합니다. 풀 유지보수 스레드가 실행할 때, 풀 유지보수 스레드는 미사용 제한시간에 지정된 시간 값보다 길게 사용되지 않은 기존의 모든 연결을 최소 연결 수에 지정된 연결 수에 도달할 때까지 버립니다. 또한 풀 유지보수 스레드는 유효 제한시간에 지정된 시간 값보다 오래 동안 활성 상태인 모든 연결을 버립니다.

Reap 시간 간격은 또한 성능에 영향을 줍니다. 더 작은 간격은 풀 유지보수 스레드가 더 자주 실행하여 성능이 떨어진다는 것을 의미합니다.

풀 유지보수 스레드를 사용 불가능하게 하려면, Reap 시간을 0으로 설정하거나 미사용 제한시간 및 유효 제한시간을 모두 0으로 설정하십시오. 풀 유지보수 스레드를 사용 불가능하게 하는 방법은 Reap 시간을 0으로 설정하는 것으로서, 이 경우 미사용 제한시간 및 유효 제한시간이 무시됩니다. 그러나 미사용 제한시간 및 유효 제한시간을 0으로 설정하는 경우 풀 유지보수 스레드가 실행됩니다. 0이 아닌 제한시간 값으로 인해 제한시간이 초과되는 실제 연결 뿐만 아니라 사용된 풀(또는 공유된 풀)에 있는 해당 연결이 버려집니다. 유휴 제한시간에 설정된 시간 간격보다 더 오래 보유되었기 때문입니다.

정보
데이터 유형 Integer
단위
기본값 180
범위 0 - 최대 정수

미사용 제한시간

지정된 시간 후에 사용되지 않거나 대기 중인 연결이 버려지는 초 단위의 간격을 지정합니다.

최적의 성능을 위해 Reap 제한시간 값보다 높은 미사용 제한시간 값을 설정하십시오. 사용되지 않은 실제 연결은 현재 연결 수가 최소 연결 설정을 초과하는 경우에만 버려집니다. 예를 들어 미사용 제한시간 값을 120으로 설정하고 풀 유지보수 스레드가 사용 가능한 경우(Reap 시간이 0이 아님), 2분 동안 사용되지 않은 모든 실제 연결이 버려집니다.

이 제한시간의 정확성 및 성능은 Reap 시간 값의 영향을 받습니다. 자세한 정보는 Reap 시간의 내용을 참조하십시오.

정보
데이터 유형 Integer
단위
기본값 1800
범위 0 - 최대 정수

유효 제한시간

실제 연결이 버려지기 전의 초 단위의 간격을 지정합니다.

유효 제한시간을 0으로 설정하면 활성 상태인 실제 연결이 풀에 무기한으로 남아 있도록 지원합니다. 최적의 성능을 위해 Reap 제한시간 값보다 높은 유효 제한시간 값을 설정하십시오.

예를 들어 유효 제한시간 값이 1200으로 설정되고 Reap 시간 값이 0이 아닌 경우, 1200초(20분) 동안 존재한 실제 연결은 풀에서 버려집니다. 유일한 예외는 유효 제한시간에 도달했을 때 연결이 트랜잭션에 관련되어 있는 경우입니다. 트랜잭션이 완료되어 연결이 닫히기 전에는 애플리케이션 서버에서 해당 연결을 버리지 않습니다.

이 제한시간의 정확성 및 성능은 Reap 시간 값의 영향을 받습니다. 자세한 정보는 Reap 시간의 내용을 참조하십시오.

정보
데이터 유형 Integer
단위
기본값 0
범위 0 - 최대 정수

제거 정책

무효 연결 또는 치명적 연결 오류가 발견될 때 연결을 제거하는 방법을 지정합니다.

올바른 값은 EntirePoolFailingConnectionOnly입니다.

정보
데이터 유형 String
기본값
  • J2C 연결 팩토리 및 JMS 관련 연결 팩토리에 대한 EntirePool
  • WebSphere 버전 4.0 데이터 소스에 대한 EntirePool
  • 관리 콘솔을 통해 작성한 현재 버전의 데이터소스에 대한 EntirePool
  • WebSphere Application Server에 빌드된 JDBC 템플리트를 시작하는 wsadmin AdminConfig 명령을 통해 스크립트한 현재 버전 데이터 소스에 대한 EntirePool. createUsingTemplate 명령에 대한 정보는 "AdminConfig 오브젝트에 대한 명령" 주제를 참조하십시오.
  • JDBC 템플리트를 시작하지 않고 wsadmin 도구에서 스크립트한 데이터 소스용 FailingConnectionOnly
:
범위
EntirePool
풀 내의 모든 연결이 무효로 표시됩니다. 사용 중이 아닌 연결은 즉시 닫힙니다. 사용 중인 연결은 닫히고 해당 연결의 다음 조작 동안 무효 연결 예외가 발행됩니다. 애플리케이션에서 후속 getConnection() 요청은 데이터베이스 열기에 대한 새 연결의 결과를 초래하였습니다. 이 제거 정책을 사용할 경우 풀의 일부 연결이 무효화 상태가 아닐 때 불필요하게 닫힐 수도 있습니다. 그러나 이 닫기는 거의 발생하지 않습니다. 대부분의 경우, EntirePool의 제거 정책이 최상의 선택입니다.
FailingConnectionOnly
무효 연결 예외가 발생한 연결만이 닫힙니다. 이 설정은 유효한 연결이 불필요하게 닫힐 가능성은 제거하나 좀더 복잡한 애플리케이션 Perspective로부터 복구됩니다. 현재는 실패한 연결만 닫히기 때문에, 애플리케이션으로부터 다음 getConnection() 요청이 무효 풀에서 연결을 리턴할 수도 있습니다. 그 결과 더 많은 무효 연결 예외 결과를 발생시킵니다.

연결 사전 테스트 기능은 애플리케이션을 유효하지 않은 풀 연결로부터 고립시키려고 시도합니다. 데이터베이스와 같은 백엔드 자원이 다운되면, 유효하지 않은 풀 연결이 사용 가능한 풀에 있을 수 있습니다. 특히, 제거 정책이 failingConnectionOnly인 경우에 그렇습니다. 이 경우 실패 연결은 풀에서 제거됩니다. 실패한 경우 풀에 있는 나머지 연결도 유효하지 않을 수 있습니다.



파일 이름: udat_conpoolset.html