Skip to content

PostgreSQL:Vacuum

PostgreSQL 데이터베이스에서는 vacuum (배큠이라고 읽는다) 이라는 주기적인 관리 작업이 필요하다. (영어권에서는 vacuuming 단어는 '청소기 돌리기'라는 뜻으로 이미 일상 용어로 사용되고 있고, 이것을 데이터베이스 용어로 사용하였다. 이 글에서는 그냥 vacuum을 그대로 사용한다. - 옮긴이) 이 작업은 대부분의 서버 환경에서는 autovacuum 데몬이 담당해서 자동으로 처리 되기 때문에, 특별히 신경 쓸 필요는 없다. 이 부분은 23.1.6절에서 자세히 소개한다. autovacuum 관련 환경 설정값을 바꾸어서 그 데몬의 동작 상태를 조절 할 수 있다. 또한 몇몇 데이터베이스 관리자는 VACUUM 명령을 직접 실행하는 것이 데이터베이스를 효율적으로 사용할 수 있다고 판단해서, cron 이나, 작업 스케줄러 같은 프로그램을 이용해서, 이런 주기적인 정리 작업을 한다. 이런 작업을 잘 하기 위해서는 여기서 설명하고 있는 내용을 잘 이해하고 있어야한다. autovacuum 기능을 이용하는 일반적인 환경에서 특별히 문제가 발생하지 않는다면, 게다가 다른 바쁜 일들이 많은 관리자라면 이 부분은 대충 읽어도 좋다.

About

Vacuum은 MVCC 구조로 인하여 효율성이 떨어진 저장공간을 최적화하는 작업을 수행합니다. vacuum이 담당하고 있는 역할은 크게 4가지가 있습니다.

  • 저장 공간 확보 — 테이블 별 dead tuple 정리
  • transaction wraparound 방지 — MVCC에 사용되는 Transaction ID 값이 계속 증가하지 않도록 정리
  • Query Planner 정확도 향상 — 통계 정보 갱신
  • index scan 성능 향상 — visibility map 정보 갱신

때문에 데이터베이스를 지속적으로 사용하려면 Vacuum을 주기적으로 실행해야합니다. #Autovacuum은 이 역할을 담당합니다.

AutoVacuum

PostgreSQL 데이터베이스에서는 vacuum (배큠이라고 읽는다) 이라는 주기적인 관리 작업이 필요하다. autovacuum 데몬이 담당해서 자동으로 처리된다.

데몬은 DB에 설정된 autovacuum parameter 값을 활용하여 주기적으로 vacuum을 실행합니다.

How to check autovacuum process 

$ ps -eaf | egrep "/post|autovacuum"

Logging autovacuum

log_autovacuum_min_duration 설정값을 수정하면 된다. 값의 확인은 아래와 같다. 

$ cat /var/lib/postgresql/data/postgresql.conf  | grep log_autovacuum_min_duration

Active Vacuum

config 파일을 수정하던가 아래의 쿼리를 사용한다. 

ALTER SYSTEM SET autovacuum = on;

Threshold check SQL 

SELECT c.relname, u.n_dead_tup,( c.reltuples * s2.setting::float + s1.setting::int) as threshold
FROM pg_class as c, pg_settings as s1, pg_settings as s2, pg_stat_user_tables as u
WHERE c.relname = 'plugin_data' 
AND u.relname = 'plugin_data' 
AND s1.name = 'autovacuum_vacuum_threshold' 
AND s2.name = 'autovacuum_vacuum_scale_factor';

Troubleshooting

Autovacuum free space

There have been cases where the database size (specifically pg_largeobject) keeps growing even when VACUUM is done every day. Your database keeps growing until it reaches VACUUM FULL.

However, this does not mean that VACUUM cannot work on pg_largeobject. The command treats all the tables equally in PostgreSQL. The reason why it seems to not work is related to the parameter, "max_fsm_pages", on postgresql.conf.

The Free Space Map (FSM) is where postgreSQL keeps track of pages that have free space available for use. Each time it needs space in a table, it will look into the FSM first. If it cannot find any free space, then it will fall back to adding the information to the end of the table.

FSM has limited size (max_fsm_pages). It is used for VACUUM to find out how many and which pages to look for when it frees up the space. In InterScan Messaging Security Suite (IMSS), the "max_fsm_pages" parameter is set to "20000" by default. This means that every time it VACUUM, it can free 20000*8K = 160MB, at most. If the purged size exceeds 160MB every day, the other dead tuples will not be freed by VACUUM and the DB size will keep growing.

The VACUUM FULL is not limited by "max_fsm_pages" and "max_fsm_relations", but the parameters require an exclusive lock on each table while VACUUM FULL is processing them. Therefore, frequent use of VACUUM FULL can have an extremely negative effect on the performance of the current database.

See also

Favorite site

Guide