CM(Concurrent Manager) 처리구조의 이해

CM(Concurrent Manager) 처리구조의 이해에 대해 설명하려합니다.

 

•Concurrent Program은  대부분 Batch 작업 성격으로 수분에서 수시간에 걸쳐작업이 수행됩니다. 

•이러한 작업이 전체적인 작업 scheduling이 되지 않은 상태에서 운영된다면 특정 시간대에 작업이 몰려  전체적인 시스템 성능에 막대한 영향을 미칠 수 있으며 심각한 경우 시스템이 정지되는 상황이 발생할 수 있습니다.

•따라서 Concurrent Program의 작업 수와 작업 시간을 산정함으로써 시스템 자원의 용량을 효율적으로 사용하고 전체적인 성능향상을 위한 기본 자료로 이용하고자 합니다.

•이번 조사에 포함되는 Concurrent Program의 범위는 Oracle ERP의 Concurrent Manager에 의해 관리되고 수행되는 작업을 통칭합니다.

•여기에 포함되는 Concurrent Program에는 Batch Program, Report, Interface Program등이 있을 수 있습니다.

 

•Work Shifts

–Work shift는 Concurrent Manager가 활동할 수 있는 Active기간을 지정한다.

•Worker

–각 Manager는 Work shift별로 할당된 Worker를 갖으며, 각 Work는 한번에 하나의 Request(Program)을 처리한다.

–Worker 갯수 설정 : 대상 request의 특성, Throughput을 고려하여 적정한 값을 구한다.

–각 Worker는 Database에 새로운 Connection을 만드는데, 이로 인한 부하가 N/W에 발생하며, 급격한 Worker의 증가는 N/W bottleneck 및 System의 resource 사용을 유발하므로 이에 대한 주의가 필요.

•Sleep Time

–Manager가 request table 에서 Pending Request를 읽는 (Request Queue Scan) 주기를 정한다.

–Request Queue에 많은 수의 Pending/Normal Request가 존재하는 경우 이 값을 줄이는 것은(Default:60sec) 의미가 있으나 이를 30초 이하로 할  경우 System에 과도한 부하를 유발하므로 주의해야 한다.

–예를 들어 sleep time이 1이라면 1초마다 request table을 scan하는 작업을 하여 Database performance에 지대한 악영향을 준다.

•Cache Size

–request table scan시  한 번에 읽어 들이는 (cache하는) Pending Request정보의 개수를 정한다.

–해당 Request가 충분히 많고, Short-Running Requests (Constraint가 없는 Job)를  처리하는 경우 Cache Size를 최소한 Target process갯수의 두 배로 정하여, Sleep Time을 피하고 Throughput을 증가시킬 수 있다.

•Concurrent Server의 Process들은 ICM (Internal Concurrent Manager), CRM (Conflict Resolution Manager), 각 Manager Worker로 구성되며, 이들 각각은 Database Server에 자신과 연결된 Oracle Server Process를 갖는다.

•Concurrent Manager와 Database Server Process간 처리절차는 다음과 같다.

–각 Concurrent Manager는 Peer Oracle Server Process를 얻고 Session을 맺고 있다.

–사용자들이 Concurrent Program을 Request한다.

–Concurrent Manager는 Sleep Time Interval 마다 Request Table을 Access한다.

–Concurrent Manager가 처리할 Program이 Spawned Program인 경우 Program을 생성하여(Spawned), 처리하도록 한다. 이때 Spawned Program은 새로운 Peer Oracle Server Process를 생성하여 새로운 session을 맺은 후 Request를  수행한다.

–Concurrent Manager가 처리할 Program이 Spawned Program이 아닌 경우는 Manager가 직접 처리.

–CRM또한 Sleep Time Interval 마다 Requests Table을 Access하여 Pending/Standby Request를 찾아  해당 Request가 있는 경우 Conflict Program이 끝날 때까지 기다린 후 Phase/Status를 Pending/Normal로 변경하여 다른 Manager가 처리하도록 한다. 

•Constraint가 없는 Request 처리방법

–이러한 Type의 Request는 CRM이 관여하지 않으며, Manager들은 이 Table에서 Cache/Buffer Size만큼의 Request를 읽어 다음과 같이 처리를 한다.

–Manager는 자신의 Specialization Rule를 만족하는 가장 높은 Priority를 갖는 Pending/Normal request 들로 Cache를 채운다.

