개요

시스템의 CPU부하는 기본적으로 응용프로그램(User) 및 커널(Sys/Kernel)에 의해 발생한다. 커널에 의해 발생되는 경우들은 일반적으로 시스템 리소스 사용에 대한 이벤트가 발생할 때이며 그 외의 경우들은 대부분 응용프로그램에 의해 사용된다.  Altibase의 경우는 사용자가 발생 시킨 질의처리(트랜잭션)를 위해 다양한 알고리즘이 적용되어 있고 DB에 접속한 클라이언트와의 통신 및 이중화, 데이터파일의 처리에 의한 디스크I/O등 다양한 시스템 리소스 사용이 발생함으로 User영역과 Sys/Kernel영역의 CPU사용이 모두 발생하게 된다.

본 문서에서는  Altibase가 점유하는 CPU사용률이 높아질 때 어떤 부분들을 살펴보고 정상/비정상 유무를 판단할 것 인지와 비정상적인 경우 어떤 형태로 해결할지에 대해 설명한다.

다음의 문서를 사전에 참고할 것을 권장한다.

•  『Altibase 개발 가이드』
•  『Altibase SQL 튜닝 가이드』
•  『Altibase 모니터링 쿼리가이드』

본 문서의 테스트 환경은 다음과 같다.

• Altibase : Altibase 6 이상 버전
• OS : Linux ( 2.6.32-504.el6.x86_64 )

CPU 과부하 현상에 대한 분석

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

일상적 점검사항

사용자는 현재의 CPU 부하의 정상유무를 판단하기 위해 다음의 이력관리가 필요하다.  Altibase 는 자체적으로 Altibase가 사용하는 CPU 사용률 정보를 제공하는 기능은 아직 없으므로 CPU 사용률은 OS에서 제공하는 command 를 사용하여야 한다.

select name,value from V$SYSSTAT where name in ( 'execute success count','prepare success count','prepare failure count');

아래와 같은  shell script를 이용하여 일정 간격으로 수집된 정보를 파일로 기록하는 방식이 좀 더 간편할 수 있다. 

V$sysstat로 구해지는 EXECUTE COUNT는 누적값이므로 단위 시간당 증가량을 구하기 위해서는    단위시간 증가값 = ( 최근값 - 이전값 ) 과 같은 방식으로 계산해야 한다.

위의 shell script를 실행하였을 때는 아래와 같이 출력될 수 있다.

위 이력정보를 통해 사용자는 다음과 같은 표 형태의 이력을 만들 수 있을 것이다. 단위시간당 증가량 은 엑셀(Excel) 의  셀계산 수식을 사용하는 것이 편리하다.

이와 같은 형태의 자료를 통해 일상적인 시점과 CPU과부하 시점의 부하차이가 트랜잭션 처리량의 증가로 인한 것인지를 먼저 판별할 필요가 있다.

일반적 분석절차

일반적으로  CPU 사용률을 증가시키는  원인으로   자주 분석되어지는  유형의 원인이 존재한다. 따라서 잘 알려진 유형의 문제에 해당하는 지 단계적으로 점검하는 방식이 효과적일 수 있다.

평상 시보다 더 많은 트랜잭션 처리가 발생했는가?  (1)

만일, '일상적 점검' 사항에 해당하는 '세션', '서비스쓰레드', 'Prepare/Execute'의 항목이 모두 증가수치를 보이면서 CPU사용량이 증가했다면 이는 정상적인 증가패턴이라 할 수 있다.

다음의 사항을 정상패턴과 구별하여 주의해야 한다.  사용자의 검증되지 않은 질의(장시간 수행되거나 대량의 변경작업을 유발하는 성격) 및 서비스로 인해 서비스쓰레드의 증가가 발생할 경우가 있다.
이는 서비스쓰레드의 자체적인 load-balancing기능에 의해 증가하는 유형이다.

패턴 자체는 정상적인 경우이며 이와 같이 증가되는 질의가 수행된 원인을 찾아야 하는데 보통 사용자가 임의로 수행한 질의가 수행되어 발생한 경우는 해당 시점이 아니라면 발견하기 어렵기 때문에 오랜 시간 동안 수행되는 질의가 존재하는지 주기적으로 다음 질의를 통해 서버를 관찰할 필요가 있다.

신규로 추가된 서비스(응용프로그램)가 발생했는가?  (2)

직접적인 원인일 가능성이 높음으로 새롭게 추가된 질의들에 대한 실행계획을 먼저 분석하고 실행시간과 Access-Cost가 높은 질의에 대해 적절한 튜닝작업을 진행하도록 해야 한다. 위에 언급되어 있는 악성질의 탐색방법을 통해 주기적인 관찰이 필요하다.

