[오라클]네트워크 튜닝 – 프로세스의 경합

2 단계 : 프로세스의 경합

공유 서버 프로세스     하나의 사용자 프로세스마다 하나씩 할당되는 서버 프로세스를 전용서버 프로세스라고 한다면 여러 개의 사용자 프로세스에게 하나의 서버 프로세스가 할당되는 환경을 공유서버 프로세스라고 합니다. 일반적으로, 전용서버 프로세스는 마감작업, 통계 분석작업, 전산관리 업무 등과 같은 배치성 작업이나 데이터베이스의 유지보수 작업(STARTUP, SHUTDOWN, BACKUP & RECOVERY 작업)을 수행하는 사용자에게 적합하고 공유서버 프로세스는 간단한 입력, 수정, 삭제, 조회 등의 일상적인 작업처리 업무를 수행하는 사용자들에게 적합합니다. 만약, 마감작업을 처리하는 사용자가 공유서버 프로세스로 접속하여 SQL문을 처리한다면 작업 성능은 매우 늦어질 것입니다. 반대로, 한 건의 행을 입력하는 사용자가 전용서버로 접속하여 작업을 처리한다면 성능은 빨라지겠지만 메모리의 낭비가 될 것입니다. 오라클 데이터베이스를 설치하면 기본적인 모드는 전용서버 프로세스 환경입니다. 공유서버 프로세스를 사용하기 위해서는 별도의 환경설정이 필요하며, 환경설정 후에는 공유서버 프로세스와 전용서버 프로세스를 동시에 사용할 수 있습니다. 그럼, 공유서버 프로세스의 환경 설정하는 방법과 처리과정에 대해서 자세히 알아봅시다. 먼저, 공유서버 프로세스를 사용하기 위해서 필요한 기타 프로세스와 구조체를 알아봅시다. 위 그림에서 보시는 것처럼, 공유서버 프로세스(SHARED SERVER), 리스너 프로세스(LISTEN ER1), 디스패쳐 프로세스(DISPATCHER1, DISPATCHER2, DISPATCHER3)가 필요하고 SGA 영역에는 요청 큐(REQUEST QUEUE), 응답 큐(RESPONSE QUEUE)가 필요합니다. 그럼, 각 프로세스와 구조체가 어떤 기능을 하는지 처리과정을 통해 알아보겠습니다.                     사용자가 리스너 프로세스에게 데이터베이스 접속을 요청합니다.         리스너 프로세스는 현재 활동 중인 디스패쳐 프로세스를 검사합니다.         분석된 디스패쳐 프로세스의 상태정보를 저장한 다음 그 중에 가장 적게 작업을 처리하는 디스패쳐 프로세스의 주소를 사용자에게 리턴해 줍니다.         사용자는 리스너 프로세스로부터 받은 디스패쳐 프로세스의 주소를 이용하여 해당 디스패쳐 프로세스에 접속한 다음 SQL문의 실행을 요구합니다.         디스패쳐 프로세스는 사용자의 요구사항(데이터베이스 접속, SQL문의 실행)을 요청 큐에 저장합니다.         공유서버 프로세스 중에 가장 적게 작업을 처리하고 있는 프로세스가 요청 큐로부터 사용자의 요구사항을 읽어옵니다.         공유서버 프로세스는 작업을 처리한 후 디스패쳐 프로세스가 활성화될 때 각각 만들진 해당 응답 큐에 작업결과를 저장합니다.         해당 디스패쳐 프로세스는 자신의 응답 큐로부터 결과를 읽어와서 ⑩ 사용자에게 리턴해 주면 모든 작업은 완료됩니다.         지금까지, 공유서버 프로세스를 통해 사용자의 작업이 어떻게 처리되는지 알아보았습니다. 이제부터, 각 프로세스를 활성화하기 위한 환경설정 방법을 알아보도록 하겠습니다. 이 프로세스들을 활성화하기 위해서는 INIT<DB명>.ORA 파일에 다음과 같은 파라메터를 추가하셔야 합니다.           $ cd $HOME/dbs $ vi init.ora   DISPATCHERS = "(PROTOCOL = TCP)(DISPATCHER = 3)" MAX_DISPATCHERS = 5 SHARED_SERVERS = 3 MAX_SHARED_SERVERS = 5 SHARED_SERVER_SESSIONS = 100   :wq!               [DISPATCHERS]에는 데이터베이스를 시작(STARTUP)했을 때 최초 할당될 디스패쳐 프로세스의 수와 프로토콜을 정의하십시오.(기본값은 5개입니다) [MAX_DISPATCHER]는 [MTS_DISPATCHERS] 파라메터에 의해 사용 중인 디스패쳐 프로세스들이 현재 접속한 모든 사용자들의 작업을 원활하게 처리해 줄 수 없을 때 지정한 개수만큼 추가적으로 디스패쳐 프로세스를 활성화 해줍니다. [SHARED_SERVERS]는 데이터베이스를 시작(STARTUP)했을 때 최초 할당될 공유서버 프로세스의 수를 정의하십시오. [MAX_SHARED_SERVERS]는 [MTS_SERVERS] 파라메터에 의해 사용 중인 공유서버 프로세스들이 현재 접속한 모든 사용자들의 작업을 원활하게 처리해 줄 수 없을 때 지정한 개수만큼 추가적으로 공유서버 프로세스를 활성화 해줍니다.(기본값은 20입니다.) [SHARED_SERVER_SESSIONS]는 할당된 전체 공유서버가 동시에 오픈할 수 있는 세션 수를 의미합니다. 공유서버 프로세스와 디스패쳐 프로세스에 대한 환경설정이 완료되었으면 데이터베이스를 재 시작해야 합니다. 그리고, 각 프로세스와 큐 구조들이 생성되었는지 확인해 보십시오. 먼저, V$SHARED_SERVERS 자료사전을 참조해 보면 MTS_SERVERS 파라메터에 의해 활성화 되어 있는 공유서버 프로세스를 확인할 수 있을 것입니다. 공유서버 프로세스의 이름은 S000부터 Snnn 형태로 생성됩니다.                         SQL> CONNECT system/manager SQL> SELECT name, status FROM v$shared_server;     NAME STATUS   --------------------   SOOO WAIT(COMMON) <- 첫번째 공유 서버 프로세스 SOO1 WAIT(COMMON) <- 두번째 공유 서버 프로세스 S002 WAIT(COMMON) <- 세번째 공유 서버 프로세스                 V$DISPATCHER 자료사전을 참조해 보면 MTS_DISPATCHERS 파라메터에 의해 활성화 되어있는 디스패쳐 프로세스들을 확인할 수 있을 것입니다. 디스패쳐 프로세스의 이름은 D000부터 Dnnn 형태로 생성됩니다.                             SQL> SELECT name, status FROM v$dispatcher;     NAME STATUS   --------------------   SOOO WAIT(COMMON) <- 첫번째 디스패쳐 프로세스 SOO1 WAIT(COMMON) <- 두번째 디스패쳐 프로세스 S002 WAIT(COMMON) <- 세번째 디스패쳐 프로세스                   마지막으로, V$QUEUE 자료사전을 참조해 보면 요청 큐와 각 디스패쳐 프로세스의 응답 큐를 확인할 수 있습니다. PADDR 컬럼의 값이 0은 REQUEST 큐에 대한 정보이고 TYPE 컬럼의 값이 DISPATCHER는 RESPONSE 큐에 대한 정보입니다. 공유서버 환경에서 REQUEST 큐의 개수는 한 개이고 RESPONSE 큐의 개수는 디스패쳐 프로세스 부 만큼 생성됩니다.                             SQL> SELECT * FROM v$queue;     PADDR TYPE QUEUED   ----------------------------------- 00 COMMON 0   79D92A30 DISPATCHER 0   79D92A84 DISPATCHER 0   79D92AD8 DISPATCHER 0                                       공유 서버 프로세스 환경의 튜닝                 공유서버 프로세스가 주로 사용될 수 있는 환경은 많은 사용자가 동시에 데이터베이스에 접속하며 소량의 데이터를 처리하는 OLTP(Online Transaction Process) 업무에 가장 적합합니다. 공유서버 프로세스 환경에는 디스패쳐 프로세스, 공유서버 프로세스, RESPONSE 큐와 같은 프로세스들이 필요한데 시스템에서 시용할 수 있는 개수는 항상 제한적입니다. 만약, 동시에 많은 사용자들이 데이터베이스에 접속하게 되면 제한된 프로세스를 서로 나누어서 사용해야 하기 때문에 하나의 프로세스에 대해 경합현상이 발생하게 됩니다. 경합현상이 발생하게 되면 대기상태가 일어나게 되고 결국 성능이 저하되는 문제가 발생하게 되는 것 입니다. 공유서버 환경에서 경합이 발생할 수 있는 부분은 3가지 포인트가 있습니다.               첫 번째 부분은, 사용자가 접속을 요구했을 때 디스패쳐 프로세스가 부족하여 발생하는 경합문제 입니다. 하나의 디스패쳐가 처리할 수 있는 작업의 범위는 제한되어 있습니다. 그리고, 디스패쳐 프로세스의 최대 개수도 제한되어 있습니다. 동시에 많은 사용자가 데이터베이스에 접속을 요구하고 SQL문의 실행을 요구한다면 서로 디스패쳐 프로세스를 사용하기 위해 경합을 벌이게 될 것 입니다. 즉, 성능이 저하될 수 있다는 의미입니다. 이런 경우에는 디스패쳐 프로세스에 경합이 발생하는지를 분석한 다음 보다 많은 디스패쳐 프로세스 수를 늘려주어야 경합을 최소화할 수 있고 궁극적으로 성능을 향상 시킬 수 있습니다. 다음은 디스패쳐 프로세스에 경합이 발생하는지를 분석하는 방법입니다.                             SQL> SELECT network, sum(busy) / (sum(busy + sum(idle)) "Total Busy Rate"   FROM v$dispatcher   GROUP BY network;         NETWORK RATE --------------------------------------------------------- (ADDRESS=(PROTOCOL=tcp)(HOST=192.9.200.1)(PORT=1521)) 4.2345E-07 (ADDRESS=(PROTOCOL=tcp)(HOST=192.9.200.1)(PORT=1521)) 0.34651 (ADDRESS=(PROTOCOL=tcp)(HOST=192.9.200.1)(PORT=1521)) 0.58722                   <- 만약, , sum(busy) / (sum(busy + sum(idle) 의 비율이 0.5 를 초과한다면 디스패쳐 프로세스에 경합이 발생한 것이며 성능이 저하될 수 있음을 의미합니다.                   이런 경우에는 다음과 같이 디스패쳐 프로세스의 수를 보다 많이 할당해 주어야 합니다.                   SQL> ALTER SYSTEM SET mts_dispatchers = 'tcp, 10'; <- 디스패쳐 프로세스를 기본적으로 10개를 활성화 합니다.   SQL> ALTER SYSTEM SET mts_max_dispatchers = 'tcp, 20'; <- 디스패쳐 프로세스를 최대 20개까지 활성화 합니다.                 두 번째 부분은 사용자의 요구를 받은 디스패쳐 프로세스가 REQUEST 큐에 요청된 내용을 저장한 후 공유서버 프로세스에 의해 처리되면 RESPONSE 큐에서 결과를 가져오게 됩니다. 그런데, 디스패쳐 프로세스가 너무 많은 일들을 처리하다 보면 이미 처리가 되어 RESPONSE 큐에 저장되어 있는 결과를 읽어서 사용자 프로세스에게 돌려주지 못하여 RESPONSE 큐에 결과가 쌓이는 현상이 발생하게 됩니다. 즉, 디스패쳐 프로세스 수가 부족하여 대기상태가 발생하는 경우입니다, 이런 경우에는 디스패쳐 프로세스와 RESPONSE 큐 간의 대기상태를 분석한 다음 보다 많은 디스패쳐 프로세스 수를 늘려주어야 성능을 향상 시킬 수 있습니다. 다음은 디스패쳐 프로세스와 RESPONSE 큐 간의 대기상태를 분석하는 방법입니다.                   SQL> SELECT sum(wait) / sum(totalq) FROM v$queue q, v$dispatcher d WHERE q.paddr = d.paddr AND lower(q.type) = 'dispatcher';   SUN(WAIT)/SUM(TOTALQ) ------------------------ 0                   <- 만약, sum(wait) / sum(totalq) 결과가 0 값이면 RESPONSE 큐에 대기중인 처리결과가 없다는 의미이며 이 결과값이 계속적으로 증가한다면 처리결과가 계속 쌓이고 있다는 의미입니다. 즉, 디스패쳐 프로세스의 수가 부족하여 성능이 저하될 수 있습니다.                   이런 경우에도 첫 번째 경우의 조치방법과 같이 디스패쳐 프로세스의 수를 보다 많이 할당해 주어야 합니다.                 세 번째 부분은 디스패쳐 프로세스들에 의해 요청된 내용이 REQUEST 큐에 저장되면 작업이 가능한 공유서버 프로세스가 요청된 내용을 처리하게 됩니다. 만약, 활성화된 공유서버 프로세스들 중에 여유가 있는 프로세스가 없다면 REQUEST 큐에는 요청된 작업 내용들이 쌓이게 될 것이고 SQL문의 성능은 저하될 것입니다. 이런 경우에는 공유서버 프로세스의 경합상태를 분석한 다음 보다 많은 공유서버 프로세스 수를 늘려주어야 성능을 향상 시킬 수 있습니다. 다음은 공유서버 프로세스의 경합상태를 분석하는 방법입니다.                   SQL> SELECT count(*) FROM v$shared_server WHERE status NOT LIKE '%QUIT%';   COUNT(*) ---------- 6                   <- 만약, count(*)의 결과가 mts_servers 파라메터에 설정된 값보다 커지 않다면 공유서버 프로세스에는 경합이 발생하고 있지 않은 것을 의미하며, mts_max_servers 파라메터에 설정된 값과 같은 결과가 나타나면 경합이 발생하고 있는 것 입니다. 즉, 공유서버 프로세스의 수가 부족하여 성능이 저하될 수 있습니다.                   이런 경우에는 다음과 같이 공유서버 프로세스의 수를 보다 많이 할당해 주어야 합니다.                   SQL> ALTER SYSTEM SET mts_servers = 10; ß 공유서버 프로세스를 기본적으로 10개를 활성화 합니다.   SQL> ALTER SYSTEM SET mts_max_servers = 20; ß 공유서버 프로세스를 최대 20개까지 활성화 합니다.                   다음 예제는 REQUEST 큐에 얼마나 많은 요청된 내용이 쌓여 있는지를 분석하는 방법입니다.                   SQL> SELECT wait / totalq FROM v$queue WHERE lower(type) = 'common';   WAIT/TOTALQ -------------- 0                   <- 만약, wait / totalq 결과가 0 값이면 REQUEST 큐에 대기중인 요청내용이 없다는 의미이며 이 결과값이 계속적으로 증가한다면 요청내용이 계속 쌓이고 있다는 의미입니다. 즉, 공유서버 프로세스의 수가 부족하여 성능이 저하될 수 있습니다.