–Manager는 Cache의 Requests를 하나씩 읽으며 처리하고 결과를 return 한다.

–만일 Manager가 이 Cycle동안  적어도 하나의 request를 수행하였다면 Sleeping Period를 Skip하고 다음 request를 조회하여 처리하며 그렇지 않다면 설정된 Sleep Time동안 Sleep한 후 다시 request가 있는지 조회한다.

•

Manager의 개수, sleep, cache - cache수 만큼 row를 읽어와서 개수(max)만큼 수행하여 sleep time이후에 cache만큼 읽어와 처리 . 개수 : 한번에 매니저가 처리하는 개수 . cache : 한번에 매니저가 fnd_concurrent_requests table에서 가져올 수 있는 request의 수 . sleep : fnd_concurrent_requests table에서 내용을 가져오는 간격

 

•Constraint를 갖는 Request 처리방법

–동시에 같은 Data를 접근할 수 없는 Program(Incompatible Program등)을 요청하는 Request를 말한다.

–Request시 Pending/Standby 상태가 되며,  CRM 이 처리한 후 Pending/Normal상태로 바뀌어 위와 같은 처리를 하게 된다 

 

• Concurrent Program의 실행방식에는 Spawned, PL/SQL Stored Procedure, Java Stored Procedure, SQL*Plus, Immediate등이 있으며, 이와 관련하여 Concurrent Program은 Immediate, Spawned program 으로 구분된다.
• Spawned Program (Spawned, SQL*Plus)
  • Program Request을 처리하는 Concurrent Manager가 spawn한 Child Process에서 Run하며 이때 Manager는 해당 Program(Child)이 끝날 때까지 다른 Request를 처리하지 않는다.

 

• Immediate Program(Immediate, PL/SQL Stored Procedure, Java Stored Procedure)

Program Request을 처리하는 Concurrent Manager의 O/S process내에서 Run 한다.

 

 

• 오래 수행되고(Long-running), 긴급하지않은(Non-critical) 작업은 Workload가 많은 시간을 피하여 처리하도록 한다.
  • Resource를 많이 사용하는 Concurrent의 경우 가급적 System이 여유가 있는 시간대에 수행하는 것이 성능 측면이나 Resource 활용 측면에서 유리하다.
  • 예를 들면 야간에 수행이 가능한 Concurrent의 경우는 주간에 수행되지 않게 하여 OLTP 작업에 미치는 영향을 줄일 수 있다.
  • 특정 시간대에 수행되지 않아도 무방한 concurrent들은 수행 시간대를 골고루 분산하여 Concurrent 의 집중 현상을 방지할 수 있다.
• 많은 Resource를 사용하거나 큰 Log/Out file를 만드는 작업에 대해 주의한다.
  • Heavy한 Concurrent의 경우는 타 Concurrent나 OLTP의 성능에 많은 영향을 미치므로 scheduling에 더욱 신중해야 한다.
  • 수행주기가 아주 짧은 (수시로 수행되는) Concurrent에 주의 한다.
  • 수행주기가 아주 짧은 concurrent들의 경우 request table을 선점하게 되므로 타 Concurrent program이 Concurrent Manager를 할당 받지 못하는 상황이 생길 수 있다.
  • Spawned program의 경우는 Oracle server process가 떴다 내려갔다를 자주 반복하게 되므로 system 측면에서 추가적인 부하가 발생하게 된다.

 

• Template 작성시 주의 사항
  • 누락되는 프로그램이 없도록 조사되어야 한다. 누락된 program 한두 가지가 향후에 전체 scheduling을 뒤바꿀 수 도 있음.
  • 앞의 사항들을 참고하여 특정 시간대에 수행되지 않아도 무방한 concurrent 의 경우는 수행주기, 중요도 작성시 이를 반영한다.
  • 현 수행시간은 개발장비에서의 측정 시간이므로 가급적 부하가 적은 시간대에서 측정된 최신 값으로 하여 실제와의 오차를 줄인다.
    • Concurrent program 별로 수행시간을 측정한 instance가 다를 경우 이를 비고란등에 기입한다.
    • 일정상 가능하다면 본 장비에서 운영될 OPR1 에서의 수행시간을 기입하기를 권장한다.
  • Heavy한 Concurrent나 수행주기가 아주 짧은 Concurrent의 경우는 비고란등에 자세한 상황을 기술하여 scheduling시 이를 참고 할 수 있도록 한다.
  • 그 밖의 사항들도 가급적 자세하게 기술하는 것이 scheduling시 도움이 된다.

 

 

