2. Altibase 서버 튜닝#
이 장은 Altibase 서버를 운영할 때 고려해야 하는 요소를 설명한다.
-
로그 파일
-
체크포인트
-
버퍼
-
서비스 쓰레드
-
가비지 콜렉터
-
SQL Plan Cache
-
CPU 사용률
로그 파일#
Altibase는 새로운 로그 파일이 생성될 때, 트랜잭션의 응답 시간이 늦어지는 것을 방지하기 위해 로그 파일을 미리 생성해 둔다. 그러나 여분의 로그 파일이 부족한 경우, 트랜잭션들이 대기하는 상황이 발생하므로 데이터베이스 성능이 전반적으로 떨어진다.
아래는 미리 만들어둔 로그 파일의 여분이 부족해서 로그 파일이 생성되기를 기다린 횟수를 확인하는 쿼리이다.
SELECT LF_PREPARE_WAIT_COUNT FROM V$LFG;
이 값이 크다면 PREPARE_LOG_FILE_COUNT 프로퍼티의 값을 더 큰 값으로 설정하여 로그 파일 매니저가 충분한 개수의 로그 파일을 미리 만들도록 한다. 단, 이 값이 클수록 서버가 사용하는 메모리량이 증가하므로 무조건 크게 하는 것은 바람직하지 않다. PREPARE_LOG_FILE_COUNT 프로퍼티에 대한 설명은 General Reference > 2장. Altibase 프로퍼티를 참조한다.
체크포인트#
Altibase는 체크포인트를 수행 중 디스크 I/O 부하로 성능이 저하될 수 있다. $ALTIBASE_HOME/trc/altibase_sm.log에 기록되는 체크포인트 트레이스 메시지 중 아래 메시지를 출력하는 3, 4 단계에 소요되는 시간이 길다면 디스크 I/O를 모니터링할 필요가 있다.
[CHECKPOINT-step3] Flush Dirty Page(s)
[CHECKPOINT-step4] sync Database File
sar, iostat 등의 커맨드를 사용해서 디스크 I/O의 병목을 확인할 수 있다.
$ sar 1 3
Linux 2.6.32-431.el6.x86_64 (qar6) 05/07/2025 _x86_64_ (8 CPU)
11:04:36 AM CPU %user %nice %system %iowait %steal %idle
11:04:37 AM all 2.39 0.88 0.63 11.18 0.00 84.92
11:04:38 AM all 0.88 1.64 0.75 10.44 0.00 86.29
11:04:39 AM all 1.01 2.27 0.88 9.58 0.00 86.25
Average: all 1.43 1.59 0.76 10.40 0.00 85.82
$ iostat 1
Linux 2.6.32-431.el6.x86_64 (qar6) 05/07/2025 _x86_64_ (8 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
1.78 0.00 1.39 0.07 0.00 96.76
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 1.57 4.84 78.20 71446842 1155611156
sdb 0.93 7.51 99.57 110980563 1471359736
avg-cpu: %user %nice %system %iowait %steal %idle
1.53 0.00 1.65 0.00 0.00 96.82
만약 디스크 I/O의 병목이 성능 저하의 원인이라면 로그 파일과 데이터 파일이 저장되는 디스크를 분리해서 문제를 해결할 수 있다.
또는 아래의 체크포인트 관련 프로퍼티 값을 조절해서 디스크 I/O 분산 효과를 기대할 수도 있다. 단 이 방법으로는 로그 파일의 개수가 증가하는 부작용이 생길 수도 있다.
-
CHECKPOINT_BULK_WRITE_PAGE_COUNT
체크포인트시 메모리의 더티 페이지들을 여러 번에 나눠서 디스크로 저장할 수 있다. 이 때 이 프로퍼티는 한 번에 디스크로 기록하는 더티 페이지의 개수를 설정한다.
-
CHECKPOINT_BULK_WRITE_SLEEP_SEC / CHECKPOINT_BULK_WRITE_SLEEP_USEC
CHECKPOINT_BULK_WRITE_PAGE_COUNT의 값이 0이 아닐 때 더티 페이지들을 디스크로 저장 후 대기하는 시간(초, 마이크로초)을 설정한다.
-
CHECKPOINT_BULK_SYNC_PAGE_COUNT
체크포인트를 할 때 메모리와 디스크의 데이터를 몇 개의 페이지 단위로 일치시킬 것인지를 설정한다.
체크포인트에 대한 설명은 Administrator's Manual > 8. 트랜잭션 관리 > 체크포인트를 참고하기 바란다.
버퍼#
Altibase 서버는 디스크 테이블의 경우 한정된 메모리 버퍼에 데이터를 적재한 후 액세스한다. 따라서 최적화되지 않은 쿼리로 인해 잦은 디스크 I/O가 발생하는 경우 성능 저하를 유발할 수 있다.
버퍼 관련 정보는 V$BUFFPOOL_STAT 성능 뷰를 조회하여 파악할 수 있다.
SELECT HIT_RATIO 'HIT_RATIO(%)', VICTIM_SEARCH_WARP
FROM V$BUFFPOOL_STAT;
V$BUFFPOOL_STAT 성능 뷰의 HIT_RAIO 칼럼 값이 작으면 메모리 버퍼 대신에 디스크로부터 읽기(read page) 횟수가 많음을 나타낸다. 즉 이 값이 작으면, Altibase 서버가 빠른 질의 처리를 못하고 있음을 보여준다.
또한 V$BUFFPOOL_STAT 성능 뷰의 VICTIM_SEARCH_WARP 칼럼 값이 계속 증가하고 있다면, 플러셔의 페이지 플러쉬 작업이 밀리고 있음을 나타낸다. 디스크 테이블에서 많은 페이지를 액세스하는 쿼리를 튜닝하거나, BUFFER_AREA_SIZE 프로퍼티 값을 늘려서 이러한 문제를 해결할 수 있다.
통계 정보는 서버가 시작한 이후부터 누적된 값이므로 특정 기간 동안의 값을 알기 위해서는 모든 칼럼에 대해 다음의 방법으로 계산해야 한다: (현재의 값 - 측정 시작 시점의 값).
서비스 쓰레드#
서버에서 클라이언트의 요청을 받아 질의를 수행하는 쓰레드를 서비스 쓰레드라 한다. Altibase 서버는 아래의 두 가지 모드로 서비스 쓰레드를 생성하고 운용한다.
-
전용 쓰레드 모드(Dedicated Thread Mode)
서버에 다수의 클라이언트가 접속하여 질의를 수행하는 경우, 서버는 각 클라이언트 세션별로 하나의 서비스 쓰레드를 생성하여 질의를 수행한다.
-
멀티플렉싱 쓰레드 모드(Multiplexing Thread Mode)
Altibase 서버는 서버에 최적화된 개수의 서비스 쓰레드만 생성하고, 클라이언트 세션들이 이를 공유한다.
Altibase는 항상 최적화된 개수의 서비스 쓰레드를 유지하기 위해 동적으로 서비스 쓰레드를 생성하거나 삭제하도록 설계되어 있다. 단, DEDICATED_THREAD_INIT_COUNT 또는 MULTIPLEXING_THREAD_COUNT 프로퍼티에서 지정한 최소 개수만큼의 서비스 쓰레드는 항상 유지한다.
클라이언트의 동시 연결 수가 아주 많을 경우 새로운 서비스 쓰레드 생성으로 인해 서버의 성능이 저하될 수 있다. V$SERVICE_THREAD 성능 뷰를 조회해서 서비스 쓰레드 관련 부하를 확인할 수 있다.
iSQL> SELECT RPAD(TYPE, 30), COUNT(*)
FROM V$SERVICE_THREAD GROUP BY TYPE
UNION ALL
SELECT RPAD(NAME, 30), VALUE1 FROM V$PROPERTY
WHERE NAME LIKE 'MULTIPLEXING%_THREAD_COUNT';
RPAD(TYPE, 30) COUNT
-----------------------------------------------
SOCKET 44
IPC 10
MULTIPLEXING_THREAD_COUNT 8
MULTIPLEXING_MAX_THREAD_COUNT 1024
위 결과와 같이 SOCKET 항목의 수치가 MULTIPLEXING_THREAD_COUNT 항목의 수치보다 크다면 아래의 조치를 취할 수 있다.
-
MULTIPLEXING_THREAD_COUNT 프로퍼티의 값을 더 크게 설정한다.
-
Altibase 서버에서 처리 시간이 오래 걸리는 쿼리문을 튜닝한다.
가비지 콜렉터#
다중 버전 동시성 제어(Multi-Version Concurrency Control, MVCC) 기법에서는 한 데이터에 대해 필요 없는 오래된 데이터가 생성될 수 있다. 가비지 콜렉터(garbage collector 또는 ager)는 불필요한 오래된 버전의 데이터가 차지하는 메모리 공간을 회수하여 재사용될 수 있도록 조치를 취함으로써 메모리 사용의 효율성을 높인다.
그러나 MVCC 동작은 아래와 같은 문제를 유발할 수 있으므로 데이터베이스 운영시 주의가 필요하다.
-
장시간 수행되는 트랜잭션에 의한 데이터베이스 크기 증가
특정 트랜잭션이 너무 오랫동안 커밋되지 않고 수행되고 있으면, 다른 트랜잭션들의 이전 이미지들을 읽을 가능성이 있다. 따라서 가비지 콜렉터가 다른 트랜잭션들의 이전 이미지 정보들(메모리 테이블은 이전 버전, 디스크 테이블은 언두 로그 레코드 정보)과 해당 레코드의 인덱스 키들을 삭제할 수 없게 된다. 이에 따라 메모리 테이블의 크기가 증가되고, 디스크의 언두 테이블스페이스 크기가 증가하게 된다. 또한, 해당 트랜잭션이 롤백할 때를 대비해서 로그 파일도 삭제하지 못하므로, 로그 파일이 존재하는 파일 시스템이 꽉 찰 가능성이 있다.
-
동시 수행 트랜잭션 과다로 인한 데이터베이스 크기 증가
Altibase는 MVCC로 인해 생성된 이전 이미지 정보들의 해제를 가비지 콜렉터에게 맡기고 있다. 만일 동시에 수행되는 트랜잭션의 수가 해당 시스템의 CPU개수 보다 현저히 많을 경우에는 가비지 콜렉터가 이전 이미지 정보들을 삭제할 여유를 가지지 못해 데이터베이스 크기가 계속 늘어날 수 있다.
-
대량의 갱신 연산으로 인한 데이터베이스의 크기 증가
한번에 대량의 이전 정보를 생성해야 하는 연산(bulk update)들이 자주 수행되면, 메모리 테이블은 그 크기가 커지며, 디스크 테이블은 언두 테이블스페이스가 커질 수 있다.
-
이전 이미지 정보 과다로 인한 성능 저하
위에 열거한 내용들로 인하여 이전 이미지 정보가 데이터베이스 내에 너무 많이 남아있으면 트랜잭션이 실제로 목적하는 레코드를 찾는데 더 많은 비용이 들어 갈 수 있어서 전체적으로 성능이 느려질 소지가 있다.
아래와 같이 V$MEMGC 성능 뷰를 조회하여 가비지 콜렉터의 메모리 회수 능력을 확인할 수 있다. GCGAP 값은 가비지 콜렉터가 삭제해야 할 오래된 버전의 양을 의미한다.
iSQL> SELECT GC_NAME, ADD_OID_CNT, GC_OID_CNT , ADD_OID_CNT - GC_OID_CNT GCGAP FROM V$MEMGC;
ADD_OID_CNT GC_OID_CNT GCGAP
----------------------------------------------
113 113 0
아래의 쿼리는 가비지 콜렉터가 메모리 회수를 위해 커밋하기를 대기하고 있는 트랜잭션을 조회한다. 이렇게 조회되는 트랜잭션에 대해서는 트랜잭션이 수행하는 쿼리문을 튜닝할 필요가 있다.
SELECT SESSION_ID, TOTAL_TIME, EXECUTE_TIME, TX_ID, QUERY
FROM V$STATEMENT
WHERE TX_ID IN (SELECT ID FROM V$TRANSACTION
WHERE MEMORY_VIEW_SCN = (SELECT MINMEMSCNINTXS FROM V$MEMGC LIMIT 1))
AND EXECUTE_FLAG = 1
ORDER BY 2 DESC;
가비지 콜렉터가 메모리 회수 작업을 자주 수행하도록 AGER_WAIT_MUNIMUM, AGER_WAIT_MAXIMUM 프로퍼티 값을 조절하는 것도 MVCC 동작으로 인해 메모리 사용량이 과다하게 되는 것을 방지하는 하나의 방법이다.
SQL Plan Cache#
7장. SQL Plan Cache를 참조한다.
CPU 사용률#
Altibase 서버 내부의 쓰레드별 CPU 사용률과 CPU 사용률이 높은 쓰레드가 어떤 작업을 하는지 확인할 수 있다.
OS별로 쓰레드의 CPU 사용률을 확인하는 명령어는 다음과 같다.
| OS | Command |
|---|---|
| AIX | ps -mo THREAD -p altibase_pid |
| HPUX | glance +s +G |
| LINUX | ps -Lfm -p altibase_pid |
예제
$ ps -mo THREAD -p 4522224
USER PID PPID TID ST CP PRI SC WCHAN F TT BND COMMAND
eheejung 4522224 1 - A 0 60 90 * 40001 - - /home/altibase_home/bin/altibase -p boot from admin
- - - 9568417 S 0 60 1 - 410400 - - -
- - - 9895977 S 0 60 1 f1000f0a10009740 8410400 - - -
- - - 9961701 S 0 60 1 - 410400 - - -
- - - 10420443 S 0 60 1 - 410400 - - -
- - - 10616915 S 0 60 1 - 410400 - - -
- - - 11010221 S 0 60 1 - 410400 - - -
- - - 14811193 S 0 60 1 - 410400 - - -
- - - 15663139 S 0 60 1 - 410400 - - -
- - - 16449727 S 0 60 1 - 410400 - - -
CPU 사용률이 높은 쓰레드가 어떤 작업을 하고 있는지 확인하는 명령어는 다음과 같다.
-
HP-UX, Linux
pstack altibase_pid
-
AIX
procstack altibase_pid