[SAPHANA] SAP HANA DB Memory Structure

1. SAP HANA DB ?

• Column 중심의 In-memory Relationship Database

Row 기반 테이블은 모두 메모리에 적재되지만 Column 기반 테이블은 컬럼을 선택적으로 선별하여 메모리에 적재한다. 

 

• HANA Memory Structure

SAP Notes 1999997 - FAQ: SAP HANA Memory

 

2. Memory 

 

2-1. Physical Memory (물리 메모리)

• OS 수준에서 물리적으로 사용 가능한 메모리 총량 (일반적으로 RAM)

 

2-2. Virtual Memory (가상 메모리)

• HANA DB 가 OS 에서 할당받은 메모리 총량 (물리적 메모리 + 디스크 페이징 영역)

Virtual Memory 는 HANA DB 가 OS 에 요청(또는 할당)한 메모리의 양이다.
지금 현재 사용하지는 않아도, OS 에서 사용하기 위해 HANA DB 가 미리 예약한 양이라고 생각 할 수 있다.

Virtual Memory 는 사용을 위해 예약해놨을 뿐 실제 사용 양은 아니다. 이렇게 Virtual Memory 가 예약 해놓은 공간을 Memory Pool 이라고 부른다.

테이블 증가, 임시 계산 등을 통해 메모리가 필요할 경우, Virtual Memory 의 Memory Pool에서 사용 가능한 크기 만큼 Resident Memory 가 되어 점유하게 된다.

만약 Memory Pool 이 요청양보다 작을 경우, HANA 메모리 관리자는 OS 에 추가 메모리를 요청하고, 추가로 메모리를 예약한다. (Virtual Memory 증가)

 

2-3. Resident Memory (상주 메모리)

• HANA DB 가 실제 작동하는데 사용되는 물리적 메모리 총량

Virtual Memory 를 사용하여 실제 메모리를 할당(점유) 받은 메모리이며, OS 에서 HANA DB 가 실제 사용하고 있는 메모리이다.

사용에 따라 Resident Memory 는 교체 될 수 있고, 반환한 메모리는 Memory Pool 로 재활용된다.

 

2-4. Used Memory (사용 메모리)

• HANA DB 프로세스 내에서 실제 사용 중인 메모리 총량

사용 메모리에는 프로그램 코드와 스택, 모든 테이블 데이터와 시스템 테이블, 임시 계산에 필요한 메모리가 포함된다.

프로그램 코드 및 스택의 크기는 약 6GB 정도이며, 대부분의 메모리는 테이블 저장 및 임시 계산, 데이터베이스 관리에 사용된다.

 

3. HANA DB 메모리 관리

위에 메모리 구조와 in-memory DB 특성을 고려하여 HANA DB 의 메모리를 관리해야 한다.

다음과 같은 사항을 확인하여 점검해볼 필요가 있다.

 

3-1. DB 서버 SWAP 설정

OS 수준에서 SWAP 의 크기가 크다면, HANA DB 가 SWAP 메모리까지 사용하여 SWAP 관련된 경고를 볼 수 있다.

따라서, SAP 에서는 적은 양의 SWAP 을 설정을 것을 권장하고 있다. 공식적으로 SAP 에서 권장하는 DB 서버의 SWAP 의 양은 2 GB 정도이다.

SAP Notes 1999997 - FAQ: SAP HANA Memory -> 21. How much swap space should be configured for SAP HANA hosts?
SAP Notes 2779331 - HANA services use large SWAP memory
SAP Notes 3131463 - Why use of OS swap space does not affect HANA db performance

 

3-2. 높은 Resident Memory 사용 관련

HANA DB 를 계속 운영하다보면 Resident Memory 가 지속적으로 늘어나게 된다.

이는 정상적인 운영 환경이라면 메모리 누수와 같은 문제가 아닌 정상적인 HANA DB 동작으로 본다.
결과적으로 HANA Studio 나 Tcode DBACOCKPIT 과 같은 모니터링 도구에서 Resident Memory 사용량의 빨간색 경고는 무시될 수 있다.

대신, 포인트는 Used Memory 부분이다. 할당 제한에 근접하지 않는지 확인해야 하며, 해당 메모리를 모니터링해야 한다.

SAP Notes 1999997 - FAQ: SAP HANA Memory -> 27. Is a high allocated memory / resident memory / OS used memory value critical?
SAP Notes 2081473 - SAP HANA Resident Memory: High Memory Usage

 

3-3. 현 메모리 설정의 적절성 확인

SAP 에서는 일반적인 경험적 법칙을 알려준다.

• 메모리 크기는 테이블(Row, Column Based) 데이터 전체 크기의 2배 이상인 것이 가장 좋다. (테이블 데이터가 전체 메모리의 50% 사용량 수준)
• HANA DB 에서 사용하는 메모리는 Allocation Limit 보다 훨씬 낮아야 한다.

SAP Notes 1999997 - FAQ: SAP HANA Memory -> 10. How can I judge if the available memory is sufficient for the current system and a projected future growth?

그러나 위의 법칙은 대략적인 지침일 뿐, 항상 예외는 있다.
테이블 데이터 사용량이 전체 메모리의 65% 여도 전혀 문제가 없을 수도 있으며, 분석과 성능 모니터링 상에 큰 문제가 없다면 그대로 운영될 수 있다.

단, 테이블 데이터가 전체 메모리의 50% 제한을 초과할 수록 메모리 회수 및 
리소스 컨테이너 축소로 인한 메모리 부족 이벤트 또는 장애가 발생할 확률 증가

SAP Notes 1999997 - FAQ: SAP HANA Memory -> 45. What is a good table memory share?

 

3-4. 메모리 사용 제한

HANA DB 의 메모리 사용에 대한 제한은 크게 다음 두가지로 나뉘어 진다.

 

