DIA WP(Dialog work processes)는 ABAP기반의 IE(Integration Engine)에서 실행 중인 프로세스와 관련이 있는 모든 작업프레스가 사용되거나 관련 리소스가 부족한경우 PO나 PI와 SAP시스템(ERP, MDG...) 간의 연계방식인 Proxy, IDoc, BPM 등의 인터페이스에 병목현상이 보일수도 있다고 하며 DIA를 늘리는것을 권고한다는 내용을 어디선가 본것 같습니다.
통합엔진의 파이프라인 단계에서는 이 작업 프로세스를 사용하여 qRFC LUW를 기반으로 실행된다고 하며 PI의 ccBPM의 Business Process Engine에서도 통합프로세스의 단계를 실행한다고 합니다.
병목현상으로 인해 저체적인 인터페이스의 흐름에 영향을 줄수 있는 부분이며 비동기 메시지를 처리할때 관련있는 SM50, SM66, SMQR의 qRFC scheduler(Qin Scheduler)를 통해 어떤 유저로 인해 장시간 프로세스를 점유하고 있는지 확인이 가능하다고 하며 ABAP기반의 비동기 메시지는 qRFC를 통하여 처리된다고 합니다. 해당 리소스 상태는 SARFC에서 학인 및 모니터링이 가능한데 이런 작업과 확인을 통해 DIA작업 프로세스 수를 튜닝하여 이런 병목현상을 해결하는 경우도 있었던것 같습니다.
듀얼스텍의 PI시스템에서 초기 구성시 프로세스 수는 대략 CPU값의 약 6배여야 한다고 하는데 이 기준은 다른 SAP군 시스템들에 따라 현재기준과는 다를수 도 있을것 같습니다.
작업프로세스 예방과 병목현상 발생시 분석을 위한 부분들은 SM50, SM66의 CPU사용률, Dialog작업프로세스 개수에 대한 스냅샷과 모니터링을 통해 자료를 수집이 가능한것 같으며 Wily Introscope를 사용하여 ABAP리소스 사용량을 모니터링할수도 있다고 합니다.
그외 RFC나 IDoc와 관련있는 SM58의 transactional RFC(tRFC)와 SMQS의 qRFC Monitor(QOUT Scheduler)부분도 있다고 합니다.
위에 언급된 tRFC, qRFC에 대한 흐름을 알고 싶어 찾아보니 간단하게 정리하면
ABAP기반의 어플리케이션을 예를 들었을때
Client -> Outbound Queue(SMQR) -> tRFC(SM58) -> qRFC(SMQ1) -> qRFC(SMQ2) -> tRFC(SM58) -> Inbound Queue(SMQS)
이렇게 이해를 했지만 실제와 다를수 도 있을것 같습니다.
정리는 여기까지..
참조:
SAP NetWeaver Process Integration (PI)Performance-Check Guide:Analyzing Performance Problems and Possible Solution Strategies
댓글 없음:
댓글 쓰기