다중 쓰레드 서버
다중 쓰레드 기본 구조는 여러 사용자 프로세스가 한정된 수의 서버를 공유할 수
있도록 하는 것입니다. 전용서버 환경에서, 각 사용자 프로세스는 한 서버 프로세스에 할당됩니다.
이 서버 프로세스는 유휴시간과 비활동으로 인하여 사용자 프로세스에 의해 완전히 이용되지 않을 것입니다. 그러나, 이 서버 프로세스를 할당하면 메모리와 CPU 자원을 소모하게 될 것입니다.
다중 쓰레드 서버를 사용할 때, 사용자 프로세스들은 서버 프로세스에 동적으로 할당되며, 이 서버 프로세스는 많은 사용자 프로세스들 간에 공유됩니다. 디스패처 프로세스는 사용자 프로세스의 요청을 받아, 요청 큐에 놓습니다. 그러면, 공유 서버는 그 요청을 처리한 다음 결과를 디스패처의 응답 큐로 다시 보냅니다. 디스패처 프로세스는 결과가 응답 큐에 놓인 후 사용자에게 결과를 돌려줍니다.
좋은 예가 오라클 교육과정 등록을 위한 예약 프로세스입니다. 고객은 전화를 하여 예약에 관하여 문의합니다. 예약 상담원은 화면을 통해 등록할 수 있는 교육과정을 질의할 수 있지만, 먼저 고객과 잠깐동안 대화를 나눌 필요가 있습니다. 그런 다음, 질의 내역은 데이터베이스로 보내지고, 상담원과 고객과의 본격적인 대화가 끝난 후, 고객은 예약할 과정을 결정하고 상담원은 예약을 완료합니다. 따라서, 10분간의 대화 동안, 전용 서버는 전체 시간 99% 간 유휴상태에 있게 됩니다
|
Oracle8에서, 다중 쓰레드 서버는 Connection Manager와 Connection Pooling의 형태로 사용자 연결을 위한 멀티플렉싱(multiplexing)과 풀링(pooling) 기능을 지원합니다. MTS를 사용하지 않을 경우, 표준 유닉스 시스템 또는 원격 클라이언트에서 연결되는 각 사용자는 Oracle8 서버 파일과 메모리 구조에 액세스하기 위해 전용 서버 프로세스가 필요합니다. 사용자가 많은 시간을 고객과의 대화에 소요해야 하는 대화식 애플리케이션에서, 이들 전용서버는 주로 유휴상태에 있게 되며, 사용자가 데이터베이스에 질의나 변경사항을 전송할 때에만 작업을 합니다. MTS를 사용할 경우에는, 여러 사용자는 Oracle8서버에 액세스하는 디스패처 프로세스를 공유할 수 있습니다. Oracle8은 공유 서버를 사용하여 디스패처에 의해 전달되는 SQL 문을 처리합니다. MTS는 다음에 유용합니다:
데이터베이스 집중적인 작업에 공유 서버를 사용하는 것은 이익이 되지 않습니다. 과중한 작업이나 배치 작업을 수행하는 사용자는 전용 서버를 사용해야 합니다. |
MTS 사용
Net8을 설치하거나 구성하지 않았다면 MTS를 사용할 수 없습니다. 구성 사항은 본 교육 과정에 포함되어 있지
않지만(구성 사항은 Oracle8: 네트워크 관리 과정에서 다루어질 것입니다), 서버 기계에 적어도 다음 2개의 파일은 있어야 한다는 것을
의미합니다.
|
파일명 |
내용 |
|
listner.ora |
리스너 주소와 리스너 주소가 연결할 수 있는 인스턴스 |
|
tnsnames.ora |
각 인스턴스에 대한 별칭 - 사용가능한 연결 지정 |
초기화 파라미터
|
파라미터 |
값 |
|
MTS_LISTENER_ADDRESS |
listener.ora에 지정되어 있는 것과 같은 주소 |
|
MTS_SERVICE |
tnsnames.ora의 CONNECT_DATA 절에 있는 SID 키워드의 값 |
|
MTS_SERVERS |
공유 서버의 초기 숫자 |
|
MTS_DISPATCHERS |
“protocol, number_of_dispatchers” |
|
MTS_MAX_SERVERS |
선택가능 - 최대 서버 프로세스 수 |
|
MTS_MAX_DISPATCHERS |
선택가능 - 최대 디스패처 프로세스 수 |
파라미터 값의 예
MTS_LISTENER_ADDRESS =
“(ADDRESS = (PROTOCOL = ipc)
(KEY = NF7T1))”
MTS_SERVICE = NF7T1
MTS_SERVERS = 4
MTS_DISPATCHERS = “ipc,4”
MTS_MAX_SERVERS = 20
MTS_MAX_DISPATCHERS = 20
디스패처 사용을 위한 경합 식별
V$MTS 뷰의 MAXIMUM_CONNECTIONS 열에서 단일 디스패처를 통해 연결할 수 있는 최대 사용자 수를 찾을 수 있습니다. (SESSION이 디스패처에 대한 실제 한계값 보다 작게
설정되었을 경우, 디폴트는 SESSION 파라미터의 값이 됩니다.)
또한, V$DISPATCHER 뷰를 질의하여 선택된 디스패처 프로세스의 사용도를 결정할 수
있습니다. 다음을 검사하여 디스패처
경합을 식별할 수 있습니다:
위의 예에서 질의는 각 프로토콜의 디스패처 프로세스에 대한 총 사용율을 반환합니다. 즉, 이 사용율은 각 프로토콜의 디스패처 프로세스가 사용 중인 시간의 퍼센트를 나타냅니다. 이 질의의 결과는 다음과 같을 것입니다:
Protocol Total Busy Rate
--------
---------------
decnet .004589828
tcp .29111042
값이 0.5라는 것은 디스패처가 총 시간 중 50% 사용되었다는 것을 의미합니다. 이 값은 너무 높은 것이기 때문에, 더 많은 디스패처를 추가할 필요가 있을 것입니다.
디스패처 대기 여부 검사
다음 질의를 실행하여 사용자가 디스패처를 기다리고 있는지의 여부를 검사할 수
있습니다:
SELECT DECODE (SUM(totalq), 0, ‘No
Responses’,
SUM(wait) / SUM (totalq) “Average wait time”
FROM
v$queue q, v$dispatcher d
WHERE q.type = ‘DISPATCHER’
AND
q.paddr = d.paddr;
결과의 답은 100분의 1초로 표현됩니다. 값이 꾸준하게 증가하고 있다면 문제가 있다는 것입니다. 사용자는 질의를 두 번 이상 실행 시킬 때 대기 시간이 증가하는 것 같은 경우에 한번에 더 많은 디스패처를 시작시키기를 원할 것입니다.
예
디스패처를 추가하거나 삭제하기 위해서는 다음 명령을 사용하십시오:
ALTER SYSTEM SET mts_dispatchers =
‘protocol, number’;
사용자들은 로그오프하기 까지는 동일한 디스패처에 연결되어 있기 때문에 더 많은 디스패처를 추가하더라도 즉시 효과가 나타나지는 않을 것입니다. 새로 연결할 때에만 새로운 디스패처를 사용할 수 있습니다.
Performance Manager
디스패처 및 큐와 관련된 성능을 진단할 대에는 사전 정의된
차트, DISTPATCHER, QUEUE를 사용할 수 있습니다.
Performance Manager ->
Contention -> 디스패처
Performance Manager -> Contention -> 큐
서비스 감시
필요한 공유 서버의 수를 적게 산정하였을 경우, Oracle8 서버는 동적으로 더 많은
공유서버를 시작시킵니다. 여분의 서버는 유휴상태가 되면 다시 제거됩니다. 이것은 디스패처보다 서버를 감시할 필요가 더
적다는 것을 의미합니다.
그러나, 필요한 것보다 더 많은 공유 서버가 시작될 것입니다. 파라미터 파일의 MTS_SERVERS에
대해 값을 지정하면, Oracle8 서버는 프로세스가 유휴(idle) 상태이더라도 이들 프로세스를 제거하지 않기 때문에, 사용자는 로드를
검사해야 할 것입니다.
또한 서버의 수가 MTS_MAX_SERVERS의 값에 가까워지고 있는지 또는 프로세스의 수가
PROCESSES 파라미터의 값에 가까워지고 있는 지 여부를 알고자 할 것입니다. 다음 명령을 사용하여 공유 서버를 제거하십시오:
ALTER SYSTEM SET MTS_SERVERS = number;
다음 질의를 실행시켜 현재 실행되고 있는 공유 서버 프로세스의 수를 결정하십시오:
SELECT COUNT(*) “Shared Server Processes”
FROM v$shared_server
WHERE status != ‘QUIT’;
이 질의의 결과는 다음과 같을 것입니다:
Shared Server
Processes
-----------------------
10
V$QUEUE 동적인 성능 뷰의 WAIT 과 TOTALQ 열을 질의하여 공유 서버 프로세스에 경합이 있는지 여부를 결정할 수 있습니다. 애플리케이션이 실행되고 있는 동안 가끔 이들 통계를 감시하십시오:
SELECT DECODE ( totalq, 0, ‘No Requests’,
Wait/totalq || ‘hundredths of seconds’)
“Average Wait Time Per
Requests”
FROM v$queue
WHERE type = ‘COMMON’;
이 질의는 요청 큐에 대한 총 요청 수와 모든 요청에 대한 총 대기 시간을 반환합니다. 이 질의의 결과는 다음과 같을 것입니다:
Average Wait Time per Request
-----------------------------
.090909 hundredths of seconds
Performance Manager
사용자 프로세스와 관련된 성능을 진단할 때에는 사전 정의된
차트, SHARED SERVER를 사용할 수 있습니다.
Performance Manager -> Contention -> 디스패처
Performance
Manager -> Contention -> 큐
공유 연결 검사
사용자에게 문제가 있을 경우, 또는 프로세스가 너무 많은 작업을 하는 것 같을
경우에는, 공유 연결로 작업하는 현재의 사용자들을 검사해 볼 필요가 있습니다.
다음을 사용하여 현재의 디스패처와 서버를 질의할 수
있습니다:
이들은 서버 및 디스패처 이름과 사용자의 세션 id 및 시리얼 id를 제공합니다.
USERNAME 열에 해당되는
값에 대해 V$SESSION이나 ‘세션 감시’ 화면을 검사할 필요가 있습니다.
Performance Manager
사용자 프로세스와 관련된 성능을 진단할 때에는 사전 정의된
차트인 CIRCUIT을 사용할 수 있습니다.
Performance Manager -> Contention -> Circuit
검색 서버에 MTS 사용
MTS를 사용하기로 결정할 경우, Oracle8서버가 다른 방법으로 사용자
메모리 영역에 보관하는 일부 정보는 대신 공유
풀로 가야합니다. 이 사용자 글로벌 영역은 앞의 “공유 풀 튜닝” 장에서 설명되었습니다.
MTS를 사용하여도 시스템에 필요한 전체 메모리는 여전히 감소시켜야 합니다. 공유 풀의 메모리를 증가시키면 사용자 고유 메모리 요구가 줄어들기 때문입니다.
공유 서버는 정렬 작업을 위해 UGA를 사용합니다. 따라서, MTS를 사용하고 있을 경우, SORT_AREA_RETAINED_SIZE를 SORT_AREA_SIZE 값보다 작게 설정해야 할 것입니다. 그래야 메모리가 가능한 한 빨리 다른 사용자가 사용할 수 있도록 해제될 것입니다.
라지 풀(Large Pool)
MTS와 라지 풀
문제해결
다중 쓰레드 서버 환경에서 문제를 해결하는 것은 핵심 DBA 기능입니다. 일반적으로 발생할
수 있는 문제는 다음과 같습니다:
동적인 성능 뷰 사용
여러 다른 동적인 성능 뷰를 사용하여 다중 쓰레드 서버 환경에 관한 정보를
입수할 수 있습니다. Oracle8 참조 설명서를 사용하여 각 뷰에 관한 상세 사항을 얻으십시오.
|
문맥 |
참조 |
|
파라미터 |
MTS_LISTENER_ADDRESS |
|
동적 성능 뷰 |
V$CIRCUIT |
|
데이터 딕셔너리 뷰 |
NONE |
|
명령어 |
ALTER SYSTEM SET MTS_SERVERS |
|
프로시저 |
NONE |
|
진단팩 어플리케이션 |
Performance manager |