위 2가지 사항은 모두 결과적으로 서비스를 수행하는 응용프로그램들의 구조나 수행하는 질의가 대부분 잘못 구현된 경우들이다. (아래 설명할 Altibase의 질의처리과정의 CPU사용에 대해 참고)

그러나, (1)번, (2)번 항목을 확인하면 대부분 사용자들은 '그렇지 않다.'가 일반적인 답변이다. 그러면, 서비스 형상과 시스템에 아무런 변화가 없는 상태에서 Altibase버전도 변경이 없었다면 CPU과부하의 원인은 어디에 있을까?  

문제를 찾기 위해서는 현재 운영중인 프로그램과 DB에 대한 분석이 필요하다.

기 서비스 중인 응용프로그램의 문제분석  (3)

어떠한 서비스 운영의 형상변경이 없음에도 불구하고 CPU과부하를 일으킨다면 이는 데이터의 증가와 같은 원인으로 기존 질의가 본래 가지고 있던 문제점이 드러나는 경우를 가정해 볼 수 있다.
예를 들어, 기존에 사용하던 인덱스가 데이터규모가 작은 상황에서는 원활히 수행되었으나 시간이 경과하면서 데이터규모가 증가하고 이런 상황에서 적절하지 않았던 기존 인덱스가 사용된다면 CPU사용률이 증가하는 원인이 될 수 있음을 의미한다.

쿼리 플랜 변경으로 인한 쿼리 실행 Cost 증가로 인한 문제 (4)

Altibase 4 , Altibase 5 및 Altibase 6 일부버전(6.1.1.6.1 이후버전)  이상 버전은 옵티마이저가 사용하는 통계정보 수집동작이  특정 조건에 따라서 자동으로 실행되는 버전이다. 
주로 데이터 증가 및 DDL 수행( index 변경) 으로 인해서  통계정보가 갱신되는 경우가 많은 데  이 같은 경우  쿼리 옵티마이저가  새로운 쿼리 플랜을 선택하는 과정중에   이전보다 cost가 높은 잘못된 플랜을 선택하는 경우가  간혹  발생할 수 있다.

이와 같은 비효율적인  플랜을 통해서 실행되는 쿼리는  Access-cost를 크게 증가시켜  CPU 사용량 증가를 유발할 수 있다.  보통 이러한 경우  앞에 기술한   long-run 쿼리를 조회하는 쿼리를  통해서  문제 쿼리가 확인되는 경우가 많다.  

따라서 CPU 의 비정상적인 사용패턴이 발생할 경우는  모니터링 쿼리를 통해서  long-run 쿼리를 가장 먼저 확인해 보는 것이 효과적이다.  

확인된 long-run 쿼리는 쿼리 실행시 플랜을 보여주는 명령문을 실행한 후  문제 쿼리의  실행플랜을 확인해서 플랜의 문제점이 있는지 확인할 수도 있고  v$PLANTEXT 에 저장된 런타임 플랜을 조회해서 확인할 수 있다.

쿼리의 상태를 확인하는 방법은 "Altibase 모니터링 가이드" 문서에서 쿼리 상태 확인을 위한 다음의  쿼리를 실행해서 확인할  수 있다.

질의처리 과정의 CPU 비용

질의처리과정에서  Altibase가 CPU를 쓰게 되는 부분들에 대해 간략하게 설명한다.

응용프로그램 구현 형태에 따른 CPU 부하

Altibase의 질의처리는 크게 아래와 같은 과정을 거쳐 수행된다.

1) 질의의 문장/문법 오류 체크

2) 질의에 사용되는 테이블/칼럼의 존재 유무 체크

3) 최적의 실행 계획 수립

4) 데이터 영역에 접근하여 필요한 연산을 통해 데이터를 획득 및 변경

이런 과정 중 1) ~ 3) 을 Prepare-Validation-Optimization (PVO)라고 지칭하며  4)의 과정을 EXECUTE라고 한다. 일반적으로 PVO를 수행하는 과정이 질의전체의 처리과정에서 60~70%정도의 비중을 차지한다.

위 가정을 전제로 “동일한 질의를 매번 PREPARE-EXCUTE” 형태로 수행하는 게 얼마나 비효율적인 CPU사용을 유발하는지 짐작할 수 있다.

따라서, 개발자나 운영자는 v$sysstat을 통해 다음의 항목이 지나치게 증가하는 경우라면 반드시 응용프로그램의 반복적인 PREPARE를 수행하지 않도록 수정하거나 혹은  Altibase 5부터 제공하는 PLAN-CACHE기능을 활용할 것을 권장한다.

