Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents
maxLevel2

 

 

개요

...

시스템의 메모리사용량 증가로 인한 문제는 기본적으로 응용프로그램(User) 및 메모리테이블스페이스의 데이터 증가에 의해 발생한다. 응용프로그램에서 사용되는 쿼리로 인해 데이터베이스의 메모리적재가 일어나고 이로인해 가용메모리의 부족이 발생할수 있으며, Altibase의 고성능 데이터 처리를 위해 메모리테이블스페이스로 데이터를 관리할때 누적된 데이터로 인한 저장공간이 늘어나고 이로인한 가용메모리의 부족이 발생할수 있다.

...

Note

이 문서는 정보 제공을 목적으로 제공되며, 사전에 예고 없이 변경될 수 있습니다. 이 문서는 오류가 있을 수 있으며, 상업적 또는 특정 목적에 부합하는 명시적, 묵시적인 책임이 일절 없습니다.

이 문서에 포함된 Altibase 제품의 특징이나 기능의 개발, 발표 등의 시기는 Altibase 재량입니다.

Altibase는 이 문서에 대하여 관련된 특허권, 상표권, 저작권 또는 기타 지적 재산권을 보유할 수 있습니다.

 

 

Memory 사용량 일상적 점검

...

서비스 운영 중에 갑작스런 메모리 부족에 의한 서비스 지연이 발생할 수 있는데 이 과정에서 지속적으로 메모리 부족 현상이 발생할 때 사용자가 확인할 부분과 해결방안에 대해 설명한다.

 

OS별 시스템 메모리/Swap 확인 방법

...

장비의 여유 메모리가 부족한지 여부는 OS명령어를 이용하여 가용 메모리를 확인 할 수 있다.

...

  • AIX

    항목(붉은 박스)설명
    size전체 물리적 메모리의 페이지 개수를 의미한다. 실제 1page는 4,096byte임으로 7936M의 메모리를 갖는 시스템임.
    inuse(Computational + Persistent)의 실제 사용 중인 물리적인 메모리의 페이지 개수
    free물리적 메모리에서 사용 중이지 않은 페이지 개수
    pinSwap out할 수 없는 물리적 메모리의 페이지 개수
    virtualVMM (Virtual Memory Manager)에 의해 생성된 페이지 개수
    pg spacePaging space 공간의 사용량


  • HP-UX

    # glance -> m 메모리 확인


    현재 물리적인 메모리 32.0GB - 시스템 9.6GB + 유저 13.8GB + 파일캐쉬 722MB - 버퍼캐쉬 0GB + 프리 7.9GB (사용가능한 메모리량)


  • Linux

    Linux에서는 메모리 사용 현황을 top 명령으로 조회할수 있으며, 아래는 top 결과 샘플이고 샘플내의 여러 항목들 중에서 free 와 cached의 값이 주요 항목이다.


    linux에서 가용메모리 계산은 free + buffers + cached로 할수 있다.

    위의 top 명령 결과로 메모리 용량을 분석해 본다면,

    - 전제 물리 메모리 : 16630888k - 실제 사용중인 메모리(used - cached - buffers) : 16559108k - 16034200k - 100516k = 424392k - 실제 가용한 메모리 (free + buffers + cached) : 71780k + 100516k + 16034200k = 16206496k - 전체 메모리(실제 사용중인메모리 + 실제 가용한메모리) : 424392k + 16206496k = 16630888k

    아래는 free명령을 통해 조회한 결과이다.(-m 옵션은 MB단위 출력지정)


 

일상적 점검 사항 

...

사용자는 현재의 메모리 사용량에 대한 정상유무를 판단하기 위해 다음의 이력관리가 필요하다. 이것은 문제상황이 발생할 때 정상 대비 증가된 부분을 분석하여 원인을 추적하는데 중요한 정보로 활용이 가능하다.

...

Code Block
themeDJango
languagebash
$ sh get.sh
20170213 110718: CPU USAGE= 7.1  MEM USAGE= 0.6 SESSIONCNT=1 THREADCNT=25 EXECCNT=1201
20170213 110748: CPU USAGE= 7.1  MEM USAGE= 0.6 SESSIONCNT=1 THREADCNT=25 EXECCNT=1202
20170213 110818: CPU USAGE= 7.1  MEM USAGE= 0.6 SESSIONCNT=1 THREADCNT=25 EXECCNT=1203
......

 

V$MEMSTAT 

...

