PostgreSQL 와 vaccum에 대해 알아보자.

PostgreSQL 뿌-우

 

🍀 PostgreSql

Oracle 사용자들이 가장 쉽게 적응할 수 있는 오픈소스 DBMS이다. postgres(포스트그리)라고도 많이 부른다. 조회 성능적인 측면에서 뛰어나기 때문에 MySQL처럼 함께 많이 사용된다. http://www.postgresql.org/

https://d2.naver.com/helloworld/227936 , 1986년 Ingres에서 시작하여 1995년에 Postgres95 이름이 처음 붙여졌다.

https://techblog.woowahan.com/6550/

Aurora MySQL vs Aurora PostgreSQL | 우아한형제들 기술블로그

 

 

 

🍀  PostgreSQL 는 어떤 기준으로 사용해야할까요?

중요한 내용은 아니라서, 궁금하면 눌러보자

전세계에서 가장 많이 사용하는 데이터베이스를 한번 훑어서 비교해보면 아래와 같다.

https://db-engines.com/en/ranking - 2021년 10월 기준

Orcale과 Microsoft 는 유료 데이터베이스 서비스이고 MySQL과 PostgreSQL은 오픈소스 무료 데이터베이스이다.

보통 MySQL과 PostgreSQL의 인기가 많으며 회사나 관공서처럼 사후지원이 필요한 상용서비스는 비싼 요금을 지불하고 Oracle, Microsoft를 주로 사용한다고 생각하면 된다.

 

여담으로 2010년대는 다양한 DBMS들이 우후죽순으로 탄생하던 시기였다.

모바일의 등장으로 전통적인 관계형 데이터베이스, RDBMS의 시대는 저문다는 이야기가 나왔고 NoSQL과 같은 단순한 로그 성격의 빅데이터의 저장이 필요해지며 Cassandra나 HBase, 나중에 나온 MongoDB등이 많은 관심을 받았었다.

 

하지만 10년이 지난 지금, 그 누구도 그때 출시됐던 NoSQL DBMS가 상용 데이터베이스를 잠식했다고는 언급하지 않는 듯 하다.

* 캐시 서버로 많이 사용되는 Redis와 Memcached는 서비스 DBMS라고 보기에는 범주가 약간 다르다. ElasticSearch도 마찬가지

그나마 HBase와 MongoDB정도가 자기만의 영역에서 사용되고 있으며 예상과는 다르게 여전히 MySQL, Postgres와 같은 관계형 DB가 수많은 NoSQL DBMS의 역할을 대체하며 사용되고 있다.

 

 

오픈소스 DB 대결, MySQL vs Postgres

원래 무료 DBMS중에선 MySQL 사용률이 압도적이었으나 2009년에 오라클이 Sun사를 인수하면서 MySQL의 소유권 이슈, 유료화등의 문제 때문에 PostgreSQL 사용률이 증가했고 이후 이래의 장점들 덕분에 사용률이 꾸준하게 증가되고있다.

https://news.hada.io/topic?id=8018

https://news.hada.io/topic?id=11287

https://news.hada.io/topic?id=8018&utm_source=slack&utm_medium=bot&utm_campaign=T03385HMGMD

PostgreSQL 장점

• PostgreSQL은 SQL 표준을 경쟁사보다 잘 지키고 있는 편이다.
• 다양한 join 방법 (sort merge join , hash join)을 제공하여 복잡한 조회 쿼리 성능이 좋다.
• PostGIS(좌표계)와 같은 다양한 확장 플러그인을 제공한다.

PostgreSQL 단점

• update 를 과거 행을 삭제하고 새로운 행을 추가하는 형식이라 경쟁사에 비해 성능이 떨어지는 편이다
  즉 수정보다 insert 를 주로 하고 복잡한 조회가 많은 서비스에서 적합하다.
• MVCC 가 추가 저장하는 식으로 구현되어있다. 이후 마치 Java GC 처럼 auto vaccum을 통해 죽은 데이터들을 정리한다. 즉 auto vaccum 동작에 대해 잘 알고 있지않고 사용한다면 죽은 데이터가 쌓여 성능 저하를 일으킬 수도 있다.

 

 

 

 

🍀 Postgre MVCC 와 vaccum

MVCC(Multi-Version Concurrency Control)는 여러 트랜잭션에서 락을 걸지 않고 동시성을 관리해 성능을 높이는 방법을 의미한다.

