IBAnalyst: InterBase/Firebird 데이터베이스에서 통계를 올바르게 가져오는 방법

Dmitry Kuzmenko, 마지막 업데이트 2014-03-31

개요

이 문서는 IBAnalyst 유무에 관계없이 InterBase/Firebird 데이터베이스에서 통계를 수집하고 분석하는 팁과 요령에 대해 다룹니다.

올바른 시간, 올바른 장소

이상하게 들릴 수 있지만, gstat 또는 Services API를 통해 통계를 수집하는 것만으로는 충분하지 않습니다. 통계는 애플리케이션이 데이터베이스의 데이터와 트랜잭션에 어떻게 영향을 미치는지 보여줄 수 있는 올바른 시점에 수집되어야 합니다. 통계를 수집하기 가장 나쁜 시기는 다음과 같습니다:

복원 직후
-g 스위치 없이 백업(gbak -b db.gdb)을 수행한 후
수동 스윕(gfix -sweep) 후

또한 작업 중에 데이터베이스가 올바른 상태에 있는 순간이 있을 수 있습니다. 예를 들어, 애플리케이션이 평소보다 데이터베이스 부하를 적게 발생시키는 경우(사용자 로그인 시간, 점심 시간 또는 특정 비즈니스 프로세스 시간)입니다.

데이터베이스에 문제가 있을 때를 어떻게 포착할 수 있을까요?

네, 애플리케이션이 너무 완벽하게 설계되어 항상 트랜잭션과 데이터를 올바르게 처리하고, 스윕 간격, 많은 활성 트랜잭션, 장기 실행 스냅샷 등을 만들지 않을 수 있습니다. 그러나 일반적으로 그렇지 않습니다. 적어도 일부 개발자는 2-3명의 동시 사용자로 애플리케이션을 테스트하기 때문입니다. 따라서 15명 이상의 동시 사용자를 위해 작성된 애플리케이션을 설정하면 데이터베이스가 예측할 수 없게 동작할 수 있습니다. 물론, 다중 사용자 모드가 잘 작동할 수도 있습니다. 대부분의 다중 사용자 충돌은 2-3개의 동시 실행 애플리케이션으로 테스트할 수 있기 때문입니다. 그러나 더 많은 동시 애플리케이션이 실행되면 가비지 수집 문제가 (최소한) 발생할 수 있습니다. 그리고 이는 올바른 시점에 통계를 수집하면 포착할 수 있습니다.

주기적인 성능 문제가 없는 경우

애플리케이션이 올바르게 설계되었거나, 데이터베이스 부하가 낮거나, 하드웨어가 현대적이고 매우 강력한 경우(현재 사용자 수와 데이터를 처리하기에 충분한) 이러한 상황이 발생할 수 있습니다.

가장 가치 있는 정보는 트랜잭션 부하와 버전 누적입니다. 이는 정기적인 통계 저장을 설정한 경우에만 확인할 수 있습니다.

InterBase에는 내부 작업 스케줄러가 없으므로 표준 작업 스케줄러(Windows)나 cron(Unix)과 같은 외부 스케줄러를 자유롭게 사용할 수 있습니다.

가장 좋은 설정은 매시간 트랜잭션 통계를 수집하는 것입니다. 이는 다음을 실행하여 수행할 수 있습니다:

gstat -h db.gdb >db_stat_.txt

여기서

_db.gdb_는 데이터베이스 이름이고,

_db_stat_.txt_는 통계가 저장될 텍스트 파일이며,

는 통계가 수집된 현재 날짜와 시간입니다.

주기적인 성능 문제가 있는 경우

이러한 문제는 일반적으로 자동 스윕 실행으로 인해 발생합니다. 먼저 이러한 성능 저하 사이의 시간 간격을 결정해야 합니다. 다음으로 이 간격을 최소 4(8, 16 등)로 나눕니다. 현재 정보 시스템에는 많은 동시 사용자가 있으며, 서버와 데이터베이스가 구성되지 않은 경우 대부분의 성능 문제는 하루에 2-3회 발생합니다. 예를 들어, 성능 저하가 3시간마다 발생한다면 다음을 수행해야 합니다:

gstat -h db.gdb

통계를 30-45분마다 수집하고,

gstat -a -r db.gdb -user SYSDBA -pass masterkey

통계를 1-1.5시간마다 수집합니다.

가장 좋은 방법은 예상되는 성능 저하 직전에 gstat -a -r 통계를 수집하는 것입니다. 그러면 실제 가비지가 어디에 있는지, 얼마나 많은 오래된 레코드 버전이 누적되었는지 보여줍니다.