3-4-1. global_allocation_limit

HANA DB 프로세스가 OS 에서 사용할 수 있는 메모리의 최대치이다.

기본 설정은 호스트에서 사용 가능한 물리 메모리 64GB 의 90% 에, 추가되는 각 GB 의 97% 를 더해 계산된다.
(간단히 물리 메모리의 97% 로 이해하면 된다.)

보통 해당 제한을 따로 사용할 필요는 없으나, 다음과 같은 상황에서는 사용을 고려할 수 있다.

• SAP HANA DB 라이선스 준수
• 단일 호스트에 둘 이상의 SAP 시스템이 설치된 경우
• OS 외부 프로그램에서 상당한 메모리가 필요할 경우

파라미터 설정 단위는 MB 단위이다.

SAP Notes 2926166 - How to limit the overall SAP HANA memory allocation

 

3-4-2. statement_memory_limit

단일 SQL 문에 대한 메모리 제한이다.

단일 SQL 문이 HANA DB 에서 한번에 너무 많은 메모리를 사용할때 제한할 때 사용된다.

호스트 별로 단일 SQL 메모리 제한을 할 수 있으며, 백업 종료 또는 중요한 비즈니스 쿼리등을 취소할 수도 있기 때문에, 적용 전 면밀한 검토를 하거나 충분히 큰 값으로 설정해야 한다.

단위는 GB 이며, 기본값 0은 메모리 제한이 없다는 뜻이다.

SAP Notes 3211034 를 통해 일반적인 상황에서 SAP 에서 권장하는 권장값을 계산할 수 있다.

SAP Notes 2926166 - How to limit the overall SAP HANA memory allocation

특정 사용자(DB User)에 대한 메모리 제한은 다음 Notes 를 참고하기 바란다.

SAP Notes 2383578 - How to set HANA memory limit for a particular database or application user

 

3-4-3. statement_memory_limit_threshold

해당 파라미터는 statement_memory_limit 적용 전의 조건에 대해서 설정한다.

조건이란, 현재 HANA DB 메모리 사용률이 global_allocation_limit 대비 설정된 임계값을 초과할 때만, statement_memory_limit 제한이 적용된다.

즉, 조금 더 유연하게 statement_memory_limit 제한을 적용한다.

단위는 %이며, 기본값 0은 조건과 관계없이 statement_memory_limit 를 바로 적용 하는 것이다.

 

간단한 예시를 위해, 아래 상황을 가정한다.

물리 메모리 : 100 GB
global_allocation_limit : 95 GB
statement_memory_limit : 2 GB
statement_memory_limit_threshold : 80% (76 GB)
현재 메모리 사용량 : 50 GB

설정된 statement_memory_limit_threshold 임계값은 80%, 즉, 76GB 이다.
현재 메모리 사용량 50 GB 이 임계값 76 GB (80%) 를 넘지 않았기 때문에 statement_memory_limit 제한은 걸리지 않는다.

이제 다음 상황이다.
시스템 사용량이 늘어 현재 메모리 사용량이 80 GB 가 되었다.
이때는 임계값 76 GB (80%) 를 넘었기 때문에 statement_memory_limit 제한이 적용되어, 2 GB 이상의 메모리를 사용하는 단일 SQL 문은 메모리 덤프로 취소된다.

 

4. SAP HANA DB FQA

Q. In-Memory 데이터베이스 이면 데이터가 메모리에 적제 되어 있다는 것인데 그럼 서버가 꺼지면 데이터도 소멸 되는가?

A. 데이터가 들어가는 순간에는 일단 메모리에 적제 되는 것이 맞지만 그와 별도로 하드디스크에도 메모리와 동일한 정보를 가질 수 있도록 동기화를 하는 작업이 있습니다. 하드디스크에도 데이터가 들어가 있기 때문에 데이터가 증발(!) 하는 일은 없습니다.

 

Q. 다른 DB 사용/개발자가 개발 할 수 있는 것 인가?

A. 오라클과 같은 RDBMS 기반 사용/개발자라면 크게 다르지 않을 것으로 보입니다. 저도 개발자는 아니지만, 듣기로는 결국 ANSI-SQL 이라 그냥 개발은 크게 문제는 없고 일부 HANA 에 특화 된 부분만 학습하면 된다고 합니다. 다만 이는 RDBMS 로서의 개발을 이야기 하는 것 이지 HANA DB 개발 전체를 다룰 수 있다는 것은 아닙니다.

 

Q. 기존 DB 대비 나은 것이 무엇인가? (SSD 디스크를 사용하는 오라클 DB vs SAP HANA DB)

A. 사람마다 견해가 다르기에 시장의 중론이 아닌 개인적인 입장을 적자면, 오라클 DB 는 기본적으로 쓰기속도를 고려하며 많은 데이터의 변동이 있는 경우에는 장점이 있지만 HANA DB 는 새로운 데이터보다 기존 데이터를 읽고 분석하는 입장에서 강점을 가지고 간다고 보입니다.

이 때문에 SAP 에서 계속 강조하는 "실시간 회사 정보의 전산화" 에 보다 적합하다고 할 수 있겠지요.

새로운 정보를 계속해서 입력하고 기존 정보를 변경해야 하는 작업이 많다면 큰 강점이 없지만, 이보다 기존에 쌓아 온 정보를 분석하는 입장에서는 이론적으로 훨씬 장점이 있습니다. 문제는 메모리에 적제하여 처리한다는 이 사상으로 인해 사실상 처리 데이터의 제한이 생길 수 밖에 없다는 아이러니함을 함께 가지고 있기도 하죠. (삼성전자의 메모리 크기가 어디까지 늘어날 수 있느냐에 따라 SAP HANA 도 가능성이 늘어나게 됩니다)