IBAnalyst: 요약 보기에서 볼 수 있는 내용

Dmitry Kuzmenko, 최종 업데이트 2014-03-31

요약

이 문서는 IBAnalyst의 “요약 보기” 페이지에 있는 정보를 설명하고, 이를 데이터베이스 통계를 위해 해석하는 방법을 다룹니다. 또한 설치 패키지에 몇 가지 통계 예제를 추가하여 InterBase 통계의 모든 세부 사항을 쉽게 학습할 수 있도록 했습니다. 이 예제들은 IBAnalyst 설치 디렉토리의 Examples 폴더에 있습니다.

Oldest transaction, Oldest snapshot, active 및 Next가 무엇인지 모르신다면, 먼저 Craig Stunz의 기사 “Understanding Transactions Lifetime"을 읽어보시기 바랍니다:

http://blogs.teamb.com/craigstuntz/articles/UnderstandingTransactionLifetimes.aspx

트랜잭션 번호

Understanding Transaction Lifetimes 기사를 읽었더라도 OIT/OST/OAT 번호에 대해 여전히 궁금한 점이 있을 수 있습니다. 간단히 설명하면 다음과 같습니다:


번호	유지되는 경우, …	앞으로 이동하는 경우, …
Oldest transaction	이 번호를 가진 트랜잭션이 롤백되었고 그 안에 많은 데이터 변경이 있었거나, 클라이언트 연결이 끊어진 경우	자동 또는 수동 스윕이 성공했을 때
Oldest Snapshot	스냅샷(또는 IB 7.1 이전의 read committed write)이 오랫동안 활성 상태인 경우(가장 오래된 활성 스냅샷을 로컬 OST로 기억함)	새 트랜잭션이 시작될 때, OST를 보유한 트랜잭션이 종료된 경우
Oldest Active	이 번호를 가진 트랜잭션이 오랫동안 활성 상태인 경우	새 트랜잭션이 시작될 때, OAT를 보유한 트랜잭션이 종료된 경우
Next	절대 아님	새 트랜잭션이 시작될 때

참고: 여기서 Oldest transaction은 다른 많은 기사에서 언급되는 Oldest Interesting Transaction(OIT)과 동일합니다.

표준 설정으로 정확한 통계

IBAnalyst를 시작하고 (Statistics/Load statistics from file 메뉴를 통해) !allok.txt 파일을 엽니다.

IBAnalyst는 데이터베이스 생성 날짜뿐만 아니라, 통계가 Services API를 통해 수집된 경우 서버의 현재 날짜/시간을, 통계 파일이 로드된 경우 파일의 날짜/시간을 인식합니다.

그래서 통계 파일을 수정하지 않는 것이 좋습니다. 수정하면 IBAnalyst가 하루 평균 트랜잭션 수를 잘못 계산할 수 있기 때문입니다. 여기서 하루 트랜잭션 수는 약 12,500건이며, 이 데이터베이스는 생성 또는 복원 이후 8일 동안 “살아있음"을 보여줍니다.

Oldest, Oldest snapshot, Oldest active 및 Next 트랜잭션은 완벽한 상태입니다. 항상 이와 같은 통계를 보시길 바랍니다.

많은 활성 트랜잭션

다음으로 !lotofactive.txt 파일을 엽니다 (언제든지 !allok 그림을 다시 보면서 다음 예제와 비교할 수 있습니다).

여기서 Active transactions 행이 빨간색으로 표시됩니다. Oldest active와 Next 트랜잭션 사이에 큰 차이가 있기 때문입니다. 이는 통계가 수집된 시점에 일부 트랜잭션이 여전히 활성 상태이며, 그 시작 이후 55,000개의 트랜잭션이 이미 시작되었음을 의미합니다 (이들은 활성, 커밋, 롤백 등 어떤 상태든 될 수 있습니다). 하루 평균 트랜잭션 수가 약 12,500건이므로, IBAnalyst는 일부 트랜잭션이 4.4일 동안 계속 살아있다는 경고를 표시합니다. 이런 상황은 다음과 같은 경우에 발생할 수 있습니다:

일부 애플리케이션이 여전히 실행 중이고 최소한 하나의 트랜잭션이 열려 있는 경우 - 일부 사용자가 오랫동안 애플리케이션을 실행 중일 수 있습니다.
애플리케이션이 오랫동안 실행되면서 트랜잭션 핸들을 잃어버린 경우 - 즉, 코드(또는 사용하는 컴포넌트/라이브러리)가 동적으로 트랜잭션을 시작하고 특정 상황에서 롤백이나 커밋으로 종료하는 것을 “잊어버린” 경우.
애플리케이션이 명시적 트랜잭션(BDE)을 사용하지 않고, 트랜잭션 처리를 사용 중인 컴포넌트에 맡기는 경우. 결과적으로 트랜잭션 수명이 애플리케이션에 의해 제어되지 않으며, 대부분의 Next-OAT 트랜잭션이 실제로 활성 상태라고 확신할 수 있습니다.
애플리케이션이 “기본 트랜잭션"을 허용하는 드라이버나 컴포넌트를 사용하는 경우. 코드가 이 트랜잭션을 제어하지 않으면 매우 오랫동안 실행될 수 있습니다.

안타깝게도 통계는 현재 활성 트랜잭션의 실제 수를 표시하지 않습니다. 이는 InterBase 7.x에서 IBConsole, IB Performance Monitor 또는 tmp$transactions 임시 시스템 테이블에 대한 직접 쿼리를 통해서만 볼 수 있습니다. Firebird 1.5에서는 isc_database_info를 isc_info_active_transactions 매개변수로 호출할 수 있습니다.

스윕

이제 !needsweep.txt를 열어보겠습니다.

스윕은 InterBase 내부의 유지 관리 프로세스입니다. 스윕은 데이터베이스의 모든 레코드를 검사하여 가비지 버전을 정리하고, Oldest transaction 번호를 올리려고 시도합니다. 새로 생성된 데이터베이스에서 스윕 간격은 기본적으로 20000입니다. 트랜잭션 간의 차이(아래 표 참조)가 스윕 간격보다 커지면 스윕이 자동으로 실행됩니다. 따라서 데이터베이스에서 주기적인 성능 저하를 볼 수 있습니다. 예를 들어, 애플리케이션이 월요일과 화요일에는 정상적으로 작동하지만 수요일에는 사용자가 몇 시간 동안 성능 문제를 보고하고, 그 후 성능이 다시 정상으로 돌아옵니다.

이와 유사한 동작이 보이면 자동 스윕이 실행되고 있는 것입니다.


서버 버전	스윕 실행 조건
InterBase 7.x	(Oldest Active - Oldest) > 스윕 간격
InterBase 4.x, 5.x, 6.x, Firebird 1.5.2 이전, Yaffil	(Oldest Snapshot - Oldest) > 스윕 간격

표 1. 자동 스윕 실행 조건

참고: IBAnalyst는 모든 버전에 대해 올바른 스윕 간격 정보를 자동으로 표시합니다. IBAnalyst는 ODS ID로만 서버 구현 간의 차이를 감지할 수 있습니다. 예를 들어, InterBase 7.x는 ODS 11.x를, 다른 최신 서버는 ODS 10.x를 사용합니다. InterBase 7.x 데이터베이스(ODS 11)만 사용하는 경우 Options 대화상자에서 해당 옵션을 전환할 수 있습니다.

데이터베이스의 스윕 간격이 0이 아닌 경우, IBAnalyst는 기본적으로 이 행을 노란색으로 표시합니다 (자동 스윕이 예측할 수 없는 순간에 시작될 수 있음을 경고). 일반적으로 모든 애플리케이션의 60%가 자동 스윕 문제를 가지고 있습니다. 이 문제를 피하는 가장 쉬운 방법은 스윕 간격을 0으로 설정하여 자동 스윕을 끄는 것입니다. 그러나 일부 애플리케이션이 많은 변경을 수행한 후 롤백하면 Oldest transaction이 고정되어 스윕이 실행될 때까지 올라가지 않습니다. 유효 트랜잭션 상태는 Oldest부터 Next 트랜잭션까지 계산되므로 이 거리가 커지면 성능이 저하됩니다. 이를 방지하려면 수동으로 스윕(gfix -sweep)을 실행해야 합니다. 이 그림에서는 스윕 간격이 0이고 큰 트랜잭션이 롤백된 동작을 볼 수 있습니다:

여기서 스윕 간격 값은 약 4.5일 전에 큰(많은 변경을 만든) 트랜잭션이 롤백되었음을 보여줍니다. 매일 수동으로 스윕을 실행하는 것을 권장합니다.

물론, 앞서 언급한 60%의 애플리케이션의 경우 스윕 간격을 20000보다 크거나 작게 설정하는 것이 더 나을 수 있지만, 이는 여러 요인(예: 일일 트랜잭션 수)에 따라 달라지며 실험적으로만 이해할 수 있습니다. 따라서 스윕 간격을 0으로 설정하면 예측할 수 없는 순간에 스윕이 자동으로 실행되지 않을 것이라고 확신할 수 있습니다.

!rollback.txt 파일에서도 동일한 그림을 볼 수 있습니다.

참고: 자동 스윕이 실행 중일 때, 큰 데이터베이스나 가비지 레코드 버전이 많은 데이터베이스의 경우 스윕이 작동하는 동안 Snapshot, Active 및 Next 트랜잭션이 앞으로 이동할 수 있으며, 가장 가까운 트랜잭션 시작 시 스윕이 다시 시작될 수 있습니다.

스윕이 작업을 수행할 수 없는 경우

스윕이 Oldest transaction을 더 높이 올릴 수 없는 경우가 많이 있습니다. 물론 스윕은 먼저 작업을 수행하려고 시도합니다. 즉, 데이터베이스의 모든 레코드를 확인하고 불필요한 레코드 버전을 수집합니다. 그러나 다음과 같은 경우 스윕은 성공 없이 계속 반복 실행됩니다:

스윕 실행 중 문제가 발생한 경우: 스윕 중 서버가 중지되었거나, 가비지 레코드 버전 정리 중 오류가 발생한 경우. 또한 다음 상황에서도 이 그림을 볼 수 있습니다:

스윕이 작동 중일 때 통계가 수집된 경우
스윕이 실행 중이고 지속적으로 업데이트되는 테이블의 가비지를 수집하려고 하는 경우. 이는 업데이트가 끝날 때까지 지속될 수 있습니다.
sweep은 페이지 잠금으로 인해 지연되고 있습니다. 많은 사용자가 데이터로 작업하고 있기 때문입니다.

일반적으로 sweep은 높은 데이터베이스 부하 중에는 완료될 기회가 없습니다. 보통 성능이 정상적인 작업을 계속할 수 없을 정도로 저하되면 DBA가 서버를 재시작하고, 첫 번째 사용자 연결 시 sweep이 실행됩니다. 다른 사용자가 연결되는 동안 시간이 있으므로 sweep은 작업을 완료할 시간을 갖게 됩니다.

InterBase 7.1/7.5부터 Sweep gap을 이전 버전과 다르게 계산하므로, sweep이 작업을 수행할 수 없는 또 다른 상황은 일부 애플리케이션이 장기 실행 스냅샷 트랜잭션을 가질 때입니다:

여기에는 두 가지 경고가 있습니다 - 하나는 장기 실행 스냅샷에 대한 (노란색) 경고이고, 다른 하나는 Sweep interval 및 Sweep gap에 대한 (빨간색) 경고입니다.

장기 실행 스냅샷

이전 그림은 InterBase 7.1/7.5에서 장기 실행 스냅샷을 나타냅니다. Sweep interval이 0으로 설정된 경우 빨간색 경고는 없고 노란색 경고만 있을 것입니다. 유사한 그림은 다른 InterBase, Firebird 및 Yaffil 버전에서 장기 실행 스냅샷 트랜잭션을 나타냅니다:

보시다시피 여기서 Sweep gap은 Oldest Snapshot과 Oldest transaction의 차이로 계산됩니다(ODS 10, pre-IB7.x 버전의 경우). 따라서 sweep 경고가 없습니다(기본 sweep interval 제외).

그러나 스냅샷 트랜잭션만이 트랜잭션 상태에 이런 방식으로 영향을 미치는 것은 아닙니다. InterBase 7.1/7.5를 제외한 모든 InterBase, Firebird 및 Yaffil 버전은 우리가 “read committed artifact"라고 명명한 다음과 같은 동작을 가지고 있습니다.