postgreSQL의 MVCC는 수정후 데이터를 통으로 insert한 뒤 나중에 따로 vaccum 해준다. 이 방법으로 동시성과 성능을 극대화시켰다.

MySql은 undo log로 구현한거라 일정시간 이후 메모리에서 정리한다. postgre는 같은 공간에 데이터를 계속 쌓는 형식이라 GC(vaccum)이 필요하다.

 

다시 설명하자면 (* 트랜잭션ID = tx_id , 데이터 레코드 = Tuple )

• Postgre MVCC는 트랜잭션이 시작하게 되면 본인의 id 를 할당받는다.
• 이후 UPDATE등을 할 때 page (=Free Space Map page)를 생성하고 변경될 때 마다 현재의 스냅샷을 insert 형식으로 쌓아간다.
• MVCC 구현을 위해 현재 데이터 페이지 내에 자신의 tx_id 보다 작은값의 id를 가진 Tuple을 읽어온다.

이 때 각 Tuple에 할당되는 tmin, tmax값은 아래와 같다.

• xmin (*tx_id min)
  - INSERT 시  -> 신규 Tuple 의 xmin 에 tx_id 할당
  - UPDATE 시 -> 신규 Tuple 의 xmin 에 tx_id 할당
• xmax (*tx_id max)
  신규 Tuple 의 xmax 에는 NULL 할당
  DELETE 시 -> 이전 Tuple 의 xmax 에 tx_id 할당
  UPDATE 시 -> 이전 Tuple 의 xmax 에 tx_id 할당, 

이 과정 속에서 여러번 변경되어 쓸모없어진 이전 데이터들은 어디에도 참조되지 않는데, 이를 dead tuple이라고 부른다.

이 dead tuple은 수동 명령어로 지울 수도 있지만 다행히도 postgre auto vaccum을 통해 대부분 처리된다.

 

 

🤔 vaccum이 대체 뭐죠? 안하면 어떻게 되는거죠?

참고로 서비스 트래픽이 엄청난 대기업이라면, Postgre auto-vaccum 설정도 반드시 확인해보아야한다.

 

우선 Postgre에서는 Vaccum과 Vaccum full 2가지 종류가 있는데, full 의 경우 디스크 메모리까지 정리하지만 테이블에서 베타락을 걸어 DML, 쿼리 어떠한 것도 하지 못하고 시간도 오래걸린다. 운영도중에는 가능하면 vaccum full 작업을 피해야 하기에 auto vaccum 기본 값은 vaccum full 작업을 하지 않게 설정되어있다. 디스크 메모리 부족 등 최악의 경우에만 사용하자. 단순히 특정 테이블에서 생긴 문제라면 ALTER TABLE로 새로운 테이블을 만드는게 더 낫다. + 참고로 Truncate로 통째로 날리면 dead tuple도 함께 정리된다.

-- DB 전체 풀 실행
vacuum full analyze;

-- DB 전체 간단하게 실행
vacuum verbose analyze;

-- 해당 테이블만 간단하게 실행
vacuum analyse [테이블 명];

-- 특정 테이블만 풀 실행
-- 참고로 full 실행시 pg_class.relfilenode 가 변경되는데, 이는 디스크에 저장되는 물리적인 파일명이다.
vacuum full [테이블명];

 

일반 vaccum 작업은 락은 안걸리지만 Disk I/O 부하를 만들고 동시에 작업중인 다른 DB 세션의 성능을 떨어뜨린다. 그래서 수동으로 실행시 사용량이 적은 새벽시간대에 vaccum 명령을 하는 것을 권장한다. 물론 이는 관련 설정 변경으로 어느정도 조절은 가능하다. 

 

다행히 이는 사용자가 매번 신경 쓸 필요가 없도록 auto-vaccum에 의해 처리된다.
auto-vaccum은 메모리 공간을 줄인다기보단, 주기적으로 vaccum을 돌려 일정 수준 이상 커지지 않게 만들어주도록 동작한다. 또한 죽은 데이터를 삭제한 후 쿼리(인덱스) 통계 정보가 바뀔 필요가 있다고 판단되면 ANALYZE 명령을 추가로 수행한다. 단순히 삭제된 데이터수를 기준으로 판단하는건 아니고, 칼럼의 변경빈도나 자료형등 여러 조건을 고려하여 현재 정리한 테이블에만 analyze를 한다.

 

