ABAP 느린 원인 90%는 WP 문제 — SM50으로 즉시 진단 #shorts #SAP #ABAP

개요 및 이 글이 답하는 질문

ABAP 시스템이 갑자기 느려지거나 사용자 트랜잭션이 멈춰버리는 상황은 운영자에게 가장 자주 찾아오는 골칫거리입니다. 이 글은 SAP NetWeaver AS ABAP의 핵심 모니터링 트랜잭션인 SM50(Work Process Overview)을 활용해 워크프로세스(WP) 상태를 정확히 읽어내고, 코드에서 TH_SERVER_LIST로 동적 조회하며, 가장 까다로운 PRIV 상태를 진단해 시스템 자원 부족을 해결하는 방법을 다룹니다.

SM50의 WP 상태 코드(PRIV, HOLD, STOP, WAIT, Running)를 해석할 수 있다
ABAP 코드 내부에서 함수 모듈로 WP 정보를 조회할 수 있다
PRIV 상태가 발생하는 메모리 흐름과 em/initial_size_MB 파라미터의 관계를 이해한다
장애 발생 시 어떤 WP를 먼저 보고, 어떤 SAP 노트를 참고할지 판단할 수 있다

이 글을 보기 전에

SAP GUI에서 트랜잭션 코드를 입력해본 경험이 있고, SM21(System Log), ST22(Dump Analysis) 같은 기본 모니터링 트랜잭션을 들어본 적이 있다면 충분합니다. ABAP의 FUNCTION MODULE 호출 문법과 내부 테이블(DATA ... TYPE TABLE OF) 정도를 다뤄봤다면 코드 실습이 매끄럽게 진행됩니다. 메모리(extended, heap, roll) 개념은 본문에서 다시 짚어드립니다.

환경 / 버전 / 준비물

아래 환경을 기준으로 검증된 절차입니다. 다른 릴리스에서도 SM50의 핵심 컬럼과 함수 모듈명은 거의 동일하지만, 신형 화면(SM50 New Design, S/4HANA의 SMON 연계)에서는 일부 라벨이 다를 수 있습니다.

SAP NetWeaver AS ABAP 7.52 이상 (S/4HANA 2022 / 2023 포함)
커널 패치 레벨 7.89 이상 권장 (PRIV 처리 로직 안정화 반영)
SAP GUI for Windows 7.70 또는 SAP GUI for Java 7.70 이상
권한 오브젝트: S_ADMI_FCD(값 PADM/SM21/ST0M 등), S_TCODE(SM50, SM66, SM04)
OS 레벨 점검을 위한 dpmon 접근 권한(선택)

SM50은 단일 애플리케이션 서버 인스턴스의 WP만 보여줍니다. 다중 인스턴스 환경에서는 SM66(Global Work Process Overview)을 함께 사용해야 전체 그림이 잡힙니다.

핵심 개념

ABAP 애플리케이션 서버는 디스패처(dispatcher)가 사용자 요청을 받아 여러 종류의 워크프로세스에 분배하는 구조입니다. 식당으로 비유하면 디스패처는 홀 매니저, 워크프로세스는 주방의 요리사입니다. 손님(사용자 요청)이 몰리면 요리사 수와 작업 상태를 실시간으로 봐야 병목을 알 수 있고, 그 창문이 바로 SM50입니다.

워크프로세스 타입

DIA (Dialog): 사용자 화면 트랜잭션 처리, 기본 응답시간 600초 제한(rdisp/max_wprun_time)
UPD / UPD2 (Update / Update2): V1 / V2 업데이트 모듈 실행
BTC (Background): SM37 잡 실행
SPO (Spool): 인쇄 출력
ENQ (Enqueue): 락 관리

WP 상태(Status) 코드

Waiting: 요청 대기 중. 정상 유휴 상태
Running: ABAP 코드 실행 중
Stopped: 디버그, RFC 응답, GUI, 큐 등 외부 이벤트 대기로 멈춤. 옆 컬럼 Reason(GUI, RFC, DEBUG, PRIV 등)이 핵심 단서
On hold (HOLD): 외부 자원 점유, 자주 보이는 Reason은 GUI(프론트 응답 대기), CPIC(RFC), ENQ(락 대기)
PRIV: 해당 WP가 사용자 컨텍스트의 heap memory를 점유해 다른 사용자에게 양보할 수 없는 상태. 가장 위험 신호

메모리 흐름

ABAP 메모리 할당 순서는 Roll Area → Extended Memory(EM) → Heap Memory입니다. EM(em/initial_size_MB)이 고갈되면 DIA WP는 Heap을 잡으면서 PRIV 상태로 전환되고, 그 WP는 사실상 한 사용자에게 묶입니다. PRIV가 많아질수록 활용 가능한 DIA WP가 줄어 시스템 전체 응답이 급격히 나빠집니다.