위의 Value 값이  지속적으로 크게 증가한다면  응용프로그램에서  지속적으로 Prepare 를 반복하는 부분이 있다는 것을 의미한다.

어떤 응용프로그램인지는  v$sysstat 정보를 세션단위로 상세하게 보여주는  또 다른  성능뷰인 V$sesstat 와  프로세스 PID를 보여주는  V$session 테이블의 조합으로 찾을 수 있다.

위와 관련된 자세한 사항은 “Altibase 개발 가이드” 문서를 참고하도록 한다.

데이터 스캔(Scan)에 의한 CPU 부하

• 메모리 테이블의 데이터 접근
  Altibase의  메모리테이블은 물리적인 시스템메모리에 모두 적재된 상태로 유지된다. 저장되는 단위는 32Kbyte의 페이지 단위로 저장되고 이 페이지 내에서도 레코드 저장에 적합한 테이블 별 개별단위(Slot)로 분할되어 있다.
  문제는, 테이블에 Full-Scan형태로 접근할 경우 테이블에 존재하는 모든 데이터에 대한 접근비용이 매우 크게 발생한다. 이런 질의가 동시에 여러 세션에서 수행한다면 CPU사용률은 급증할 수 밖에 없다.
  그럼, 인덱스를 사용하는 경우는 반드시 CPU사용률은 낮아지는가?
  반드시 그렇지는 않다. 메모리테이블의 인덱스 역시 시스템메모리에 존재한다. 하지만, 메모리테이블의 인덱스에는 실제 데이터 값이 존재하지 않는다. 다만, 시스템메모리상의 데이터가 위치한 물리적 포인터 값을 가지고 있고 이 포인터 값이 인덱스 키값과 함께 연산되어 변환된 값 형태로 정렬되어 존재한다.
  따라서, 인덱스가 가리키는 실제 물리적인 데이터에 매번 접근하여 데이터 값을 획득하고 비교하는 과정을 거치게 된다. (이 과정이 불합리하게 보일지 모르지만 상대적으로 성능측면에서는 디스크I/O를 유발하지 않아 다른 DBMS가 I/O로 인한 대기시간이 요구되는 상황에서도 CPU를 점유하여 더 많은 트랜잭션의 처리가 가능하다)
  따라서, 인덱스를 이용한 질의라 하여도 Access-Cost가 많을수록 CPU사용률은 상대적으로 증가하게 되기 때문에 사용자는 정기적으로 서비스 운영에 수행되는 질의의 실행계획을 모니터링 하여 비효율적인 질의를 제거하는 노력을 수행해야 한다.
  
  
• 디스크 테이블의 데이터 접근
  디스크테이블에 대한 설명은 다음과 같이 I/O측면의 CPU사용에 대한 이해를 필요로 한다. 일반적으로 OS는 File-Cache라는 메모리영역을 할당하여 파일I/O가 빈번하게 발생하여도 미리 메모리상에 적재해둠으로써 I/O성능을 보장하려 한다.
  하지만, 대부분의 RDBMS는 자체적인 버퍼를 중간에 두어 이러한 효과를 얻어내기 때문에 일반적으로 파일시스템이 Direct I/O를 지원한다면 File-Cache를 사용하지 않고 Direct I/O를 이용하도록 권장하고 있다.
  Buffered I/O는 응용프로그램의 코드상으로 Read/Write System-Call처리에 대한 CPU자원을 이용하고 OS정책에 의해 File-Cache에 기록된 내역들이 디스크에 Sync되는 과정에서 CPU자원이 소모되는데 이 시점에 I/O작업이 완료될 때까지 대기가 발생하고 CPU사용률은 낮아지는 것처럼 보이지만 이때의 CPU자원을 다른 응용프로그램이 사용할 수 없음으로 서비스 처리는 감소할 가능성을 가지고 있다.
  이를 반대로 생각하면 Direct I/O를 이용할 경우 CPU는 I/O자체를 I/O전담채널에 일임하게 된다. 따라서, CPU가 I/O처리를 위해 대기할 필요가 없어지고 그 자원을 다른 응용프로그램들이 점유할 수 있으며 상대적으로 서비스 처리도 그만큼 더 수용 가능하다. 하지만, 상대적으로 Buffered I/O에 비해 CPU사용률은 마치 증가한 것과 같이 사용자가 판단할 수 있다.
  Buffered I/O 와 Direct I/O 의  설정방법과 동작방식에 관한 설명은  " 디스크 I/O 병목을 고려한 볼륨구성 가이드" 를 참고하기 바란다.
  요약하면 Buffered I/O 또는, Direct I/O의 설정은 모두가 CPU사용과 성능에 대해 Trade-off를 가지기 때문에 어느 것이 적합하다는 답은 없으며 사용자의 서비스환경에 맞게 적절히 설정하도록 한다.

