Tibero DB 대기 이벤트
Tibero Database에서 발생하는 대기 이벤트 정보에 대하여 설명합니다.
V$SYSTEM_EVENT
Tibero는 서버 프로세스와 백그라운드 프로세스들이 일을 처리하는 과정에서 발생하는 대기 현상들을 측정하기 위 해 여러가지 대기 이벤트들을 정의하고 프로세스들이 일을 진행하다가 대기 이벤트가 발생할 때마다 횟수와 대기 시간을 내부에 저장합니다.
v$system_event는 인스턴스 기동 후 현재까지 누적된 이벤트 발생 현황을 시스템 레벨로 확인할 때 사용합니다.
개별 세션별로 누적치를 확인하려면 v$session_event를 조회하고 세션 레벨에서 현재 진행 중 이거나 바로 직전에 발생했던 이벤트 정보를 보여주는 View 는 v$session_wait 입니다.
Single DB
다음은 Single DB 쿼리 작성 예입니다.
SELECT name,
total_waits,
time_waited/1000000 "time_waited",
average_wait/1000000 "average_wait",
total_timeouts
FROM v$system_event
WHERE Total_waits>0
ORDER BY time_waited DESC;결과는 아래와 같습니다.
TAC DB
다음은 TAC DB 쿼리 작성 예입니다.
결과는 아래와 같습니다.
각 항목에 대한 설명은 다음과 같습니다.
항목
설명
INST_ID
Tibero 인스턴스 정보 (TAC DB 질의 쿼리)
TOTAL_WAITS
해당 이벤트가 호출된 총 횟수
time_waited
해당 이벤트에서 대기한 시간 (단위 : 초)
Average_wait
해당 이벤트에서 한번에 대기한 평균 시간 (단위 : 초)
Total_Timeout
해당 이벤트에 Timeout이 설정이 되어 있을 때 Timeout 발생 횟수
주요 이벤트는 아래와 같습니다.
이벤트
설명
WE_SEQ_WRITEBACK
Agent가 Seq를 Writeback할 때까지 기다리는 이벤트
WE_SEQ_FREESLOT
Seq_Buffer_의 Free Slot이 없을 때까지 기다리는 이벤트
WE_SEQ_NEXTVAL
Agent가 New Value를 Cache에 올릴 때까지 기다리는 이벤트
WE_BUF_WAIT
Buf Pin을 위해 기다리는 이벤트
WE_BUF_WRITE
Buf Write까지 기다리는 이벤트
WE_BUF_FREE
Free Buf가 생길 때까지 기다리는 이벤트
WE_MBR_WAIT
MBR이 끝날 때까지 기다리는 이벤트
WE_SEQ_FLUSH
Seq alba가 Cache Flush를 마칠 때까지 기다리는 이벤트
WE_WTHR_READY
WTHR Ready까지 기다리는 이벤트
WE_LGWR_ARCHIVE
LGWR Process가 Archive 완료할 때까지 기다리는 이벤트
WE_LGWR_LNW
LGWR Process가 네트워크를 통해 로그를 쓸 때까지 기다리는 이벤트
WE_LOG_FLUSH
Log Flush 할 때까지 기다리는 이벤트
WE_LOG_FLUSH_SPACE
공간이 부족해서 Log Flush할 때까지 기다리는 이벤트
WE_LOG_FLUSH_REQ
Log Flush를 요청해서 기다리는 이벤트
WE_CKPT_WAIT
Checkpoint를 기다리는 이벤트
WE_PROC_DOWN
Shutdown Finish되는 경우 발생하는 이벤트
WE_WTHR_START
WTHR가 시작되기 위해서 메시지를 받을 때까지 기다리는 이벤트
WE_WTHR_MSG
WTHR가 클라이언트의 MSG를 기다리는 이벤트
WE_ACF_SCVR
SCVR(scavenger)에서 CCC/CWS RSB(Resource Block)를 reclaim 요청 받을 때 까지 기다리는 이벤트
만약 reclaim 요청이 없더라도 주기적 (_ACF_SCVR_TIMEOUT(기본값 : 1초))으로 깨어나서 reclaim을 수행
WE_ACF_AST
WTHR가 AST(asynchronous system trap)인 경우 이벤트
Waiting은 실제 수행되는 작업의 성능을 저하하므로 가장 많이 발생하는 대기 이벤트를 중점적으로 해결하고 각 대 기 이벤트의 종류에 따라 Waiting이 많이 발생하는 이벤트를 해결합니다. 또한 모든 wlock 관련 정보는 대기 이벤트로 나타나므로 wlock Contention을 알아보는데 사용할 수 있습니다.
예제
다음은 여러 세션이 특정 Block에 지속적으로 업데이트를 하면서 동시에 계속 Commit을 수행하고 있을 때WE_LOG_FLUSH_COMMIT 이벤트가 많이 발생하는 예입니다.
V$session_wait 쿼리를 조회해 보면 다음과 같습니다.
[그림 1] V$session_wait 수행 결과