auto-vaccum 은 여러개의 데몬 프로세스(autovaccum launcher)로 항상 실행되어 있으며 테이블의 자료가 많이 변경되었을 때  (autovaccum worker) 프로세스를 만들어서 자동으로 실행된다. 이는 다른 작업을 방해하지 않으나 share update lock의 경우에만 vaccum이 중단되고, 해당 락을 계속 잡고 있는 경우 vaccum이 제대로 완료되지 않을 수 있다. 당연한말이지만 db max_connection 같은 옵션과 autovaccum 프로세스는 아무런 관련이 없다.  

 

참고로 현재 실행중인 vaccum 세션은 아래와 같이 확인해볼 수 있다.

SELECT datname, usename, pid, CURRENT_TIMESTAMP - xact_start AS xact_runtime, query
FROM pg_stat_activity
WHERE upper(query) LIKE '%VACUUM%'
ORDER BY xact_start;

 

 

 

PostgreSQL에서 VACUUM 명령은 다음과 같은 여러 가지 이유로 정기적으로 각 테이블 단위로 실행되어야 한다

1. 죽은 tuple 때문에 생기는 불필요한 추가 Disk I/O와 메모리 공간을 줄이기 위해  필요하다.
2. 트랜잭션 ID 겹침이나, 다중 트랜잭션 ID 겹침 상황으로 오래된 자료가 손실 될 가능성을 방지해야할 필요가 있다.
3. PostgreSQL 쿼리 실행 계획기가 사용할 자료 통계 정보(ANALYZE)를 갱신할 필요가 있다.
4. 커버리지 인덱스(only index) 속도를 위해, 실자료 지도(visibility map, vm) 갱신할 필요 있다.

 

 

1️⃣ 죽은 tuple 때문에 생기는 불필요한 추가 Disk I/O와 메모리 공간을 줄이기 위해 필요하다.

Postgre는 데이터를 읽을 때 FSM page (Free Space Map page) 단위로 읽어들인다. 이는 기본 8KB인데 페이지에 쓰레기 데이터가 많다면 더 많은 FSM page를 메모리에 올려야한다. 즉 메모리가 낭비되는건 물론이고 Disk I/O 작업 횟수를 늘리게 되고 쌓이면 쌓일수록 쿼리의 성능 저하로 이어지게 된다.

원래 2페이지로 끝날 걸 죽은 데이터 때문에 수십만 개의 페이지를 더 읽어야할지 모른다. 이는 곧 Disk I/O의 증가 = 쿼리의 성능 하락을 의미한다.

 

참고로 이렇게 불필요한 페이지를 많이 읽게되면, 인덱스가 멀쩡히 있음에도 인덱스를 사용하지않는 황당한 상황도 발생할 수 있다.

 

 

2️⃣ 트랜잭션 ID 겹침으로 오래된 자료가 손실 될 가능성을 방지해야할 필요가 있다.

Postgre MVCC에 사용되는 트랜잭션 ID는 32bit 양수이기에 42억 개까지만 저장할 수 있다. 이 수를 초과하면 오버플로우로 0이 되면서 데이터가 손실될 가능성이 있다. 문제를 방지하기위해 설정된 수치를 넘게되면 auto-vaccum 을 이용해 테이블의 모든 트랜잭션 ID를 따로 예약된 Fronzen xid(2)로 바꿔버린다. 이를 freeze (또는 anti wraparound vaccum)라고 부른다. 참고로 Postgre는 트랜잭션 ID가 Fronzen xid로 되어있다면, 값을 비교하지않고 무조건 옛날 Tuple로 판단한다.

최대값이 40억개라, 20억개가 되기전에 Freeze 해서 초기화해야 겹침없이 XID를 쌓아서 쓸 수 있다.

참고로 PostgreSQL 9.4 이전에는 단순히 xmin = 2 (Fronze xid) 로 덮어씌워서 저장했는데 새 버전에서는 별도의 flag(1bit) 값으로 표시해두고 두고 xmin을 변경하지는 않기에 장애 분석용으로 사용될 수도 있다. 

 

이 임계치는 vacuum_freeze_min_age 으로 변경할 수 있으며, 기본 최대값은 5000만이다.