정리

앞에서 설명한 몇 가지 과정들이 모두 CPU자원을 필요로 하고 결과적으로 질의처리과정 자체가 CPU를 낮게 사용하면서 빠른 성능을 내야 한다는 것은 개념적으로 불가능하다. 다만, 효율적으로 CPU를 사용하면서 요구되는 성능을 발휘하는 것은 사용자/개발자의 노력에 따라 가능한 일이라 할 수 있겠다.

기타 사례를 통한 CPU 문제들

성능이 원하는 수준은 아니지만 CPU도 예상 수치만큼 사용하지 않는 경우들이 발생할 수 있다. 이러한 현상들은 다음과 같은 경우들을 고려해야 한다.

DB와 응용프로그램 Character Set 불일치

문자 셋(NLS_USE)의 설정이 DB와 응용프로그램이 다른 경우 내부적인 문자 셋의 변환작업(Encoding)으로 인해 Altibase 성능이 저하되고 CPU사용량이 높아지는 현상이 보고된 사례가 있다.  이 경우 DB서버와 응용프로그램간의 문자 셋을 일치시켜 문제를 해결한다.

서비스쓰레드 증가

Altibase 4.3.x버전대는 'Dedicated Thread'의 증가로 인한 'Select-Poll' system-call에 의한 CPU사용량이 증가하는 경우가 보고된 사례가 있다.
Altibase는 세션의 접속을 'Service Thread'가 담당하여 트랜잭션을 처리하는데 Long-run질의가 발생하거나 모든 'Service Thread'가 실행(Executing)상태가 되면 새로운 접속이나 대기하는 트랜잭션들을 처리하기 때문에 별도의 새로운 'Dedicated Thread'를 실시간으로 생성하게 된다.
새롭게 생성된 'Dedicated Thread'들이 자신이 처리할 트랜잭션이 존재하는지 주기적으로 체크하게 되는데 이 과정에서 ALTIBASE는 'Select-Poll' system-call이 많아지고 CPU사용량 중 sys(%)사용량이 증가하는 패턴을 보인다.

아래의 쿼리로 DB의 서비스쓰레드 상태를 조회할  수 있다.

 이런 유형에 대비하여 'MULTIPLEXING_POLL_TIMEOUT'이란 속성값을 증가시키는 방안이 있는데 이것은 'Select-Poll' system-call의 수행주기를 증가시켜 system-call의 횟수를 감소시키는 것이다.
근본적으로 사용자는 'Dedicated Thread'가 발생하는 이유가 세션의 증가, 트랜잭션의 부하증가, 다수의 Long-Run질의, 락 경합 등에 의한 경우임으로 이런 상황들을 원천적으로 해소할 개선방안에 대해 고민해야 한다.

OS 환경변수 설정의 영향

OS 환경변수 설정에 따른 CPU사용량의 변화가 있을 수 있는데 Altibase는 멀티쓰레드 구조를 채택하기 때문에 OS의 설정에 대해 이와 관련된 설정을 적절하게 할 필요가 있다. 해당 설정은 CPU사용량의 감소측면이 아니라 CPU를 사용하는 만큼의 성능을 나타내지 못하는 경우들에 대한 설정으로 이해하면 된다.

자세한 사항들은 OS별로 제공되는 'Altibase 설치가이드'를 참고한다.

빈번한 DB Connection 시도

Altibase의 v$statement에는 현재 접속된 세션이 수행한 질의에 대한 실행정보를 가지고 있다. 따라서, Connect/Disconnect의 반복적 수행이 발생하는 구조에서는 이 정보에서 악성질의를 탐색하기가 매우 어렵다.

• 빈번한 DB 접속이 발생하는지 여부의 확인
  아래의 쿼리로 확인할 수 있다.