V$MEMSTAT는 Altibase가 제공하는 내부 모듈 별 메모리 사용량에 대한 Performance View이다.

...

항목설명
Query_PrepareSQL 처리 시 Prepare 과정에서 SQL 문장 분석, 통계정보, 실행계획, 바인딩 등의 정보를 내부적으로 관리하기 위한 메모리를 필요로 한다.일반적으로 어플리케이션에서 SQL이 매번 Prepare, Execute 구조로 수행되면(Direct Execute 방식) 이 항목의 메모리 사용량이 증가할 수 있다.
SQL 수행 시 Prepare Execute 방식(1번 Prepare + N번 Execute) 으로 수행하면 이 항목의 메모리 사용량은 어느 정도 증가 후 운영 중 일정 크기를 유지하게 된다.이 값은 모든 세션에서 사용하는 Query_Prepare 의 전체 크기이다.
Query_ExecuteSQL 실행 과정에서 데이터 Sort 및 중간 결과 값을 저장하기 위해 사용하는 메모리 크기를 나타낸다.
메모리 테이블 또는 TEMP_TBS_MEMORY 힌트를 사용한 SQL 실행 시 증가할 수 있다.
이 값은 모든 세션에서 사용하는 Query_Execute 의 전체 크기이다. AltibaseSQL 실행 종료 시점에 메모리는 해제된다. 따라서 정상적인 경우에 어느 정도 증가했다가 감소하며 운영 중 일정 크기를 유지하게 된다.
Query_BindingSQL 실행 과정에서 바인딩 변수를 저장하기 위한 메모리 크기를 나타낸다. 이 값은 하나의 SQL에 사용된 바인딩 변수에 영향을 받는다.PrepareStatement 를 close 하거나 세션 종료 시 메모리를 반환하므로 정상적인 경우에 어느 정도 증가했다가 감소하며 운영 중 일정 크기를 유지하게 된다.일반적으로 Query_Binding 가 증가하는 사례는 아래와 같다.
1) statement 들이 급격하게 증가한 경우
2) 너무 큰 데이터형에 대하여 binding을 수행
3) PrepareStatement 를 제대로close 안하였을 경우
4) exception 처리 시 무한 반복하여 prepare statement를 발생시킨 경우
Storage_Memory_Manager메모리 테이블스페이스 관리를 위한 정보와 메모리 테이블의 데이터가 저장되는 공간으로, Altibase의 고성능 데이터 처리를 위해 메모리에 상주된 메모리 데이터의 크기이다.메모리데이터의 누적되어 커질경우 이 항목의 값이 증가한다.
Index_Memory메모리 테이블에 생성한 인덱스를 위한 메모리 사용량을 보여준다.이 값이 증가하는 것은 메모리 인덱스의 사용량이 증가했음을 의미한다. 메모리를 많이 소비하는 인덱스를 제거하여 메모리를 정리할 수 있다.
Storage_Disk_Buffer

디스크 버퍼 관리자에 의해 사용되는 메모리로, 디스크 테이블스페이스 의 데이터를 메모리에 버퍼링하여 데이터를 처리하는 공간이다.

이 공간이 작으면, 디스크 페이지의 In/Out 의 자주 발생하게 되어 성능이 저하될수 있다

 

 

Altibase 프로세스 메모리 사용량 증가에 대한 원인과 조치

...

Altibase의 메모리가 아닌 다른 프로세스로 인하여 증가된 메모리는 여기에서 다루지 않고, Altibase의 프로세스 메모리의 증가부분에 대한 조치방법을 설명한다.

...

  위와 같은 대표적인 경우들에 대해 원인과 조치방법에 대해 자세히 살펴보도록 한다.

 

메모리 테이블의 데이터 증가

...

아래의 SQL 문장으로 메모리 데이터 사용량 증가 추이를 살펴본다. 