실제 동작에서는 즉시 auto-vaccum이 실행되는 건 아니고 freeze가 필요한 Tuple이 생기면 테이블 파라메타(vacuum_freeze_table_age)  값에 저장해두었다가 설정된 임계치(autovacuum_freeze_max_age) 를 넘게되면 강제로 freeze(Anti Wraparound Vaccum)를 수행한다.

 

그럴 일은 없겠지만 auto-vaccum이 무한정 실패해서 트랜잭션ID 겹침문제가 발생할 우려가 있다면, 아래의 경고 메시지를 띄워주고

WARNING:  database "mydb" must be vacuumed within 10985967 transactions
HINT:  To avoid a database shutdown, execute a database-wide VACUUM in that database.

 

이를 무시하고 계속 사용한다면 아래 오류 메시지를 남기며 Postgre 서버는 모든 트랜잭션 작업을 중단한다.

ERROR:  database is not accepting commands to avoid wraparound data loss in database "mydb"
HINT:  Stop the postmaster and use a standalone backend to VACUUM in "mydb".

 

만약 우리 DB에서 오래된 트랜잭션ID가 어느정도인지 궁금하다면, pg_class 와 pg_database 테이블로 확인할 수 있다.

-- relfrozenxid 은 vaccum 정리했던 기준 트랜잭션ID값 이다. (이 값보다 오래된 모든ID는 freeze 처리됨)
-- age는 현재 시점기준, vaccum으로 정리된 가장 오래된 트랜잭션ID값 이다.
SELECT c.oid::regclass as table_name,
       greatest(age(c.relfrozenxid),age(t.relfrozenxid)) as age
FROM pg_class c
LEFT JOIN pg_class t ON c.reltoastrelid = t.oid
WHERE c.relkind IN ('r', 'm');

SELECT datname, age(datfrozenxid) FROM pg_database;

 

 

여담으로 Postgre 9.3 이후로 다중 트랜잭션 ID 겹침문제가 공식문서에 추가되었는데, 설명은 위와 크게 다르지 않으므로 궁금하면 문서를 읽어보자.

 

 

3️⃣ PostgreSQL 쿼리 실행 계획기가 사용할 자료 통계 정보(ANALYZE)를 갱신할 필요가 있다.

이는 위에도 언급했지만, auto-vaccum 과정속에서 필요에 따라 ANALYZE를 추가로 실행한다.

실제 DB 버전을 바꾸거나 마이그레이션하는 경우 실행계획이 크게 달라져 장애가 발생할 수 있는데, 이때 쿼리를 계속 실행시켜주거나 ㅇANALYZE 명령을 입력하면 Postgre 서버가 알맞은 실행계획으로 최적화 해준다.

 

여담으로 anaylze는 아래와 같이 사용할 수 있다.

# 데이터베이스
analyze;

# 테이블
analyze t1;

# 컬럼
analyze t1 (c1, c2);

# 상세 수행내역 확인
analyze verbose t1;
-- INFO:  analyzing "public.t1"
-- INFO:  "t1": scanned 443 of 443 pages, containing 100000 live rows and 0 dead rows; 30000 rows in sample, 100000 estimated total rows
-- ANALYZE

 

또한 아래의 설정을 건드린 적이 없다면, 기본적으로 auto-vaccum 은 실행하면서 통계 정보를 같이 수집하여 판단 기준에 사용하는데 필요하면 pg_class, pg_stats 등의 테이블로 확인해볼 수 있다.

• autovacuum (기본값 on) : autovacuum 프로세스 사용 여부
• track_counts (기본값 true): 데이터베이스 통계정보 수집여부
• autovacuum_analyze_scale_factor (기본값0.1) : 테이블 내의 레코드 변경 비율
• autovacuum_analyze_threshold (기본값 50) : 최소 변경 레코드 수

#------------------------------------------------------------------------------
# postgresql.conf 파일 내 AUTOVACUUM PARAMETERS
#------------------------------------------------------------------------------
#autovacuum = on                        # Enable autovacuum subprocess?  'on'  ## PostgreSQL 9.x 부터는 default로 활성화된 상태임
                                        # requires track_counts to also be on.
#log_autovacuum_min_duration = -1       # -1 disables, 0 logs all actions and   ## 0면  autovacuum 일어날때마다 로그 남기고,
                                        # their durations, > 0 logs only           200ms 설정하면 200ms 이상 걸려 실행되는
                                        # actions running at least this number
                                        # of milliseconds.