• 프로파일링을 통한 튜닝 대상 쿼리의 선정
  더더욱, 매번 Connect/Disconnect의 비용만큼 응용프로그램의 성능도 저하될 수 밖에 없다. 따라서, 사용자는 이와 같은 응용프로그램의 구조를 DB에 연결된 상태에서 처리되도록 변경하는 것이 바람직하며 이것이 불가능할 경우 DB의 성능저하를 감수하더라도 다음과 같이 프로파일링 기능을 통해 악성질의를 탐색해야 한다.

  위 기능을 수행한 이후 수행된 모든 질의는 $ALTIBASE_HOME/trc/xxxxx.prof라는 확장자가 '*.prof'라는 파일명으로 기록이 된다. 이 파일은 바이너리 파일로 만들어져 사용자가 바로 확인할 수 없으며 다음과 같이 일반 텍스트형태로 변환을 해야 한다.

  'altiProfile'은 Altibase에서 제공되는 분석 유틸리티이며 이를 이용해 분석용 파일을 만들 수 있다. 해당 파일에는 실행된 '질의문', '수행시각의 상세정보' 등이 기록되어 있기 때문에 해당 내역을 기반으로 수행시각이 오래 걸린 악성질의를 찾을 수 있다.

  altiProfile 의 자세한 사용법은  AID의 FAQ 에서 참조할 수 있다. (  Altibase에서 수행된 쿼리 로그로 남기는 법에 관한 AID 설명 페이지 : http://aid.altibase.com/x/ygSL )

  Icon

  ※ 프로파일링 기능은 DB의 성능저하 및 로그기록으로 인한 디스크부족을 유발할 수 있음으로 사용에 신중한 주의가 필요함.

요약

앞에서 설명한 대로 각 항목들에 대해 사용자가 어떻게 일상적으로 점검하고 CPU과부하에 대한 원인을 찾을지에 대해 정리한다.

단계적 점검방법

분석을 위한 데이 수집

현재의 CPU 부하가 정상적인지 유무를 판단하기 위한 데이타를 수집한다.  OS에서 제공하는 command와   앞서 설명한  "일상적 점검사항"에서와 같이 Altibase의  시간대별/일별 CPU 사용량, 트랜잭션 처리량등의 정보를 수집한 후 트랜잭션처리량의 증가로 인한 정상적인 CPU 사용량 증가인지 여부를 판단한다.

원인 분석

1. 응용프로그램 변경의 영향과 관련이 있는지 점검
   신규로 추가된 서비스(응용프로그램) 이 있으며 신규 추가된 서비스의 운영시점과 CPU 부하량 증가시점이 일치한다면  신규 추가된 서비스의 연관성을 확인해 볼 필요성이 있다.
   
   
2. 데이터 증가와의 관련성 및 쿼리 플랜 변경 유무 확인
   시간이 경과하면서 데이터 누적으로 인해서 Access 비용으로 인한 CPU증가 인지 여부를 확인해야 한다.   Altibase 구버전(6.1.1 이하) 은  통계수집이 특정 조건에 따라서 자동으로 이루어지는 기능을 갖고 있다. 통계 정보 갱신으로 인해서  옵티마이저가 기존에 돌던 쿼리의 플랜보다  비효율적인 플랜을 선택 사용한 경우 이로 인한 Access cost 증가는 CPU 사용량 증가를 유발할 수 있다.
   
   
3. DB와 응용프로그램 Character Set 불일치
   문자 셋(NLS_USE)의 설정이 DB와 응용프로그램이 다른 경우 내부적인 문자 셋의 변환작업(Encoding)으로 인해 Altibase 성능이 저하되고 CPU사용량이 높아지는 현상이 보고된 사례가 있다.
   
   
4. 서비스쓰레드 증가
   세션 요청을 처리하는  dedicated 서비스쓰레드가 증가한 상태인 경우 주기적으로 요청이 존재하는지 여부를 검사하기 위한  'select-poll'  system call 함수의  증가로 인해서  sys CPU 사용량이 증가하는 경우가 있다.
   
   
5. OS 환경변수의 영향
   OS 환경변수 설정에 따른 CPU사용량의 변화가 있을 수 있는데 Altibase는 멀티쓰레드 구조를 채택하기 때문에 OS의 설정에 대해 이와 관련된 설정을 적절하게 할 필요가 있다.
   
   
6. 빈번한 DB Connection 시도
   DB에 접속하고 해제하는 과정은 DB 자원을 소모하는 작업이며  반복적인  DB 접속/해제를 하는 구조에서는 악성질의를 탐지하기도 어렵다.  또한  Statement 를  Prepare하고 사용할 수 없으므로  쿼리의  성능 저하의 요인이 될 수도 있다.

OS 유틸리티를 통한 탐색

Altibase는 Multi-Thread Architecture를 채택하고 있다. 따라서, 내부의 특정 쓰레드가 비정상적으로 CPU를 많이 사용하지 않는지 파악해볼 필요가 있다. 이 경우 OS별로 제공되는 유틸리티를 통해 쓰레드별 CPU사용량 및 현재의 상태를 알아낼 수 있는데 관련된 자세한 방법은 다음 문서를 참고하도록 한다. 

('문제분석을 위한 OS별 유틸리티 가이드' 문서 참고)