pg_buffercache 모듈을 이용하면,
공유 버퍼 캐시가 어떻게 사용되고 있는지를 실시간으로 살펴볼 수 있다.
C로 만든 pg_buffercache_pages 함수는 버퍼 캐시 정보를
레코드 단위로 리턴하고, 이를 이용해서 좀 더 보기 편한 pg_buffercache
뷰도 제공한다.
보안상 이슈가 될 여지가 있어, 이 두 기능은 슈퍼 유저와
pg_monitor 롤 소속 사용자만 사용할 수 있다.
필요하다면, GRANT 명령을 통해 권한을 부여한다.
pg_buffercache 뷰이 뷰에서 제공하는 칼럼은 표 F.15 표와 같다.
표 F.15. pg_buffercache 칼럼들
칼럼 자료형 설명 |
|---|
ID, 1.. |
해당 릴레이션의 파일노드 번호 |
해당 릴레이션의 테이블스페이스 OID |
해당 릴레이션의 데이터베이스 OID |
해당 릴레이션 포크 번호;
Fork number within the relation;
|
해당 릴레이션 안의 페이지 번호 |
이 페이지가 체크포인트 대상인지? |
Clock-sweep 접근 회수 |
해당 페이지를 선점한 백엔드 수 |
하나의 로우는 공유 캐시 안에서의 하나의 버퍼 정보다.
이 버퍼가 사용되고 있지 않다면, bufferid 칼럼을 제외한 모든
칼럼 값이 null이다.
공용 시스템 카탈로그는 데이터베이스 OID가 0으로 표시된다.
이 출력 자료는 공유되고 있는 모든 캐시 정보를 보여주기 때문에,
현재 데이터베이스에 속하지 않은 정보들도 출력된다.
그래서, pg_class 테이블에 없는 릴레이션 OID 값이 출력될 수도
있다. pg_class 테이블과 join 쿼리를 사용한다면,
reldatabase 값이 0인 경우도 고려해서 쿼리를 작성해야한다.
이 뷰로 출력될 자료를 버퍼 관리자가 복사할 때, 버퍼를 잠그지 않기 때문에,
pg_buffercache 뷰는 다른 프로세스들의 일반적인
버퍼 작업에 크게 영향을 주지 않는다. 이렇게 처리하기 때문에 모든 버퍼의
일관성이 맞지 않을 수도 있다. 하지만, 각 개별 버퍼의 일관성은 맞게
보여준다.
regression=# SELECT n.nspname, c.relname, count(*) AS buffers
FROM pg_buffercache b JOIN pg_class c
ON b.relfilenode = pg_relation_filenode(c.oid) AND
b.reldatabase IN (0, (SELECT oid FROM pg_database
WHERE datname = current_database()))
JOIN pg_namespace n ON n.oid = c.relnamespace
GROUP BY n.nspname, c.relname
ORDER BY 3 DESC
LIMIT 10;
nspname | relname | buffers
------------+------------------------+---------
public | delete_test_table | 593
public | delete_test_table_pkey | 494
pg_catalog | pg_attribute | 472
public | quad_poly_tbl | 353
public | tenk2 | 349
public | tenk1 | 349
public | gin_test_idx | 306
pg_catalog | pg_largeobject | 206
public | gin_test_tbl | 188
public | spgist_text_tbl | 182
(10 rows)
Mark Kirkwood <markir@paradise.net.nz>
디자인 제안: Neil Conway <neilc@samurai.com>
디버깅 도와준 이: Tom Lane <tgl@sss.pgh.pa.us>