실전 코드 3단계

1단계: SM50 화면 해석과 기본 액션

SAP GUI에서 /nSM50 입력 후 표시되는 컬럼을 읽는 연습부터 합니다. 아래는 전형적인 한 줄 예시입니다.

* SM50 한 줄 예시 (텍스트로 재구성)
* No  Ty Pid    Status   Reason Start Err Sem CPU   Time User    Report   Action       Table
* 0   DIA 12345 Running  -      Yes   0   -   00:12 45   SCOTT   ZSD_RPT  Direct Read  VBAK
* 1   DIA 12346 Stopped  PRIV   Yes   0   -   00:08 120  KIM     ZFI_BIG  -            -
* 2   DIA 12347 On hold  GUI    Yes   0   -   00:00 2    PARK    SAPMV45A -            -
* 3   BTC 12348 Running  -      Yes   0   -   01:23 980  DDIC    RSBDCSUB Sequential   BDCP2

실무에서 가장 먼저 보는 컬럼은 Status / Reason / Time / User / Report / Action 다섯 개입니다. Time이 비정상적으로 큰 행, Reason이 PRIV인 행, 같은 Report가 여러 WP에 동시에 등장하는 패턴을 우선 확인합니다. 메뉴 Process → Trace → Active components로 SQL/RFC 트레이스를 즉시 활성화할 수 있고, Process → Cancel without core로 폭주 WP를 종료할 수 있지만 트랜잭션 무결성을 깰 수 있으니 SM12 락과 SM13 업데이트 큐를 먼저 점검합니다.

2단계: TH_SERVER_LIST + TH_WPINFO로 코드 조회 (에러/로깅)

GUI를 띄울 수 없는 자동 감시 잡에서는 함수 모듈로 WP 정보를 가져옵니다. TH_SERVER_LIST로 인스턴스 목록을 받고, 인스턴스별로 TH_WPINFO를 호출하는 패턴이 일반적입니다.

REPORT z_wp_monitor.

DATA: lt_servers TYPE STANDARD TABLE OF msxxlist_t,
      lt_wpinfo  TYPE STANDARD TABLE OF wpinfo,
      lv_msg     TYPE string.

START-OF-SELECTION.
  CALL FUNCTION 'TH_SERVER_LIST'
    TABLES
      list           = lt_servers
    EXCEPTIONS
      no_server_list = 1
      OTHERS         = 2.

  IF sy-subrc <> 0.
    MESSAGE |TH_SERVER_LIST failed: { sy-subrc }| TYPE 'E'.
  ENDIF.

  LOOP AT lt_servers ASSIGNING FIELD-SYMBOL().
    CALL FUNCTION 'TH_WPINFO'
      EXPORTING
        srvname = -name
      TABLES
        wplist  = lt_wpinfo
      EXCEPTIONS
        OTHERS  = 1.

    IF sy-subrc <> 0.
      WRITE: / 'WP info error on', -name.
      CONTINUE.
    ENDIF.

    LOOP AT lt_wpinfo ASSIGNING FIELD-SYMBOL()
                     WHERE wp_status = 'PRIV'
                        OR wp_waiting > 300.
      lv_msg = |SRV={ -name } NO={ -wp_index } | &&
               |TYPE={ -wp_typ } STAT={ -wp_status } | &&
               |USR={ -wp_bname } RPT={ -wp_report } | &&
               |TIME={ -wp_elapsed }|.
      WRITE: / lv_msg.
    ENDLOOP.
  ENDLOOP.

위 보고서를 SM37에 5분 주기로 등록하고, 결과가 한 줄이라도 나오면 알림을 보내는 식으로 운영합니다. TH_WPINFO는 인스턴스 단위로 동작하므로 클러스터 환경에서는 반드시 TH_SERVER_LIST로 받은 서버명을 그대로 전달해야 합니다.

3단계: PRIV 진단과 프로파일 대응 (프로덕션)

PRIV가 지속 발생할 때는 두 갈래로 접근합니다. 첫째는 폭주 프로그램 식별, 둘째는 메모리 파라미터 재산정입니다.

* PRIV 상태 WP의 메모리 점유를 빠르게 보고 싶을 때
* SM04(사용자 목록) → 사용자 선택 → Memory 버튼
* 또는 ST02(Tune Summary) → "SAP Memory" 영역에서
*   - In memory / Max. use / On disk 비교
*   - "Heap mem. - allocated" 가 비정상적으로 큰 사용자 확인

