SAP HANA DB 를 간단하게 설명하면, Column 중심의 in-memory 관계형 데이터베이스 이다.
in-memory DB이기 때문에 서비스 시작 시, 대부분의 DB 데이터를 메모리에 올려서 서비스를 한다.
Row 기반 테이블은 전부 메모리에 올라가게 되고, Column 기반 테이블은 선택적으로 메모리에 올라가게 된다.
그외 여러 데이터들이 메모리에 올라가게 되기에, HANA DB 를 효과적으로 관리하기 위해서는 메모리 구조를 알아야 한다.
HANA DB 의 메모리 구조를 설명하는 그림이다.
SAP Notes 1999997 - FAQ: SAP HANA Memory
간편한 설명을 위해서, HANA DB 메모리를 조금 더 간단하게 도식화하여 설명하려고 한다.
아래 그림은 시간에 따른 다양한 메모리에 대한 측정값의 예시이다.
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 증가)
Virtual Memory 를 사용하여 실제 메모리를 할당(점유) 받은 메모리이며, OS 에서 HANA DB 가 실제 사용하고 있는 메모리이다.
사용에 따라 Resident Memory 는 교체 될 수 있고, 반환한 메모리는 Memory Pool 로 재활용된다.
사용 메모리에는 프로그램 코드와 스택, 모든 테이블 데이터와 시스템 테이블, 임시 계산에 필요한 메모리가 포함된다.
프로그램 코드 및 스택의 크기는 약 6GB 정도이며, 대부분의 메모리는 테이블 저장 및 임시 계산, 데이터베이스 관리에 사용된다.
위에 메모리 구조와 in-memory DB 특성을 고려하여 HANA DB 의 메모리를 관리해야 한다.
다음과 같은 사항을 확인하여 점검해볼 필요가 있다.
OS 수준에서 SWAP 의 크기가 크다면, HANA DB 가 SWAP 메모리까지 사용하여 SWAP 관련된 경고를 볼 수 있다.
따라서, SAP 에서는 적은 양의 SWAP 을 설정을 것을 권장하고 있다. 공식적으로 SAP 에서 권장하는 DB 서버의 SWAP 의 양은 2 GB 정도이다.
HANA DB 를 계속 운영하다보면 Resident Memory 가 지속적으로 늘어나게 된다.
이는 정상적인 운영 환경이라면 메모리 누수와 같은 문제가 아닌 정상적인 HANA DB 동작으로 본다.
결과적으로 HANA Studio 나 Tcode DBACOCKPIT 과 같은 모니터링 도구에서 Resident Memory 사용량의 빨간색 경고는 무시될 수 있다.
대신, 포인트는 Used Memory 부분이다. 할당 제한에 근접하지 않는지 확인해야 하며, 해당 메모리를 모니터링해야 한다.
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?
HANA DB 의 메모리 사용에 대한 제한은 크게 다음 두가지로 나뉘어 진다.
HANA DB 프로세스가 OS 에서 사용할 수 있는 메모리의 최대치이다.
기본 설정은 호스트에서 사용 가능한 물리 메모리 64GB 의 90% 에, 추가되는 각 GB 의 97% 를 더해 계산된다.
(간단히 물리 메모리의 97% 로 이해하면 된다.)
보통 해당 제한을 따로 사용할 필요는 없으나, 다음과 같은 상황에서는 사용을 고려할 수 있다.
파라미터 설정 단위는 MB 단위이다.
- SAP Notes 2926166 - How to limit the overall SAP HANA memory allocation
단일 SQL 문에 대한 메모리 제한이다.
단일 SQL 문이 HANA DB 에서 한번에 너무 많은 메모리를 사용할때 메모리 사용을 제한하기 위해 사용된다.
호스트 별로 단일 SQL 메모리 제한을 할 수 있으며, 백업 종료 또는 중요한 비즈니스 쿼리등을 취소할 수도 있기 때문에, 적용 전 면밀한 검토를 하거나 충분히 큰 값으로 설정해야 한다.
단위는 GB 이며, 기본값 0은 메모리 제한이 없다는 뜻이다.
SAP Notes 3211034 를 통해 일반적인 상황에서 SAP 에서 권장하는 권장값을 계산할 수 있다.
특정 사용자(DB User)에 대한 메모리 제한은 다음 Notes 를 참고하기 바란다.
- SAP Notes 2383578 - How to set HANA memory limit for a particular database or application user
해당 파라미터는 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 문은 메모리 덤프로 취소된다.