스냅샷 다시 보기 및 ReadCommitted가 Oldest Snapshot을 고정시키는 경우

!snapshot2.txt를 엽니다. :

Oldest transaction이 Oldest snapshot보다 크다는 점에 주목하십시오. 그리고 Sweep gap은 음수 값을 가집니다. 이는 두 가지 경우에 발생할 수 있습니다. 첫 번째 경우는 일부 스냅샷 트랜잭션이 연속적으로 시작되고 커밋되는 경우입니다. 즉, 이 그림은 이전 그림과 마찬가지로 스냅샷에서도 발생할 수 있습니다. 다음 경우는 IB 7.1/7.5 이외의 서버에서 ReadCommitted 트랜잭션(또는 ReadCommitted와 Snapshot 트랜잭션의 조합)에서만 발생합니다. 이들은 Snapshot 트랜잭션과 동일한 방식으로 Oldest Snapshot 번호를 잠글 수 있습니다. 현재 트랜잭션 상태는 다음 순서로 시뮬레이션할 수 있습니다:

트랜잭션 1 시작, snapshot 또는 read_committed
일부 read_committed 트랜잭션 시작/커밋
트랜잭션 2 시작, snapshot 또는 read_committed
일부 read_committed 트랜잭션 시작/커밋
트랜잭션 1 커밋

(물론 여기서는 읽기 전용이 아닌 read_committed 쓰기 트랜잭션에 대해 이야기하고 있습니다).

이 시점에서 스냅샷 1(마크 3) 이후에 시작된 현재 활성 트랜잭션 2(snapshot 또는 read committed)는 Oldest Snapshot으로 스냅샷 번호를 유지합니다(IB 7.1/7.5를 사용하는 경우 동시 스냅샷 트랜잭션에서만 발생할 수 있습니다. read_committed 또는 read_committed+snapshot은 이 효과를 생성하지 않습니다). 큰 롤백이 없었으므로 Oldest transaction은 앞으로 이동하여 Oldest Snapshot보다 커집니다.

이제 장기 실행 read committed 트랜잭션이 있으면 이와 같은 그림을 볼 수 있습니다. 안타깝게도 여기서 애플리케이션으로 할 수 있는 일은 없습니다(읽기 전용 트랜잭션에 “read” 매개변수를 추가하는 것 외에는). 그리고 물론 이 경우 sweep은 자동으로 실행되지 않습니다(<> 0으로 설정된 경우).

참고: 이 동작은 Firebird 2.0에서 수정될 예정입니다.

절대 및 상대 보기

기본적으로 IBAnalyst는 트랜잭션 행을 절대 값의 백분율로 채웁니다. 즉, 100%는 0부터 Next transaction까지입니다. 때로는 데이터베이스가 오랫동안 작동한 경우 트랜잭션 정보를 다음과 같이 볼 수 있습니다:

트랜잭션이 많을 때 snapshot, active 및 oldest 간의 차이는 매우 작아 보입니다(약 98%에 가까움). 상황을 더 명확하게 하려면 Options 대화 상자, Transactions 탭을 열고 “Relative (from oldest) bars %” 옵션을 선택하십시오(그래프 막대가 없는 이전 스타일 보기를 사용하는 경우 이 확인란을 설정할 수 없습니다). OK 버튼을 누르면 트랜잭션 보기가 다음과 같이 변경됩니다:

이제 상대 보기에서 트랜잭션 차이를 볼 수 있습니다(100%는 0이 아닌 Oldest(또는 snapshot) 트랜잭션부터 Next까지). 현재 상황을 이해하고 경고(있는 경우)를 보는 것이 더 쉽습니다.

이 보기는 Options 대화 상자에서 선택을 해제할 때까지 유지됩니다. Oldest Transaction 또는 Oldest snapshot 행으로 어떤 보기를 보고 있는지 이해할 수 있습니다 - 상대 보기에서는 이 행 중 하나가 녹색으로 채워지지 않습니다. 절대 보기에서는 항상 채워집니다(물론 부분적으로).

아직 질문이 있으십니까? [email protected]으로 문의하십시오.