SAP Memory 전체적인 구조 및 관리__SAP Memory Structure and Management
SAP BC - 기본 개념
- 1차 개편 완료 (25.09.03 ~ 25.09.23)
SAP 에서는 사용자가 리포트(프로그램 또는 Tcode) 를 수행할 때, 워크 프로세스는 개별 사용자마다 부여된 메모리(User Context, EM) 와 필요에 따라 프로세스의 메모리(HEAP) 를 사용하여 처리한다.
여기서는 SAP 시스템을 운영하면서 자주 보게되는 메모리 덤프에 대한 이해와, 정확히 어떤 흐름으로 SAP 메모리가 부여되고, 관리되는지에 대해서 기록한다.
해당 이해를 바탕으로 실무적으로 SAP 메모리를 조정하는 방법은 아래 포스트를 참조하기 바란다.
0. 서론
시작하기에 앞서, SAP Kernel 740 이상 부터는 새로운 메모리 관리 기능과 개념이 추가되었기 때문에, 대부분의 메모리 파라미터 값들이 PHYS_MEMSIZE (물리 메모리 크기) 파라미터 값을 통해 직간접적으로 자동 계산되어 적용된다.
따라서, 특별한 이슈 없이 정상 운영되는 시스템에서 해당 글을 기반으로 수치를 조정하거나 튜닝을 할 필요는 없으며, 전체적인 개념 이해로 참고하길 바란다.
1. SAP 메모리 유형
SAP Help Portal 의 메모리 유형과 설명은 다음과 같다.
기본적으로는 해당 문서를 기반으로 작성했으며, 이해를 돕기 위해 일부 용어는 변형해서 설명한다.
1-1. SAP 시스템 메모리
SAP 메모리는 크게 다음과 같이 6가지 유형이 있으며,
이 중 SAP Shared Memory 내에 ES, EM, EG 가 존재한다.
| 범주 | 메모리 유형 | 물리적 메모리 할당 | 메모리 할당 수명 | 사용자별 할당 여부 |
|---|---|---|---|---|
| OS 공유 메모리 | SAP Shared Memory (SHM) | 모든 Work processes | ABAP Instance 서비스 수행 | No |
| SHM | ㄴ Extended Segments Memory (ES) | 모든 Work processes | ABAP Transactions 수행 | - |
| SHM | ㄴ Extended Memory (EM) | 모든 Work processes | ABAP Transactions 수행 | Yes |
| EM | ㄴㄴ Global Extended Memory (EG) | 모든 Work processes | ABAP Instance 서비스 수행 | No |
| OS | PRIV Memory (HEAP) | 특정 Work Processes | ABAP Transactions 수행 | Yes |
| OS | PROC Memory | 특정 Work Processes | ABAP Instance 서비스 수행 | No |
2. SAP 시스템 메모리 세부 설명 에서 각 SAP 메모리에 대한 세부적인 설명을 추가한다.
1-2. SAP 세션 메모리
1-2-1. 유저 컨텍스트(User Conetxt)
유저 컨텍스트 는 SAP 시스템에 로그인한 각 사용자에게 할당되는 메모리이며, 사용자 세션에 속하는 데이터가 포함되어있다.
사용자가 로그인하게 되면, SHM 내의 EM 내에 각 사용자 별로 유저 컨텍스트라는 메모리 사물함이 생기게 되며, 사용자가 로그아웃 하면 해제된다.
(유저 컨텍스트가 SHM 내의 EM 에 존재하므로 똑같이 공유 메모리이다.)
상기 유저 컨텍스트 구조 그림에서 표현된 ABAP Session Context <N> 는 쉽게 새로운 SAPGUI 창(세션) 으로 이해하면 되며,
각 SAPGUI 창(세션) 마다 Internal Session Context (내부 세션 컨텍스트) 는 최대 9개까지 생성된다.
SAPGUI 창(세션) 갯수 파라미터(
rdisp/max_alt_modes) 의 기본 값이 6개이기에, 그림 상 6개까지 표현되어있다.
실제로는 해당 파라미터의 설정 값 만큼 ABAP Session Context 가 생긴다.
종합적으로 사용자 컨텍스트에는 다음과 같은 데이터가 포함되어 있다.
- 사용자 고유 데이터 (User-Specific Data)
- Authorization
- ABAP 변수
- ABAP 오브젝트
- Internal Table
1-2-2. 유저 컨텍스트 스위칭 (전환)
SAP 의 모든 화면은 정적 화면이다.
즉, 버튼 클릭 한번 한번(이하 Step) 마다 디스패쳐로 부터 사용 가능한 워크 프로세스를 할당 받아 처리한다.
따라서, 같은 프로그램 내에서 라도 Step 에 따라, 그때 그때 해당 요청(Request) 을 처리하는 워크 프로세스가 달라지며, 그때마다 요청 사용자의 유저 컨텍스트 데이터를 받아서 작업을 수행한다.
즉, 워크 프로세스가 한 사용자의 작업에서 다른 사용자의 작업으로 전환하면서, 유저 컨텍스트가 바뀌는 전체적인 개념을 유저 컨텍스트 스위칭이라 한다.
이는 공유 메모리 EM 내에 유저 컨텍스트가 존재하여, 모든 워크프로세스에서 접근이 가능하기 때문에, 유저 컨텍스트 간의 스위칭이 가능해진다.
만약 유저 컨텍스트가 HEAP 메모리에 존재하게 된다면, 각 워크프로스의 개별 메모리에 존재하는 것이기 때문에, 유저 컨텍스트 간의 스위칭이 불가능하다.
모든 워크 프로세스가 엑세스 할 수 있는 공유 메모리(EM) 과는 달리,
워크 프로세스의 개별 메모리인 HEAP 메모리에는 다른 워크프로세스가 엑세스 할 수 없기 때문에, 유저 컨텍스트 스위칭이 불가능하다.
2. SAP 시스템 메모리 세부 설명
설명에 앞서, 메모리 할당 관련 영어 단어는 아래 뜻 설명을 참고하길 바란다.
- assign : 논리적인 할당, 메모리를 예약만 해놓은 상태이며, 직접 점유 상태는 아님
- allocate : 물리적인 할당, 실제 메모리를 확보하여 점유 상태
- attach : 주소 매핑, 물리 메모리 주소를 전달하여, 가상 주소 공간에 연결(매핑), 포인터 개념
2-1. SAP Shared Memory (SHM)
2-1-1. SAP SHM
SAP Shared Memory(이하, SHM) 는 OS 영역의 공유 메모리를 기반으로 SAP 커널단 내부에서 논리적으로 구현된 자체 공유 메모리 영역이며, SAP 메모리에서 가장 상위 개념이다.
즉, SHM 는 OS 공유 메모리 기반 위에 만들어진, SAP 인스턴스의 전체가 공유할 수 있는 메모리(공유 메모리) 라고 보면된다.
이러한 SHM 은 실제 물리적인 메모리로부터 물리 주소로 할당된 공간이며, OS 상에서 ipcs -m 명령어를 통해서 확인할 수 있다.
SAP Help Portal 장표 상으로는 SHM, ES, EM 등등이 따로 적혀있어서 별개의 메모리 유형으로 받아들여질 수 있지만, 실제로는
1-1. SAP 메모리 유형과 그림표에서 보듯이 ES, EM, EG 는 모두 SHM 안에 속해 있는 메모리 유형이다.
SHM 은 SAP 시스템 전체의 공유 메모리이기 때문에, 같은 Host/Instance 안의 SAP 에서 수행되는 모든 작업(워크 프로세스) 에 매핑(attach) 될 수 있다.
SHM 에는 EM, EG 등의 공유 메모리 유형 외에도,
프로그램 버퍼, 테이블 버퍼 등의 다양한 SAP Buffer 와 ABAP 공유 메모리 객체 등등이 저장된다.
2-1-2. SHM Segment (공유 메모리 세그먼트)
SAP SHM 은 전체적인 메모리 유형의 이름이며, 실제 워크 프로세스에 할당되어 사용될때는 SAP SHM Segment 로 부여된다.
따라서, 먼저 물리 메모리상의 예약된 공간에 SAP SHM Segment 를 생성하고 해당 Segment 의 주소를 워크 프로세스에 매핑(attach) 한다.
SAP SHM Segment 는 공유 범위에 따라, Global(Host 단위 공유) / Local (Instance 단위 공유) 로 나눠진다.
SHM Segment 는 기본적으로 OS Shared Memory Segment 에서 직접 할당되지만, SHM Pool 을 통해서 관리되기도 한다.
2-1-3. SHM Pool (공유 메모리 풀)
SHM Pool 은 여러 SAP SHM Segment 들의 그룹 집합이며, 각 Pool 마다 특정한 공유 메모리 ID (Pool key) 를 가진다.
SHM Pool 은 파라미터 ipc/shm_psize_<nn> 을 통해서 확인할 수 있으며, nn 은 공유 메모리 ID 를 뜻한다.
대표적으로 SAP Buffer 는 공유 메모리 ID 10, 40 에 저장되며, 아래 Notes 의 첨부파일을 통해서 각 SAP Buffer 가 속해 있는 공유 메모리 ID 를 볼 수 있다.
- SAP Notes 1137734 - Assignment of memory areas, shared memories, and pools
2-1-4. SHM 해제/삭제
이러한 공유 메모리는 SAP 명령어로 해제가 가능한데,
우리가 SAP 서비스를 종료하고 수행하는 cleanipc 명령어가 바로 SAP 공유 메모리 해제 명령어이다.
cleanipc명령어로 공유 메모리를 해제하는 구문은 다음과 같다.
cleanipc <Instance Number> remove
2-1-5. 설정 파라미터
SAP 지시를 제외하고는 관리자가 별도로 수정할 필요 없음.
2-2. Extended Segments Memory (ES)
2-2-1. Extended Segments Memory
Extended Segments (이하 ES) 는 EM 과 EG 를 구성하는 기본 단위이다.
ES 는 동일한 크기의 ES Block 으로 구성되며, 64bit 시스템의 경우, ES Block의 기본 값은 4 MB 이다.
즉, ES Block 이 모여서 EM 과 EG 가 구현되며, EM 이 확장될때는 ES Block 단위로 할당이 되며 확장 된다.
앞서 SHM 에서 설명했듯이 ES 는 공유 메모리(SHM) 에 속해있는 메모리 유형 중 하나이다.
2-2-2. 설정 파라미터
◼ em/blocksize_KB :
ES Segment 블럭 사이즈
2-3. Extended Memory (EM)
2-3-1. Extended Memory
Extended Memory (이하 EM) 은 SAP 메모리 관리의 핵심이며, 사용자 별 데이터(User-specific Data, 유저 컨텍스트) 를 저장하는 것이 주 목적이다.
여기서는 보다 쉬운 이해를 위해 EM 을 다음과 같이 구분한다.
◼ EM-메모리 영역 : Extended Memory 의 전체 영역(=em/initial_size_MB)
◼ EM-User Context : EM 영역 내, 할당(allocate) 된 유저 컨텍스트 구역
EM-메모리 영역의 핵심은 바로 위에 설명했듯이 유저 컨텍스트 가 할당되는 공간이라는 점이다.
워크 프로세스가 작업을 수행하기 위해서는 반드시 EM 영역내에 있는 유저 컨텍스트가 필요하며, 작업 수행에 필요한 데이터(ABAP 변수, 인터널 테이블 데이터 등) 들을 유저 컨텍스트에 저장한다.
2-3-2. EM-User Context 할당 순서
워크 프로세스가 요청을 받아 프로그램을 수행할 때, 운영체제와 작업 유형에 따라서 SAP 메모리 관리자로부터 할당 받는 메모리의 순서가 달라진다.
◼ Unix(AIX 제외), Linux 시스템의 경우,
◻ Dialog 작업일 시, EM → HEAP 순서
◻ Non-Dialog 작업일 시, HEAP → EM 순서로 할당된다.
◼ Window, AIX 에서는 Dialog/ Non-Dialog 관계 없이,
◻ EM → HEAP 순서로 할당된다.
유닉스, 리눅스 시스템에서의 메모리 할당 순서의 차이에는 이유가 있다.
프론트에서 수행되는 Dialog 작업은 빠른 유저 컨텍스트 스위칭을 보장하기 위해, 워크 프로세스에 EM-User Context 을 먼저 할당한다.
EM-User Context 은 단순히 워크 프로세스의 내부 가상주소 공간에 매핑(attach) 만 하기 때문에 스위칭이 빠르기 때문이다.
이 후, 메모리 사용량이 EM-User Context 최대치에 도달하면, HEAP 을 할당한다.
🔰 이하, 이어지는 아래 설명은 기본적으로 Linux / Dialog 작업 유형을 기준으로 설명한다.
2-3-3. EM 구현 모델
운영체제에 따라서, EM 과 워크프로세스의 가상주소 매핑의 구현 모델도 달라진다. (파라미터 : es/implementation)
자세한 설명은 아래 3. SAP 워크 프로세스의 내부 가상주소 공간 구조 에서 진행한다.
◼ 리눅스나 유닉스는 기본값이 std (flat 모델)
◼ 윈도우는 기본값이 view (map 모델)
2-3-4. ROLL 영역 개편
SAP Kernel 7.40 부터는 메모리 현대화의 일환으로 ROLL 영역이 EM 으로 통합되었으며, 기존의 ROLL 영역 = EM 영역으로 이해하면 된다.
이에 따라, 기존 ROLL 영역의 몇몇 파라미터는 더 이상 작동을 하지 않으니 참고하기 바란다. (ztta/short_area 등)
자세한 내용은 다음 Notes 참조하기 바란다.
- SAP Notes 2085980 - New features in memory management as of Kernel Release 7.40
2-3-5. 설정 파라미터
◼ em/initial_size_MB :
전체 EM 메모리 풀 크기, (AIX 의 경우 EM/TOTAL_SIZE_MB)
◼ ztta/roll_extension :
워크 프로세스에 매핑된 EM-User Context 가 최대로 확장 가능한 크기 (Dialog, Non-Dialog 모두 적용됨, 글로벌 설정)
◼ ztta/roll_extension_dia :
Dialog 워크 프로세스에 매핑된 EM-User Context 가 최대로 확장 가능한 크기
(Dia 전용, 설정 시 Dia 워크 프로세스는 해당 메모리 제한값을 따름.)
◼ ztta/roll_extension_nondia :
Non-Dialog 워크 프로세스에 매핑된 EM-User Context 가 최대로 확장 가능한 크기
(Non-Dia 전용, 설정 시 Non-Dia 워크 프로세스는 해당 메모리 제한값을 따름.)
ztta/roll_extension파라미터는 글로벌 설정이며,ztta/roll_extension_dia/nondia가 설정된다면,ztta/roll_extension파라미터 설정 값을 무시하고,ztta/roll_extension_dia/nondia파라미터 설정 값을 따른다.
◼ es/implementation :
EM 구현 모델, (AIX 의 경우 EM/TABLE)
2-4. Global Extended Memory (EG)
2-4-1. Global Extended Memory
Global Extended Memory (이하 EG) 는 글로벌 데이터 용으로 예약된 EM 의 한 부분이며, 특정한 워크 프로세스나, 특정 사용자 세션에 속하지 않는 글로벌로 사용되는 데이터가 저장된다고 이해하면 된다.
예를 들어, 모니터링 및 통계에 사용되는 데이터, 데이터베이스 인터페이스(DBI) 의 테이블 버퍼, 사용자 세션과 관계 없이 모든 Work process 가 엑세스할 수 있는 ABAP 공유 객체등이 EG 에 포함된다.
또한, SAP 커널 Component 간의 내부 통신(작업 핸들러, 인큐 등) 에서 발생하는 관리 데이터도 EG 에 저장된다.
일반적인 EG 의 크기는 EM 의 5% 크기이며,
SAP 에서도 EG의 크기를 EM의 5~10% 크기를 추천한다.
2-4-2. 설정 파라미터
◼ em/global_area_MB :
전체 EG 메모리 풀 크기
단, SAP Help 문서에서는, 실제 EG 의 전체 크기는 항상 파라미터로 설정된 값보다 크게 예약된다고 설명한다.
2-5. PRIV Memory
2-5-1. PRIV Memory (또는 HEAP Memory)
PRIV 메모리(이하 HEAP) 은 워크 프로세스가 SAP 메모리 관리자를 통해서, OS 로 부터 직접 할당받는 메모리이다.
EM-User Context 가 최대 할당량에 도달하게 되면, 워크 프로세스는 개인 메모리인 HEAP 메모리를 할당받은 다음, 초과된 유저 컨텍스트 데이터를 HEAP 메모리에 저장한다.
여기서는 이해를 돕기위해, HEAP 메모리에 저장되는 유저 컨텍스트 데이터를 HEAP-User Context 라 표현하겠다.
즉, 이 시점에서의
유저 컨텍스트(User Context)데이터는EM-User Context+HEAP-User Context이다.
Dialog 워크 프로세스에서 유저 컨텍스트가 HEAP 메모리에 할당되면, 더 이상 공유 메모리(EM) 가 아닌, 워크 프로세스가 개인적 할당받은 Private 한 메모리(PRIV Memory = HEAP) 를 사용함으로, 해당 워크 프로세스는 PRIV 모드로 전환된다.
(HEAP 메모리를 할당 받은 Dialog 워크 프로세스 = PRIV 모드 워크프로세스)
워크 프로세스가 PRIV 모드로 전환되면 (HEAP 메모리를 할당 받으면),
유저 컨텍스트 데이터는 더 이상 공유 메모리(EM) 에만 존재하는 것이 아니라, 워크 프로세스의 개인 메모리(HEAP) 에도 존재하게 된다.
유저 컨텍스트 데이터가 EM-User Context 와 HEAP-User Context 로 나눠졌기 때문에, 더 이상 유저 컨텍스트 공유가 불가능해지게 되고, 유저 컨텍스트는 해당 워크 프로세스에게 묶이게 된다.
(HEAP-User Context 는 공유 메모리가 아닌, 워크프로세스의 개인 메모리에 저장되므로)
이로 인해, PRIV 모드로 작업을 수행 중인 Dialog 워크프로세스는, 현재 수행 중인 작업이 종료되어 HEAP 메모리에 할당된 유저 컨텍스트 데이터가 해제될 때까지, 현재 수행 중인 작업만을 처리할 수 있다.
(즉, PRIV 모드 워크 프로세스는 종료 전까지 다른 작업을 처리할 수 없다.)
2-5-2. HEAP 메모리 설정 파라미터
◼ abap/heap_area_total :
전체 HEAP 메모리 풀 크기
◼ abap/heap_area_dia :
개별 Dialog 워크프로세스에 할당할 수 있는 최대 HEAP 메모리 크기
◼ abap/heap_area_nondia :
개별 Non-Dialog 워크프로세스에 할당할 수 있는 최대 HEAP 메모리 크기
만약 HEAP 메모리 여유가 없다면, 추가로 할당할 메모리가 없으므로 워크 프로세스가 EM 최대 할당량에 도달할 경우, 메모리 DUMP 와 함께 작업이 바로 종료된다.
2-5-4. HEAP 메모리 반환
PRIV 모드 워크 프로세스 작업이 정상적으로 종료되면, 워크 프로세스는 할당받은 HEAP 메모리를 해제하여 OS 에 반환하는데, 이때 할당 받은 HEAP 메모리 전체를 반환하지 않고, 일부분만 반환한다.
따라서, 워크 프로세스가 OS 메모리를 장기간 점유하지 않도록, 파라미터를 통해 워크 프로세스의 자동 재시작 설정할 필요가 있다.
2-5-5. HEAP 메모리 관리 파라미터
◼ abap/heaplimit (SAP Kernel 7.49 미만) :
SAP Kernel 7.49 미만에서 HEAP 메모리 사용량에 따른 워크프로세스 재시작을 트리거하는 파라미터.
워크 프로세스에서 할당받은 HEAP 메모리 크기가 해당 파라미터 값을 초과한다면, 현재 작업이 종료된 후, 해당 워크 프로세스 재시작을 트리거한다.
(말그대로, 재시작을 트리거하기 때문에, rdisp/wp_abap_restart 파라미터 값에 따라, 재시작을 안할 수도 있다.)
◻ rdisp/wp_abap_restart :
워크 프로세스 재시작 트리거에 대한 대기 시간 설정. (기본 초 단위)
기본 값은 0 이며, 대기 없이 최대한 빠르게 워크프로세스를 재시작한다.
◼ rdisp/os_heap_for_restart (SAP Kernel 7.49 이상) :
- SAP Notes 2660701 - Memory disclaiming in heap
- SAP Notes 3285104 - Default setting for heap monitoring
SAP Kernel 7.49 이상에서 HEAP 메모리 사용량을 모니터링하여, 워크프로세스 재시작을 트리거하는 파라미터.
◻ rdisp/os_heap_check_frequency : HEAP 메모리 모니터링 빈도
◻ rdisp/os_heap_check_time : HEAP 메모리 모니터링 주기
◼ rdisp/wppriv_max_no :
PRIV 모드 워크 프로세스의 최대 숫자.
PRIV 모드 워크 프로세스의 숫자가 해당 파라미터 값을 초과한다면, 가장 오래된 PRIV 모드 워크 프로세스가 강제로 종료된다.
0 값 설정 시, 모든 워크 프로세스는 PRIV 모드로 전환되지 않고 종료된다. (워크 프로세스가 HEAP 메모리를 사용하지 않음)
해당 파라미터가 rdisp/max_priv_time 파라미터보다 적용 우선순위가 높다.
◼ rdisp/max_priv_time :
PRIV 모드 워크 프로세스가 작업을 수행 할 수 있는 최대시간. (기본 초 단위)
2-6. PROC Memory
2-6-1. PROC Memory
PROC 메모리는 유저 컨텍스트와 관계없이, 각 워크 프로세스마다 필요한 자체 기본 데이터(Temporary, Heap buffer 등등) 를 저장하는데 사용된다.
파라미터 설정은, 개별 워크 프로세스에 할당되는 PROC 메모리 양이 아닌, 전체 PROC 메모리 풀의 크기를 설정할 수 있으며, 해당 메모리 풀 안에서 자동으로 할당된다.
2-6-2. 설정 파라미터
◼ em/proc_max_size_MB : 전체 PROC 메모리 풀 크기
◼ em/proc_max_wpsize_MB : 개별 워크 프로세스의 최대 PROC 메모리 크기
3. SAP 워크 프로세스의 내부 가상주소 공간 구조
각 워크 프로세스는 내부적으로 가상 주소를 기반으로한 자체 가상 주소 공간을 가지며, 가상주소 공간 구현은 EM 구현 모델인 es/implementation 파라미터 값에 따라 달라진다.
워크 프로세스 가상주소 공간을 주요 부분만 도식화하면 다음과 같이 구성되며,
실제 작업을 수행하기 전까지는 점유(allocate) 가 아닌 예약(assign) 만 해놓는다.
- Stack (위동적으로 확장 가능 ↑)
- SAP Shared Memory (SHM)
- ES (EM + EG, 고정된 크기)
- PRIV Memory (HEAP, 동적으로 확장 가능 ↑)
- PROC Memory
여기서는 Linux 에서 기본 값으로 설정된 EM 구현 모델인 Flat 모델을 중점으로 설명한다.
Flat 모델이 Linux 에서의 EM 구현 모델 기본값이지만, map 모델로도 변경할 수 있다. 실제로 예전 32bit 시스템에서는 map 모델을 기본 값으로 사용했다.
다만, SAP 에서는 64bit 시스템일 경우에는 Flat 모델(=std) 을 사용하는 것을 권장한다.
3-1. Flat 구현 모델 (STD 구현)
- SAP Notes 941735 - SAP memory management system for 64-bit Linux systems
Flat 모델의 경우, 그림에서 보다시피 공유메모리 영역(EM) 에 있는 메모리 주소 배열과, 워크프로세스의 메모리 주소 배열이 동일하게, Flat 매핑된다.
공유 메모리인 EM 전체 영역이 각각의 워크프로세스의 가상주소 공간의 예약된 EM 영역에, ES Block 단위로 모든 Block 이 전부 1:1 매핑된다.
모든 워크 프로세스들은 모두 공유 메모리 EM 전체를 바라보게 된다.
따라서, 워크 프로세스 1에서 공유 메모리의 유저 컨텍스트 데이터(EM-User Context) 를 변경한다면, 공유 메모리를 바라보고 있는 다른 모든 워크프로세스에게도 적용된다.
따라서, 워크프로세스에 EM 영역이 매핑될때, 작업을 요청한 사용자의 유저 컨텍스트만 매핑(attach) 되는 것이 아니라, 모든 사용자의 유저 컨텍스트가 메모리 보호된 채(protect) 로 워크프로세스에 매핑된다.
그리고, 실제 작업을 수행할때는 작업을 요청한 해당 사용자의 유저 컨텍스트만 메모리 보호를 해제(Roll-in) 하게되면, 해당 유저 컨텍스트는 다른 워크 프로세스에서 사용할 수 없도록 잠기게(Lock) 된다.
이러한 작업은, 실제 요청한 사용자의 유저 컨텍스트 외에, 다른 사용자의 유저 컨텍스트에 잘못된 동작 및 엑세스를 방지하기 위한 메모리 관리 메커니즘이다.
이렇게, 워크 프로세스는 메모리 보호가 해제된, 작업 요청 사용자의 EM-User Context 를 사용하여 작업을 수행한다.
EM 내에 각 사용자별 유저 컨텍스트는 메모리 주소 공간은 물리적으로 연속적이지 않다.
그림에서 노란색 표시된 1번 유저 컨텍스트가 확장된다고 할 때, 해당 메모리 공간에 이어서 연속적으로 확장되지 않는다.
그러나, SAP 커널 메모리 관리자가 Offset 을 통해 논리적 으로 연속된 것 처럼 관리를 한다.
작업이 종료되면, 메모리 보호를 해제한 해당 사용자의 유저 컨텍스트를 다시 보호하고(Roll-out), 다른 워크 프로세스에서 사용할 수 있도록 잠금을 해제한다.
3-2. Map 구현 모델
윈도우에서의 기본 EM 구현 모델인 Map 모델은 간단히 설명한다.
Map 구현 모델은 각 워크 프로세스의 내부 가상주소 공간에, 유저 컨텍스트를 매핑받는 전용 위치를 미리 예약해두고, 해당 주소공간에만 유저 컨텍스트를 매핑받는다.
내부적으로 map 함수를 사용하여 유저 컨텍스트를 워크 프로세스에 매핑하기 때문에, 매핑 되는 순간 해당 유저 컨텍스트는 잠기게 되며, 다른 워크 프로세스에서 사용할 수 없게 된다.
작업이 종료되면, unmap 함수로 유저 컨텍스트 매핑을 해제하게 되고, 이제 다른 워크 프로세스에서 해당 유저 컨텍스트를 사용할 수 있게 된다.
Flat 모델과의 주요 차이점은 EM 메모리 중에서, 필요한 부분만 그때그때 매핑된다는 점이다.
4. 종합 정리
아래 SAP 메모리 할당 흐름으로 넘어가지 전에, 중요한 부분을 종합적으로 정리한다. (Linux, Dialog 유형 기준)
-
유저 컨텍스트(User Context)에는 사용자 고유 데이터와 프로그램/리포트 수행에 필요한 데이터들이 저장되며, 워크 프로세스가 작업을 수행하기 위해서는 유저 컨텍스트가 반드시 필요하다. -
유저 컨텍스트는 공유 메모리 (SHM 내의 EM 에) 생성되며, 기본적으로는 EM 안에 생성되지만, 메모리 사용량과 작업 유형(Non-Dialog) 에 따라 HEAP 안에도 있을 수 있다. (HEAP-User Context) -
워크 프로세스는 OS 종류와 작업 유형(Dia, Non-Dia) 에 따라 EM, HEAP 할당 순서가 달라진다.
해당 글의 설명은 기본적으로 Linux, Dialog 작업 유형을 기준으로 설명하고 있다. (EM → HEAP 순) -
EM-User Context 는 공유 메모리 상의 메모리 주소 값만 워크 프로세스에 매핑(attach) 하기 때문에, 빠른 유저 컨텍스트 스위칭이 가능하다.
-
Dialog 워크 프로세스가 HEAP 메모리를 할당받아, HEAP 메모리에
유저 컨텍스트를 저장하면 (HEAP-User Context 가 생기면), PRIV 모드로 전환되어, 해당 작업만 처리한다.
5. 전체적인 메모리 할당 흐름
지금까지 설명의 이해를 돕기 위해, 간단한 시나리오로 SAP 메모리가 할당되는 흐름을 따라가보려고 한다.
5-1. Linux, Dialog 작업의 경우 (Flat 모델)
5-2. Window, Dialog 작업의 경우 (Map 모델)
해당 케이스의 시나리오는 다음과 같다.
- Window 서버, Map 구현모델
- 사용자 TEST_USER 가 프로그램 ZTEST_PROGRAM 을 Dialog 로 수행한다.
- 프로그램 ZTEST_PROGRAM 은 많은 메모리를 사용하며, HEAP 메모리 사용까지 필요하다.
◾ 사용자 TEST_USER 가 프로그램 ZTEST_PROGRAM 을 Dialog(프론트) 수행.
◾ 프로그램 ZTEST_PROGRAM 수행 요청은 디스패쳐로 전달되어, 디스패쳐 큐(Dispatcher Queue) 로 들어간다.
디스패쳐는 사용 가능한(유휴) Dialog 워크 프로세스에 해당 프로그램 수행 요청을 할당한다.
◾ SAP 커널 메모리 관리자는 공유 메모리 EM 내에 해당 사용자의 유저 컨텍스트 를 할당된 워크 프로세스에 매핑(attach) 한다.
◾ 워크 프로세스는 매핑된 유저 컨텍스트를 통해, 사용자 고유 데이터, 권한 데이터와 함께 프로그램 실행에 필요한 메모리를 확인하여 프로그램을 수행한다.
◾ 프로그램 ZTEST_PROGRAM 수행에 따라, EM-User Context 는 필요한 만큼 확장 되며, 최대 ztta/roll_extension_dia 파라미터 설정 값만큼 확장된다.
◾ EM-User Context 가 최대 할당치까지 도달했다.
그러나 프로그램 정상 종료까지 메모리가 더 필요하므로, SAP 커널 메모리 관리자를 통해서, 현재 워크 프로세스에 HEAP 메모리를 추가로 할당받아 작업을 이어서 수행된다.
◾ 이제 워크 프로세스의 개인 메모리(HEAP) 에 유저 컨텍스트 가 저장되기 때문에 (HEAP-User Context), 현재 작업을 수행 중인 워크 프로세스는 PRIV 모드로 전환된다.
이로 인해, 현재 워크 프로세스는 지금 수행 중인 작업이 종료되어 유저 컨텍스트가 해제될 때까지, 다른 작업은 처리하지 않고, 해당 작업만을 처리한다.
◾ (1) 작업이 Dia HEAP 최대 사용량(abap/heap_area_dia) 까지 도달하기 전에, 정상 종료 되었다.
이제, 차례로 다음 작업을 수행하여, 다시 사용 가능한 유휴 워크 프로세스가 된다.
1. 매핑된 유저 컨텍스트 를 해제
2. PRIV 모드에서 기본 모드 전환
3. 할당 받은 HEAP 메모리 반환 (전체 반환은 아님)
4. HEAP 메모리 관리 파라미터 설정 값에 따라서, 워크 프로세스 재시작 트리거 설정. (재시작 시, HEAP 메모리 전체 반환)
◾ (2) 작업이 Dia HEAP 최대 사용량에 도달했음에도 작업이 종료되지 않았다면, 강제로 작업을 종료한 다음, ABAP 덤프(메모리) 를 생성한다.
6. FAQ SAP Notes
6-1. 트러블슈팅 관련
- SAP Notes 2180736 - TSV_TNEW_PAGE_ALLOC_FAILED (or similar, memory related) short dumps
- SAP Notes 3259122 - SYSTEM_NO_ROLL - Troubleshooting
- SAP Notes 2488097 - FAQ: Memory usage for the ABAP Server on Windows
6-2. 분석 관련
- SAP Notes 2194685 - How to find work process trace for SM21 System Log or ST22 dump
- SAP Notes 3422772 - How to get more information on MEMORY_NO_MORE_PAGING dumps in ST22
- SAP Notes 1563748 - MEMORY_NO_MORE_PAGING dump occurs in ST22
- SAP Notes 3252927 - Low free memory in Linux
- SAP Notes 2840590 - CST - Troubleshooting SAP Memory Dumps - Guided Answers
- SAP Notes 2442188 - Analyzing and Configuring Memory to Increase Performance - Guided Answers
6-3. 특이 케이스 관련
- SAP Notes 3529809 - Why memory is not released when click return button in some transaction?
- SAP Notes 1241185 - Increased memory consumption for report transactions
- SAP Notes 2401892 - High memory consumption for page management of internal tables
- SAP Notes 3405362 - Heap consumption in work processes increases continually.
- SAP Notes 3296506 - Swap Memory at 100%
- SAP Notes 3237356 - Implementing an SAP Note with SNOTE terminates with TSV_TNEW_PAGE_ALLOC_FAILED