#autovacuum_max_workers = 3             # max number of autovacuum subprocesses
                                        # (change requires restart)
#autovacuum_naptime = 1min              # time between autovacuum runs     ## 실행 주기.. 1min 넘 짧네..
#autovacuum_vacuum_threshold = 50       # min number of row updates before ## vacuum 작업시 최소 갯수.. 1000이상으로 늘려도 됨
                                        # vacuum
#autovacuum_analyze_threshold = 50      # min number of row updates before ## 마찬가지 500이상
                                        # analyze 
#autovacuum_vacuum_scale_factor = 0.2   # fraction of table size before vacuum
#autovacuum_analyze_scale_factor = 0.1  # fraction of table size before analyze
#autovacuum_freeze_max_age = 200000000  # maximum XID age before forced vacuum
                                        # (change requires restart)
#autovacuum_vacuum_cost_delay = 20ms    # default vacuum cost delay for
                                        # autovacuum, in milliseconds;
                                        # -1 means use vacuum_cost_delay
#autovacuum_vacuum_cost_limit = -1      # default vacuum cost limit for
                                        # autovacuum, -1 means use
                                        # vacuum_cost_limit

실제로 쿼리 실행계획 (EXPLAIN ANALYZE)을 측정할 때 해당 통계 테이블들을 사용한다.

 Postgre 실행계획 및 통계 - 쿼리성능 분석하기 seunghyunson

 

 

 

4️⃣  커버리지 인덱스(only index) 속도를 위해, vm(visibility map, vm) 갱신할 필요 있다.

3번 ANAYLZE와 는 조금 다른내용인데, postgre는 vaccum 작업을 통해 내부의 visibility map을 갱신해서 현재와 미래의 모든 트랜잭션이 실제로 사용할 테이블별 지도를 미리 만들어둔다.

https://postgresql.kr/docs/13/storage-vm.html 를 구글번역한 내용

 

이는 인덱스 전용 쿼리들 (커버리지 인덱스) 에 대해 빠른 응답을 제공하는데 사용된다. PostgreSQL의 인덱스는 어떤 자료를 어떤 DB 세션에 보여줘야할지 결정하기 위해 테이블의 page를 읽어보는데,  만약 vaccum 때 미리 만들어둔 visibility map 만으로 찾아서 실제 page 데이터를 검색하지 않고 바로 찾기에 데이터가 많은 테이블을 조회할 때 Disk I/O를 크게 줄일 수 있다. 

 

 

 

🍀 실제로 있었던 Vaccum 이슈

사내에서 사용자의 학습상태를 관리하기위해 SpringStateMachine를 사용해서 각각의 사용자의 학습상태(Context) 객체를 직렬화한 뒤 계속 업데이트하여 DB에 저장하고 있었다.

create table state_machine (
     machine_id varchar(255) not null,
     state varchar(255),
     state_machine_context oid,
     primary key (machine_id)
);

 

postgres에서는 lobs(Large Objects) 를 저장할 때 식별용 oid 값 칼럼에 저장해두고 실제 데이터는 pg_largeobject 테이블에 따로 저장된다.

 

🤔 그래서 뭐가 문제였죠?

여기서 문제가 되었던건 oid 값은 auto-vaccum이 처리해주지만 large_object에 저장되어있는 데이터는 oid와의 링크 때문에 dead tuple로 취급되지 않아 지워지지 않았다. 아마 oid를 업데이트하더라도 기존 데이터 수정이 아닌 새로운 row가 추가되는 형식이었기 때문으로 추측한다. 

 

학습상태 특성상 굉장히 자주 업데이트 되는데, 위 테이블에 보이는 data(Hex)가 수정 될 때 마다 dead tuple이 계속 쌓이게 되어 수동으로 vaccum을 해주지 않으면 점점 성능이 느려지는 이슈가 있었다. 💣 위에도 언급했지만 Dead Tuple이 쌓이면 불필요한 page를 엄청나게 읽어 Disk I/O가 증가하는건 물론 실행계획이 바뀌어 인덱스 자체를 안타게 변경될 수도 있다.

 

문제해결은 간단했다. 아래 명령을 통해 oid 와 링크를 해제해주면 auto-vaccum이 동작한다.

SELECT lo_unlink($oid값)

 

