| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 25. 데이터베이스 활동 감시 | Fast Forward | Next |
PostgreSQL는, 데이터베이스 서버의 동적 추적을 지원하는 기능을 제공합니다. 이로 인해, 외부 유틸리티를 코드의 특정의 포인트로 호출할 수가 있어 추적을 실행할 수 있게 됩니다. 현시점에서는, 코드에 관한 상당한 친밀성이 필요하기 때문에, 이 기능은 주로 데이터베이스 개발자 전용을 의도하고 있습니다.
많은 추적 포인트(종종 probes로 불림)는 소스 코드 내에 존재합니다. 디폴트에서는 이러한 프로브는 이용할 수 없습니다. 그리고 유저는 명시적으로 설정 스크립트를 PostgreSQL에서 사용할 수 있는 probes를 작성할 필요가 있습니다.
현재 Solaris Express 및 Solaris 10+에서 이용 가능한 DTrace 유틸리티만이 지원되고 있습니다. DTrace는 장래 FreeBSD나 Mac OS X로 이용될 수 있을 것으로 예상되고 있습니다. 다른 동적 추적 유틸리티 지원은 이론적으로는 src/include/pg_trace.h의 PG_TRACE매크로 정의를 변경함으로써 가능합니다.
디폴트에서는, 추적 포인트는 이용할 수 없습니다. 때문에 PostgreSQL이 probe를 이용할 수 있도록 설정 스크립트를 명시적으로 설정하지 않으면 안됩니다. DTrace 지원를 포함하려면, configure에--enable-dtrace를 명시합니다. 자세한 정보는 Section 14.5을 참조해 주십시요.
일부 표준 추적 포인트는 소스 코드에서 제공되고 있습니다. (물론, 특정한 문제에 필요한 포인트를 좀 더 추가하는 것은 가능함) 이들은 Table 25-3에서 보여집니다.
Table 25-3. 내장된 추적 포인트
| 이름 | 파라미터 | 개요 |
|---|---|---|
| transaction__start | (int transactionId) | 새로운 트랜잭션(transaction) 시작 |
| transaction__commit | (int transactionId) | 트랜잭션(transaction)의 정상 종료 |
| transaction__abort | (int transactionId) | 트랜잭션의 이상 종료 |
| lwlock__acquire | (int lockid, int mode) | LWLock의 획득 |
| lwlock__release | (int lockid, int mode) | LWLock의 해제 |
| lwlock__startwait | (int lockid, int mode) | LWLock을 즉시 이용할 수 없고, backend가 시작되어 이용할 수 있을 때까지 락 대기 |
| lwlock__endwait | (int lockid, int mode) | backend는 LWLock의 대기 상태를 해제시킴 |
| lwlock__condacquire | (int lockid, int mode) | caller가 대기 하지 않도록 지정했을 때, LWLock 획득 성공 |
| lwlock__condacquire__fail | (int lockid, int mode) | caller가 대기 하지 않도록 지정했을 때, LWLock 획득 실패 |
| lock__startwait | (int locktag_field2, int lockmode) | 락을 이용할 수 없기 때문에, heavyweight 락(lmgr 락)요구를 대기하도록 개시 |
| lock__endwait | (int locktag_field2, int lockmode) | heavyweight 락(lmgr 락) 요구는 대기 상태를 종료(즉, 락 획득) |
이하의 예는 시스템의 트랜잭션(transaction) 수를 해석하는 DTrace 스크립트를 나타냅니다. 성능 시험 전후 pg_stat_database의 스냅샷이 대체 가능합니다.
#!/usr/sbin/dtrace -qs
postgresql$1:::transaction-start
{
@start["Start"] = count();
self->ts = timestamp;
}
postgresql$1:::transaction-abort
{
@abort["Abort"] = count();
}
postgresql$1:::transaction-commit
/self->ts/
{
@commit["Commit"] = count();
@time["Total time (ns)"] = sum(timestamp - self->ts);
self->ts=0;
}
D스크립트를 사용할 때, 추적 포인트의 이중 언더라인을 하이픈으로 바꿔야 함을 주의하십시요. 실행하면, 예제인 D스크립트는 이하와 같은 출력을 합니다.
# ./txn_count.d `pgrep -n postgres` ^C Start 71 Commit 70 Total time (ns) 2312105013
추적 프로그램의 작성에는 주의가 필요하고, 사용 전에 디버그가 필요하다는 것을 잊지 말아 주십시요. 그렇지 않으면, 수집되는 추적 정보의 의미가 없어질지도 모릅니다. 대부분의 경우, 발견되는 문제는 시스템이 아닌 사용 방법의 실수입니다. 동적 추적을 사용해 논의할 정보를 발견할 때, 검사나 토론을 할 수 있도록 스크립트를 포함시켜 주십시요.
개발자가 원하면 코드 내에 새로운 추적 포인트를 정의할 수가 있습니다. 그러나 이는 재컴파일이 필요합니다.
추적 포인트는 추적 매크로 중 하나를 사용해 추가할 수가 있습니다. 얼마나 많은 변수가 추적 포인트의 검사에 가능한지에 따라 선택사항이 존재합니다. 이벤트 발생을 추적하는 것은 추적 포인트명만을 사용해 하나의 행으로 실현될 수 있습니다.
PG_TRACE (my__new__trace__point);
보다 복잡한 추적 포인트에서는 PG_TRACE n 매크로를 사용해, 동적 추적 유틸리티의 검사를 위해 하나 이상의 변수를 제공할 수가 있습니다. 여기서 추적 포인트명 뒤에는 대응하는 파라미터수를 기재합니다.
PG_TRACE3 (my__complex__event, varX, varY, varZ);
transaction__start 추적 포인트의 정의를 이하에 나타냅니다.
static void
StartTransaction(void)
{
...
/*
* generate a new transaction id
*/
s->transactionId = GetNewTransactionId(false);
XactLockTableInsert(s->transactionId);
PG_TRACE1(transaction__start, s->transactionId);
...
}
트랜잭션(transaction) ID가 어떻게 동적 추적 유틸리티로부터 이용할 수 있는지를 주목해 주십시요.
동적 추적 유틸리티는 추적 포인트의 한층 더한 정의를 요구할 가능성이 있습니다. 예를 들면, DTrace는 아래에서 보여지는 것과 같이 새로운 probe를 src/backend/utils/probes.d에 추가하는 것을 요구합니다.
provider postgresql {
...
probe transaction__start(int);
...
};
probe의 인자로 지정한 데이터 타입이 PG_TRACE매크로로 사용되는 변수의 데이터 타입과 일치하는 것을 주의하십시요. 컴파일시에는 검사되지 않습니다. 새롭게 추가한 추적 포인트가 재컴파일에 의해 사용 가능한지를 검사할 수 있습니다. 그 후에 새로운 바이너리를 root로서 실행하고, 이하와 같은 DTrace 커멘드를 실행해 주십시요.
dtrace -l -n transaction-start