이 통계로 무엇을 해야 하는가

애플리케이션이 트랜잭션을 명시적으로 사용하고 잘 사용한다면, 즉 read_committed가 무엇이고 언제 사용해야 하는지 알고 있고, 스냅샷 트랜잭션이 필요한 시간보다 오래 지속되지 않으며, 트랜잭션이 최소 시간 동안 활성 상태라면, 스윕 간격을 조정하거나 끌 수 있습니다. 그런 다음 애플리케이션이 수행하는 업데이트 수와 어떤 테이블이 덜 업데이트되거나 업데이트에 주의가 필요한지만 관리하면 됩니다.

이것이 무엇을 의미하는지 물을 수 있습니다. 매일 아침 20-30분 동안 성능 문제가 발생한 어떤 시스템의 예를 들어보겠습니다. 이는 “아침” 애플리케이션에 매우 충분했으며 더 오래 지속될 수 없었습니다.

데이터베이스 관리자에게 올바른 질문을 했고, 다음과 같은 그림이 나왔습니다:

일일 작업은 섹션으로 나뉘었습니다 - 아침에는 분석가가 작업하고, 그 다음에는 일반 운영자가 데이터를 삽입하고 편집하며, 하루가 끝나면 특수 프로시저가 다음 날(최소한) 분석에 사용될 데이터를 수집하기 시작했습니다.

하루가 끝날 때 데이터베이스에서 마지막 작업은 많은 업데이트였고, 분석가가 아침에 사용한 테이블의 업데이트였습니다. 따라서 아침에 실행되는 애플리케이션이 수집하기 시작한 많은 가비지 버전이 있었습니다.

그리고 그 문제에 대한 답은 간단하게 찾았습니다 - 하루가 끝날 때 gfix -sweep을 실행하는 것입니다.

스윕은 데이터베이스의 모든 테이블을 읽고 커밋 및 롤백된 트랜잭션에 대한 모든 가비지 버전을 수집하려고 시도합니다. 스윕 후 데이터베이스는 복원 직후처럼 거의 깨끗해졌습니다.

그리고 “아침 문제"는 사라졌습니다.

따라서 통계를 다른 많은 요소와 함께 고려해야 합니다:

하루 동안 작업하는 동시 사용자 수(평균)
근무 시간(8, 12, 16, 24시간)
하루 중 다른 시간에 실행되는 애플리케이션 종류와 이러한 애플리케이션이 동시에 또는 다음에 실행되는 다른 애플리케이션이 사용하는 데이터에 미치는 영향. 즉, 하루와 일주일 동안 발생하는 비즈니스 프로세스를 이해해야 합니다.

DBA가 할 수 없을 때

안타깝게도 이러한 상황이 발생합니다. 다시 예를 들어보겠습니다:

약 15명의 사용자를 위해 설치된 어떤 시스템이 있습니다. 주기적으로 성능이 너무 나빠서 DBA가 서버를 다시 시작해야 합니다. 서버를 다시 시작하면 잠시 동안 모든 것이 잘 작동하다가 다시 성능이 나빠집니다. 통계에 따르면 평균 일일 트랜잭션 수는 약 75,000건이며, 하루 시작부터 성능이 저하되는 시점까지 활성 트랜잭션이 실행되고 있습니다.

불행히도 애플리케이션은 BDE로 작성되었고 트랜잭션을 전혀 사용하지 않았습니다. 즉, 모든 트랜잭션 처리는 자동으로 BDE 자체에 의해 처리되었습니다. 이로 인해 일부 트랜잭션이 오랫동안 활성 상태로 유지되었고, DBA가 서버를 다시 시작할 때까지 가비지(레코드 버전)가 누적되었습니다. 서버를 다시 시작하면 자동 스윕이 실행되어 가비지가 수집(제거)되었습니다.

이 모든 것은 애플리케이션 때문이었습니다. 2-3명의 동시 사용자로만 테스트되었기 때문에 약 15명이 되자 애플리케이션이 매우 높은 부하를 발생시키기 시작했습니다.

이 구성에서 사용자의 70%는 데이터를 읽기만 하고 나머지 30%는 일부(!) 데이터를 삽입하고 업데이트했다고 말할 필요가 있습니다.

이 상황에서 성능을 개선할 수 있는 유일한 방법은 애플리케이션을 완전히 재설계하는 것입니다.

아직 질문이 있으신가요? [email protected]으로 문의하세요.