...

  1. 해당 테이블을 Compaction한다.
    메모리 테이블은 메모리 테이블스페이스로부터 공간을 할당 받게 된다. 하지만 하나의 테이블의 대량의 데이터 적재/삭제로 공간이 증가하면 동일 메모리 테이블스페이스에 존재하는 다른 테이블들이 할당 받을 공간이 부족해질 수 있음으로 더 이상 사용하지 않는 테이블의 공간을 동일 메모리테이블스페이스 내의 다른 테이블이 가용할 수있도록 반납할 수 있는데 이를 Compaction이라한다.

    Code Block
    themeDJango
    languagesql
    ALTER TABLE table_name COMPACT;
  2. Altibase를 재구동한다.
    위와 같은 조치를 취하면 동일 메모리테이블스페이스 내의 다른 테이블들이 공간을 할당 받을 수 있도록 1 차적인 조치가 가능하다. 그러나 여전히 OS에서 점유한 메모리 사용량은 줄어들지 않는다. 이 경우 Altibase를 재 구동하게 되면 메모리 사용량을 줄이는 것과 같은 효과를 나타낼 수 있는데 이는 다음과 같은 이유로 가능하다.
    원래의 재 구동과정에서는 모든 메모리 테이블스페이스의 데이터페이지를 메모리로 적재하지만 실제 데이터가 쓰여지지 않는 빈 페이지들은 메모리로 올리지 않기 때문에 메모리 사용량을 감소시키는 효과를 볼 수 있다.
    만일, 사용자가 일일이 테이블에 대한 Compaction을 하기 힘들다면 정기적인 PM과정에서 Altibase를 재 구동을 통해 Compaction 효과를 볼수 있다.

 

실행되는 SQL 문장의 수 증가

...

주기적으로 v$statement에 기록된 질의의 개수를 통해 확인이 가능하다. v$statement에 기록된 질의들은 현재 접속된 세션에서 수행한 질의만을 기록하기 때문에 정확하지 않으나 개략적인 개수를 파악하는 것에는 도움이 된다.

...

  1. 모든 질의는 사용 후 Close되는지 여부의 확인
    일반적으로 질의가 사용된 후에는 해당 질의에 대한 객체를 종료해야 한다.

    Code Block
    themeDJango
    languagejava
    ex) JAVA/JDBC
    Connection cn;
    prepareStatement ps;
    ps = cn.prepareStatement ("select…");
    …
    ps.close();

    위의 짧은 코드에서 만일, 'ps.close'와 같은 구문이 존재하지 않으면 ALTIBASE 내부 모듈 중 'Query_Prepare'등에 해당 질의에 대한 정보유지를 위해 메모리를 지속적으로 유지하고 이러한 상황이 반복되면 세션이 종료되지 않는 이상 메모리는 계속 사용되게 된다.

    한번 사용된 메모리는 Altibase자체적으로 Free시켜도 실제 OS에서 바로 회수하지 않기 때문에 결과적으로 메모리 사용량이 늘어난 상태로 운영되게 된다.
    따라서, 질의수행에 사용된 객체가 정상적으로 해제되는지 여부를 확인하도록 해야 한다.

     

  2. 비슷한 질의가 계속 사용되는 경우의 확인
    다음의 예를 살펴보자.

    Code Block
    themeDJango
    languagesql
    SELECT 1 FROM DUAL WHERE C1 = 1;
    SELECT 1 FROM DUAL WHERE C1 = 2;
    SELECT 1 FROM DUAL WHERE C1 = 3;

    위 질의는 “SELECT 1 FROM DUAL WHERE C1 = ?”과 같은 구문으로 대체하고 조회 조건의 변수 값만 바뀌는 형태로 개발하면 하나의 문장으로 해결할 수 있다.

    위와 같은 비슷한 질의들을 누적해서 실행할 경우 Altibase의 현재 버전에서는 각각 다른 질의로 분석하여 메모리를 할당하게 된다.

 

MVCC(Multi Version Concurrency Control) 기법에 의한 증가

...

MVCC기법은 조회/변경연산이 서로 대기하지 않도록 하여 성능을 높이는 DBMS의 일반적 동시성 제어기법을 의미한다. 현재 Altibase메모리 테이블은 변경연산 시점에 레코드의 복제 본을 생성하고 그 복제 본에 변경된 정보를 기록하는 형태로 동작한다.

...

예를 들어, 천만 건의 레코드를 변경해야 한다면 몇 만 건씩 단위작업으로 나누어 변경작업을 수행하도록 한다. (LIMIT절 사용)

 

Aging 지연에 의한 증가

...

앞서 설명한 MVCC에 의해 생성된 복제 본이 Commit시점에는 최종 레코드가 될 것임으로 원본 레코드는 삭제 대상이 된다. 만일, Rollback이 되면 복제 본은 삭제 대상이 된다. (이러한 삭제 대상 레코드를 “Old Version” 혹은 “Garbage Data”라고 하며 삭제 하는 작업을 내부적으로 Aging이라는 용어를 사용하고 GC (Garbage Collector)라는 내부 모듈이 담당)

...