V$system_event 수행결과를 통해 해당 이벤트가 255471번 호출된 것을 아래와 같이 확인할 수 있습니다.
[그림2] V$system_event 수행 결과

Commit 횟수를 줄이면 WE_LOG_FLUSH_COMMIT 이벤트가 호출된 횟수 또는 Waiting한 시간이 크게 개선된 것을 확인할 수 있습니다.
[그림3] WE_LOG_FLUSH_COMMIT 개선 효과

WE_LOG_FLUSH_COMMIT 이벤트가 줄어든 만큼 Hot Block의 경합으로 인해 WE_BUF_WAIT 이벤트가 발생하는 것을 확인할 수 있습니다. WE_BUF_WAIT는 Buffer Pinning을 위해 대기하는 이벤트로 동일 Block에 대해 업데이트를 하기 때문에 발생하는 이벤트입니다.
V$SYSSTAT
인스턴스 기동 후 현재까지 누적된 수행 통계치를 시스템 레벨로 확인할 때 사용하는 View가 v$sysstat 이고 개별 세션별로 확인할 때 사용하는 View가 v$sesstat 입니다. 또한 현재 접속해 있는 본인 세션에 대한 수행 통계는 v$mystat을 통해 확인이 가능합니다.
Single DB
다음은 Single DB 쿼리 작성 예입니다.
결과값은 아래와 같습니다.
TAC DB
다음은 TAC DB 쿼리 작성 예입니다.
결과값은 아래와 같습니다.
각 항목에 대한 설명은 다음과 같습니다.
항목
설명
INST_ID
Tibero 인스턴스 정보 (TAC DB 질의 쿼리)
STAT#
Stat 번호.
NAME
Stat 이름.
VALUE
Stat 값
v$sysstat와 v$sesstat에 나타나는 값들은 인스턴스 기동 후 또는 세션 수립 후 현재까지 누적된 값이므로 그 값의 크고 작음으로 의미있는 정보를 얻기 어렵습니다.
이를 제대로 활용하는 방법은 두 구간 사이의 변화량을 구해 SQL 수행 도중에 내부적으로 어떤 일들이 발생했는지 판명하는 것입니다.
Spin Lock Contention
TSM(Tibero Shared Memory)의 모든 Spin Lock에 대한 적중률을 확인합니다.
Single DB
다음은 Single DB 쿼리 작성 예입니다.
결과는 아래와 같습니다.
TAC DB
다음은 TAC DB 쿼리 작성 예입니다.
결과는 아래와 같습니다.
각 항목에 대한 설명은 다음과 같습니다.
항목
설명
INST_ID
Tibero 인스턴스 정보 (TAC DB 질의 쿼리)
NAME
Spin Lock의 종류
Gets
최초 시도에서 Spin Lock 획득을 요청한 경우 값을 Gets값을 1씩 증가
Misses
최초 시도에서 Spin Lock 획득에 실패한 경우 Misses값을 1씩 증가
Sleeps
슬립 상태에 빠질때마다 1씩 증가
Hit Ratio
적중률
Willing-to-Wait 모드에서의 Latch 획득 성공과 실패에 대한 통계값은 v$latch View를 통해 조회합니다. Gets(I), Misses(I) 항목은 각각 Gets(또는 Immediate gets)와 Misses(또는 Immediate misses)값을 의미하며 Gets와 Immediate gets 가운데 큰 값을 보여줍니다.
Gets가 Willing-to-Wait 모드로 요청된 경우 Immediate gets는 No-Wait 모드로 요청됩니다. Willing-to-Wait 모드는 Spin Lock 획득에 실패하는 경우 Spin과 Sleep을 하면서 획득에 성공할 때까지 재시도를 하고, No-Wait 모드는 원하는 Spin Lock 획득에 실패하는 경우 해당 Latch를 위해 Wait하지 않으므로 기본적으로 Willing-to-Wait 모드를 사용한다는 것은 Spin Lock을 획득할 때까지 대기한다는 의미입니다.
Spin Lock 모니터링
Spin Lock의 Contention에 대한 정보를 확인합니다.
Single DB
다음은 Single DB 쿼리 작성 예입니다.
결과는 아래와 같습니다.
TAC DB
다음은 TAC DB 쿼리 작성 예입니다.
결과는 아래와 같습니다.
각 항목에 대한 설명은 다음과 같습니다.
항목
설명
INST_ID
Tibero 인스턴스 정보 (TAC DB 질의 쿼리)
NAME
Spin Lock의 종류
GETS
최초 시도에서 Spin Lock 획득을 요청한 경우 값을 Gets값을 1씩 증가
MISSES
최초 시도에서 Spin Lock 획득에 실패한 경우 Misses값을 1씩 증가
SPIN_GETS
Spin Lock을 잡을 때까지 실패한 횟수를 의미하며 실패할 경우 1씩 증가
SLEEPS
슬립 상태에 빠질때마다 1씩 증가
Hit Ratio
적중률
WAIT_TIME
Spin Lock을 기다린 총 슬립 시간
WT
WAIT_TIME을 백분율로 표현한 항목
다음은 Spin Lock Contention을 발생할 수 있는 파라미터에 대한 설명입니다.
Shared Pool
SPIN_SHP_ALLOC
관련 파라미터
_SHARED_POOL_ALLOC_CNT(기본값 : 1)
설명
Shared Pool를 여러 개로 쪼갤 수 있고 몇 개의 allocator로 나누어 관리할지를 결정한다. 최고 15까지 설정 가능하며 설정값이 클수록 Contention은 줄지만 메모리 사용 효율은 떨어 진다.
SPIN_ALLOC_LRU
관련 파라미터
_SHARED_POOL_LRU_PER_ALLOC(기본값 : 4)
설명
하나의 Shared Pool Allocator에서 사용할 LRU list 개수를 결정한다.
2^n 값으로 설정해야 성능 저하가 줄어들며 설정값이 클수록 Contention은 줄지만 메모리 사용 효율은 떨어진다.
SHARED_POOL_LRU_PER_ALLOC 설정 값을 늘려 LRU가 늘었음에도 Contention 이 높다면
SHARED_POOL_ALLOC_CNT 늘려준다.
하지만 SHARED_POOL_ALLOC_CNT의 경우 여유있는 Allocator가 있더라도 Full인 Allocator를 사용할 수 있다는 문제점이 있다.
두 개의 파라미터를 곱했을 때 LRU 개수가 총 16개까지 가능하며 최신 버전에서는 15개까지 설정 가능하다.
SPIN_RECR_HANDLE_POOL
관련 파라미터
_RECR_HANDLE_FREELIST_CNT(기본값 : 8)
설명
DD Cache와 라이브러리 Cache에서 사용하는 구조체의 Free List 개수를 설정한다.
DD와 라이브러리가 메모리에서 사라질 수 있기 때문에 Handle이라는 구조체를 사용하며 매번 생성은 오버헤드가 크기 때문에 Pool로 관리한다.
WLOCK
SPIN_WLOCK
관련 파라미터
_WLOCK_BUCKETSET_CNT(기본값 : 64)
_WLOCK_BUCKET_PER_SET(기본값 : 1)
설명
wlock을 찾을 때 사용할 Hash Bucket의 Bucketset 개수를 결정한다.
Bucketset 별로 Spin Lock이 있으므로 개수가 늘어날수록 Contention이 줄어들지만 Hash Table 이 커지므로 메모리 사용량이 늘어난다.
Spin Lock만 늘려준다면 해당 파라미터만 늘려주고 전체적으로 분산을 원한다면
_WLIST_FREELIST_CNT 파라미터값도 같이 늘려준다.
wlock을 찾을 때 사용할 Hash Bucket의 Bucketset 개수를 결정합니다.
Bucketset별로 Spin Lock이 있으므로 개수가 늘어날수록 Contention이 줄어들지만 Hash Table이 커지므로 메모리 사용량이 늘어납니다. Spin Lock만 늘려준다 면 해당 파라미터만 늘려주고 전체적으로 분산을 원한다면 _WLIST_FREELIST_CNT 파라미터값도 같이 늘려줍니다.
SPIN_WLIST_FREELIST
관련 파라미터
_WLIST_FREELIST_CNT(기본값 : 8)
설명
wlock 또는 Buffer Cache에서 사용하는 구조체 Pool에서 Freelist의 개수를 결정한다. 설정값은 2 ^ n 값을 권장한다.
Buffer Cache
SPIN_BUF_WS / SPIN_BUF_WS_CKPT
관련 파라미터
_DB_BLOCK_LRU_LATCHES(기본값 : cpu 개수 * 3)
설명
Buffer Cache에서 사용할 LRU의 개수로 Workingset 값을 결정한다
SPIN_BUF_BUCKET
관련 파라미터
_DB_BLOCK_HASH_BUCKETS(기본값 : 131091)
_DB_BLOCK_HASH_LATCHES(기본값 : 131091)
설명
_DB_BLOCK_HASH_BUCKETS 파라미터 설정으로 Buffer Cache에서 특정 Buffer 를 찾을 때 사용할 Hash Bucket 개수를 결정한다.
_DB_BLOCK_HASH_LATCHES 파라미터 설정으로 Buffer Cache에서 사용하는 Hash에서 사 용할 Latch 개수를 결정한다.
Contention이 심하면 BUCKETS와 LATCHES값을 같게 할 수 있으나 Bucket마다 Latch가 있게 되어 메모리 효율은 떨어지게 된다.
Redo
SPIN_REDO_COPY
관련 파라미터
_LOG_SIMULTANEOUS_COPIES(기본값 : cpu 개수 * 2)
설명
Redo 버퍼에서 동시에 Copy 하는 트랜잭션의 개수를 설정한다.
Undo
SPIN_USGMT_HASH
관련 파라미 터
_USGMT_HASH_CNT(기본값 : 32)
설명
Undo 세그먼트의 Spin Lock Hash Bucket 수를 설정한다.
Spin Lock Hash Bucket 수를 늘려도 메모리를 많이 사용하지 않으므로 최소 64로 설정하는 것을 권장한다.
DD Cache
SPIN_DD_CACHE_BUCKET
관련 파라미터
_DD_BUCKETSET_CNT(기본값 : 16)
_DD_BUCKET_PER_SET(기본값 : 64)
설명
wlock과 거의 동일하게 Hash Bucket과 Bucketset의 개수를 결정한다.
PP Cache
SPIN_PPC_BUCKET
관련 파라미터
_PPC_BUCKET_CNT(기본값 : 1)
설명
wlock과 거의 동일하게 Hash Bucket 개수를 결정한다
Temp
SPIN_TEMP_UNIT_POOL_TF Temp 파일당 하나의 Spin Lock이 할당되며 여러 세션에서 Temp Tablespace를 사용할 경우 발생합니다. 해당 Spin Lock Contention이 비정상적으로 높을 경우 Temp Tablespace에 Temp 파일을 여러 개 추가하여 해결합니다.
Last updated