다행히 이는 알려진 이슈라서, Postgre github에 이미 만들어둔 VaccumIO가 이미 있다. 이는 모든 테이블에 oid와 pg_largeobject의 oid를 비교하여 지워진 oid를 unlink 하도록 동작한다.

 

다만 주의해야할 것은 lo_unlink 자체의 쿼리가 무겁고, lock을 걸기에 운영중에는 조심해서 사용해야한다. 테스트해보니 아예 서비스를 중지해야할 정도는 아니라서 새벽 시간대 배치 스크립트를 통해 VaccumIO를 실행하도록 해서 해결했었다.

아래 두 스크립트를 도커 이미지에 말아서 `docker run` 으로 실행할 수 있게 만들어 새벽마다 vaccumIo를 실행하도록 만들었다.

# vacuumioscript.sh

#!/bin/bash
echo "*:*:*:*:$DB_PW" > ~/.pgpass
chmod 600 ~/.pgpass
vacuumlo -h ${DB_URL} -p 5432 -U postgres -w ${DRY_RUN} -v lms -l ${LIMIT}

FROM postgres:14.3-alpine

ENV DB_URL=...
ENV DB_PW=...
ENV DRY_RUN="--dry-run" # vaccumlo --dry-run 을통해 현재 DB가 large object를 사용하는지 확인가능
ENV LIMIT=500

COPY vacuumioscript.sh vacuumioscript.sh
RUN chmod 775 vacuumioscript.sh

ENTRYPOINT ["./vacuumioscript.sh"]

 

 

그 당시에는 별 생각없이 큰데이터? 그럼 LOB에 저장하면 되겠지하고 선택했고 vaccum 동작에 대해서도 무지했는데

 

이후 더 찾아보니 LargeObject(oid)가 아닌 bytea 로 바로 저장하면 auto-vaccum이 정상적으로 처리됨을 확인하고 타입을 변경해서 해결했다. 물론 일반적인 테이블에 lob -> bytea 로 변경하면서 조회 성능이 저하될 수 있지만, 해당 테이블은 stateContext 의 크기가 고정되어있기도 하고 사용자 1명이 고유한 ID로 자신의 데이터만 사용하는 구조라 별 문제 없었다.

@Entity
@Table(name = "jiwon_state_machine")
@JsonIdentityInfo(generator = ObjectIdGenerators.IntSequenceGenerator::class)
class LmsStateMachineEntity : RepositoryStateMachine() {

  @Id
  @Column(name = "machine_id")
  private var machineId: String? = null

  @Column(name = "state")
  private var state: String? = null

  // @Lob 제거, bytea 타입으로 바로 저장
  @Column(name = "state_machine_context", length = 10240)
  private var stateMachineContext: ByteArray? = null
}

create table jiwon_state_machine (
     machine_id varchar(255) not null,
     state varchar(255),
     state_machine_context bytea,
     primary key (machine_id)
);

 

 

🍀 다른 사례

여담으로 Postgre를 딥하게 사용한다면 한번씩 겪는 문제가 Vaccum 이슈인데, 내가 겪은 @Lob과 같은 특수한 상황이 아니더라도 데이터량이 많아지면 auto-vaccum이 잘 되지않아 Dead Tuple로 인해 비슷한 이슈가 발생할 수 있다. 아래 29CM Auto-vaccum 장애 대응기도 꼭 한번 읽어보기를 추천한다. 

PostgreSQL Autovacuum 장애 대응기 (1)

 

 

 

 

📚 레퍼런스

한눈에 살펴보는 PostgreSQL - https://d2.naver.com/helloworld/227936

 

PostgreSQL Vaccum에 대한 거의 모든 것 https://techblog.woowahan.com/9478/

 

AWS Article 1편- https://repost.aws/ko/articles/ARbMXOvsOvTeCuiuoxSZxuwA/amazon-aurora-postgre-sql-auto-vacuum-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-1-2

 

AWS Artice 2편 - https://repost.aws/ko/articles/ARdulMK-V2QJueMZ5SmKnk8Q/amazon-aurora-postgre-sql-auto-vacuum-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-2-2

 

Postgre13 Docs - https://postgresql.kr/docs/13/routine-vacuuming.html

 

Vaccum을 실행해야하는 이유, 성능향상 - https://blog.gaerae.com/2015/09/postgresql-vacuum-fsm.html

 

Postgre Wiki - 개발철학 https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server