#Concurrent Request Status

Phase_code	Status_code	meaning
Pending(P)	Normal(I)	사용가능한 매니저를 기다리는 상태
	Stanby(Q)	incompatility가 걸려있는 현재 수행중인 선행 프로그램이 끝나기를 기다리는 상태
	Scheduled(Q)	Request가 미래의 시간에 scheduling된 상태
	Waiting(A,Z)	child request가 기다리는 상태는 parent request가 수행할 수 있는 상태 mark해주는 것을 기다림.
Running(R)	Normal(R)	정상적으로 request 수행 중
	Phased(W)	Complete되기 위해 모든 child request들을 중지함. 예를 들어 report set은 complete되기 위해 set의 모든 report들을 중지시킴.
	Resuming(B)	같은 parent에 의해 재시작 요청된 모든 request들은 running을 완료함. Parent request는 재시작되기 위해 기다리고 있음
	Terminating(T)	Terminating Running request는 Request Details zone의 Status field에서 Terminate가 선택되어 종료중인 상태

 

Phase_code	Status_code	meaning
Pending(P)	Normal(I)	사용가능한 매니저를 기다리는 상태
	Stanby(Q)	incompatility가 걸려있는 현재 수행중인 선행 프로그램이 끝나기를 기다리는 상태
	Scheduled(Q)	Request가 미래의 시간에 scheduling된 상태
	Waiting(A,Z)	child request가 기다리는 상태는 parent request가 수행할 수 있는 상태 mark해주는 것을 기다림.
Running(R)	Normal(R)	정상적으로 request 수행 중
	Phased(W)	Complete되기 위해 모든 child request들을 중지함. 예를 들어 report set은 complete되기 위해 set의 모든 report들을 중지시킴.
	Resuming(B)	같은 parent에 의해 재시작 요청된 모든 request들은 running을 완료함. Parent request는 재시작되기 위해 기다리고 있음
	Terminating(T)	Terminating Running request는 Request Details zone의 Status field에서 Terminate가 선택되어 종료중인 상태

 

Phase_code	Status_code	meaning
Completed(C)	Normal(C)	정상 종료
	Error(E)	성공적으로 종료되지 않음
	Warning(G)	Warning과 함께 request가 끝남. 예를 들어, report는 잘 생성되었으나, print가 제대로 안됨.
	Cancelled(D)	Pending이나 Inactive request가 Request Details zone의 Status field에서 Cancel 선택되어 끝남.
	Terminated(X)	Request Details zone의 Status field에서 Terminiate 선택되어 끝남.
Inactive(I)	Disabled(U)	실행한 request가 비활성화 상태
	On Hold(H)	Request Details zone의 Status field에서 Hold 선택된 Pending request
	No Manager(M)	Manager 없이 request 실행 정의됨.

 

Starting CM Process

 

 

$COMMON_TOP/admin/scripts/<context_name>/adcmctl.sh start apps/패스워드

(R12의 경우 $INST_TOP admin/scripts/<context_name>/adcmctl.sh start apps/패스워드)

-> $FND_TOP/bin/startmgr

-> $FND_TOP/bin/batchmgr

parameter : restart, diag, sleep, pmon, logfile, queue size

※ ICM이 시작되기전에 TNS Apps Listener 시작되어 있어야 함.

1) sh 이 Internal Concurrent Manager를 spawn한다.

2) ICM이 DB에 connect하여 System Profile에서 Concurrent:GSM Enabled 값을 확인

 

Y일 경우 :

3) ICM이 806 listener에게 요청하여 FNDSM을 spawn

4) FNDSM이 fnd_concurrent_queues table에 정의된 target_process에 따라 Manager들을 spawn후 관리

 

N일 경우 :

3) ICM이 Manager들을 spawn후 관리

 

#Concurrent Request Submission Flow

  

• Incompability

- 동시에 수행되어서는 안되는 request들에 대한 정의

- FND_CONFLICTS_DOMAIN에 등록되어 CRM이 체크하여 순서대로 돌려준다.

- FND_CONCURRENT_REQUESTS의CD_ID는 FND_CONFLICT_DOMAIN의 CD_ID값으로 PK으로 매칭

• Incompabiltiy 존재하는 request의 FND_CONCURRENT_REQUESTS table의 값 중 CD_ID,

CRM_RELEASE_DATE, QUEUE_METHOD_CODE가짐.