* 폭주 의심 프로그램을 코드 레벨에서 점검할 때 흔히 잡히는 안티패턴
SELECT * FROM vbak
  INTO TABLE @DATA(lt_vbak)            " 전체를 메모리에 적재 → EM/Heap 폭증
  WHERE erdat IN @s_erdat.

* 권장 패턴: 패키지 단위 처리로 PRIV 회피
SELECT vbeln, erdat, kunnr FROM vbak
  WHERE erdat IN @s_erdat
  INTO TABLE @DATA(lt_chunk)
  PACKAGE SIZE 5000.
  " ... 처리 ...
ENDSELECT.

프로파일 측면에서는 RZ11로 다음 파라미터를 점검합니다. 변경은 반드시 Basis 팀 검토 후 RZ10으로 영구 반영합니다.

em/initial_size_MB: 인스턴스 전체 Extended Memory 크기. 64비트 시스템에서 물리 메모리의 60~70%를 가이드로 설정
ztta/roll_extension_dia: DIA WP가 사용할 수 있는 EM 상한. 너무 작으면 Heap 진입(=PRIV)이 빨라짐
abap/heap_area_dia: DIA WP당 Heap 상한. 너무 크면 PRIV WP 하나가 OS 메모리를 다 먹음
abap/heaplimit: 트랜잭션 종료 시 WP가 재시작되는 기준
rdisp/max_wprun_time: DIA 최대 실행 시간(기본 600초)

운영 환경에서 변경 시에는 SAP Note 1986725(메모리 관리 기본), 2085980(PRIV 트러블슈팅 가이드) 류의 노트 번호와 자사 시스템 사이징을 함께 검토하는 것이 일반적인 접근입니다.

흔한 실수 / 트러블슈팅

Q1. PRIV WP를 Cancel without core로 죽였더니 사용자 데이터가 깨졌습니다.
PRIV WP가 Update를 트리거한 직후라면 SM13 업데이트 큐와 SM12 락이 함께 남습니다. 강제 종료 전에 반드시 두 트랜잭션을 확인하고, 가능하면 사용자에게 트랜잭션을 마치게 하거나 백그라운드로 옮기는 절차가 권장됩니다.

Q2. SM50에는 정상인데 사용자는 화면이 멈췄다고 합니다.
WP는 On hold / GUI 상태일 가능성이 높습니다. 이때는 ABAP 서버가 아니라 사용자 PC와 SAP GUI 간의 네트워크가 원인일 때가 많습니다. ST06(OS Monitor)의 LAN 응답시간과 SMGW(Gateway) 로그를 같이 확인합니다.

Q3. TH_WPINFO를 호출했더니 권한 오류가 납니다.
표준 권한 점검은 S_ADMI_FCD = PADM입니다. 운영 모니터링 사용자에 한해 부여하고, 일반 개발자는 SM50 트랜잭션 권한만으로 충분합니다. 함수 모듈을 RFC로 외부에서 호출할 때는 S_RFC에 함수 그룹 SUTL도 필요합니다.

Q4. SM50에서 ABAP 덤프(TSV_TNEW_PAGE_ALLOC_FAILED)가 자꾸 보입니다.
전형적인 EM/Heap 고갈입니다. ST22에서 덤프 상세를 열어 Memory consumption 섹션의 "Roll area / Extended memory / Heap memory" 값을 보고, 어느 영역에서 터졌는지 판정합니다. 코드 수정(패키지 처리, FREE 사용)이 우선이고, 프로파일 조정은 마지막 카드입니다.

Q5. SM66과 SM50의 숫자가 다릅니다.
SM66은 모든 인스턴스의 활성(running/stopped) WP만 모아 보여주고, Waiting은 기본적으로 숨깁니다. 화면 상단의 Select process 필터를 풀어야 동일한 기준이 됩니다.

다음 단계 / 관련 주제

SM50 사용이 익숙해지면 자연스럽게 다음 도구로 확장하게 됩니다.

SM66: 다중 인스턴스 통합 WP 뷰
ST03N / STAD: 트랜잭션별 응답시간 분포, PRIV 유발 프로그램 통계
ST02: SAP 메모리 영역 사용률, swap 발생 여부
SAT / SE30: 폭주 프로그램 런타임 분석
OS 레벨 dpmon: SAP GUI 없이 디스패처/WP 상태 확인
Focused Run / SolMan System Monitoring: PRIV 임계치 자동 알림 구성

S/4HANA에서는 HANA DB의 워크로드 클래스(WLM)와 ABAP WP의 매핑을 함께 보면 진단 정확도가 한 단계 올라갑니다.