�ݺ�ߣ

성능 향상 시킨다고 Reindex 는 바보짓
• 대부분 Index는 B-tree 알고리즘을 이용하는데, B-tree 구조는 변형이 잘 안 생김.

• B-tree는 균형(Balance)를 항상 맞추기 때문에 논리적 접근속도는 모두 동일.
• Reindex 는 Index 테이블의 목차를 갱신할 뿐이다.
• Reindex 를 한다고 해서 디스크 접근이 개선되지 않는다.

PostgreSQL 은 쿼리 플랜이 우수하고 Index를 잘 이용한다고 하더라도
Disk I/O 를 줄이지 못하면 성능상 이점은 없다고 봐야 한다.

PostgreSQL Disk 사용
• 모든 데이터는 Disk 쌓는다.
• 모든 데이터는 Disk 에서 읽는다.
• 유효한 데이터(Live Tuple) 만 Disk에 존재하는 건 아니다.
불필요한 데이터(Dead Tuple)도 함께 존재.

• Dead Tuple 는 데이터 접근시 안 읽으면 좋은데, PostgreSQL은 다 읽는다.
Dead Tuple

Live Tuple

Tuple ????
• MVCC(다중버전동시성제어) 구현을 위해서 Tuple 개념을 도입.
• Row(혹은 Record) 의 버전.
Rows Version 1

Dead Tuple

Rows

Update Query

Copy
Rows Version 2

Select Query
Complete

Update Query

Live Tuple

Dead Tuple ????
•

PostgreSQL은 Row 삭제시 실제 디스크에서 삭제처리 되지 않고 ‘삭제’ 표시만 한다.

•

실제 물리디스크에는 그대로 데이터가 남아 있다.

•

질의를하면 Dead Tuple까지 스캔한다.
Dead Tuple

ver1

ver2

ver3

ver4

ver5

Live Tuple

ver6

Disk Read

ver7

ver8

ver9

ver10

ver11

Dead Tuple 언제 만들어지나?
• Update, Delete 할때.
• 트랜잭션(Transaction)을 사용할때.

결국, Update, Delete, 트랜잭션을 많이 사용하는 PostgreSQL은
Dead Tuple 이 증가되고 이는 Disk I/O의 증가로 인해서
시간이 갈수록 성능저하를 가지고 온다.
• Pg_Catalog 에 모든 정보가 쌓인다.
• Tuple 정보도 쌓이는데 이를 활용해 데이터베이스 상태 파악 가능

Tuple 정보 얻기
• Pg Catalog 테이블, 뷰를 통해서 얻을 수 있음.
• 튜플 정보.
SELECT c.relname, pg_stat_get_live_tuples(c.oid) + pg_stat_get_dead_tuples(c.oid) as t_tup,
pg_stat_get_live_tuples(c.oid) AS n_live_tup,
pg_stat_get_dead_tuples(c.oid) AS n_dead_tup,
round(100*pg_stat_get_live_tuples(c.oid) / (pg_stat_get_live_tuples(c.oid) + pg_stat_get_dead_tuples(c.oid)),2) as live_tuple_rate,
round(100*pg_stat_get_dead_tuples(c.oid) / (pg_stat_get_live_tuples(c.oid) + pg_stat_get_dead_tuples(c.oid)),2) as dead_tuple_rate,
pg_size_pretty(pg_total_relation_size(c.oid)) as total_rel_size,
pg_size_pretty(pg_relation_size(c.oid)) as rel_size
FROM pg_class as c
WHERE pg_stat_get_live_tuples(c.oid) > 0
AND c.relname NOT LIKE 'pg_%' ORDER BY n_dead_tup DESC;
relname | t_tup | n_live_tup | n_dead_tup | live_tuple_rate | dead_tuple_rate | total_rel_size | rel_size
------------+-------+------------+------------+-----------------+-----------------+----------------+---------tuple_test | 1200 |

1100 |

100 |

91.00 |

8.00 | 136 kB

| 56 kB

(1 row)

• PostgreSQL은 Stat Collertor 프로세스로 각종 정보를 수집.
• 수집된 정보는 Query Plan에 활용.
• 수동으로 정보 업데이트를 하고 싶다면 Analyze 를 이용.

Vacuum
Dead Tuple 삭체 처리.

•

디스크 I/O 향상

•

PostgreSQL 8.x 버전에서는 FSM(Free Space Map) 설정이 맞지 않으면 동작 않함.

•

PostgreSQL 9.0 이상부터 Vacuum 알고리즘 변경으로 시간 단축 됨.(FSM도 필요없다.)
임시테이블을 만들어 Live Tuple를 순차적으로 쌓고 다되면 Index를 걸고 예전 테이블을 임시테이블로 교체.

Live Tuple를 순차적으로 읽어
임시 테이블에 순차적으로 쌓는다.

tuples

Index

•

PostgreSQL 9.0 이상부터 Vacuum 시 제약 조건은 임시테이블을 생성을 위한
물리 디스크 공간이다.

•

VACUUM 후에 데이터베이스,테이블의 OID 값이 변경된다.

Thank you

현승범(orion_203@naver.com)

�ݺ�ߣ

PostgreSql vaccum

Recommended

More Related Content

What's hot (20)

Viewers also liked (12)

Similar to PostgreSql vaccum (11)

PostgreSql vaccum