DB 인사이드 | PostgreSQL Architecture - 1. Process, Memory

 

 

엑셈은 창사 이래 꾸준히 축적해온 IT 시스템 성능 관리 경험과 연구 역량을 토대로 전문적이고 차별화된 컨설팅 서비스를 제공하고 있습니다. DBMS 전문가 엑셈에서 새롭게 선보이는 ‘DB인사이드’는 다양한 DBMS와 기술에 대해 소상히 알려드릴 예정입니다. 많은 관심과 응원 부탁드립니다.

 

‘DB인사이드’의 첫 시작은 PostgreSQL로 열어볼까 합니다. PostgreSQL은 오픈소스로, 객체 관계형 DBMS입니다. RDB와 NoSQL을 모두 지원하며, 최근 클라우드 환경에서 주목받고 있는 DB 중 하나입니다.

 

주요 Process

PostgreSQL은 postmaster와 postgres라고하는 Server 프로세스를 통해 커넥션을 생성하여 사용자 요청을 받으며, 이러한 요청은 다양한 백그라운드 프로세스들에 의해 처리됩니다.

 

본 글에서는 이러한 Server 프로세스와 핵심역할을 수행하는 주요 백그라운드 프로세스에 대해 알아보도록 하겠습니다.

📌 본 섹션에서 언급된 파라미터는 postgresql.conf 파일에서 설정이 가능합니다. 파라미터 관련 자세한 설명은

참고자료) Configuration File : postgresql.conf 를 참고하시면 됩니다.

 

 

postmaster : Supervisor Daemon Process

PostgreSQL 서버를 기동/중지하기 위한 필수 프로세스이자 가장 먼저 시작되는 프로세스입니다.

• postmaster 프로세스는 Shared Memory 영역을 할당하며 다양한 백그라운드 프로세스를 시작합니다.
• postmaster 프로세스는 Client의 연결 요청을 대기합니다. Client로부터 연결 요청이 생기면 postmaster는 Client를 위한 postgres 프로세스를 생성합니다.
• 가장 상위 프로세스로서 하위 프로세스들의 비정상 작동유무를 체크하며, 문제 발생시 재기동하는 역할도 수행합니다.

 

postgres 28152     1  0 Nov05 ?        00:00:06 /usr/pgsql-13/bin/postmaster -D /var/lib/pgsql/13/data/
postgres 28154 28152  0 Nov05 ?        00:00:00 postgres: logger
postgres 28156 28152  0 Nov05 ?        00:00:00 postgres: checkpointer
postgres 28157 28152  0 Nov05 ?        00:00:09 postgres: background writer
postgres 28158 28152  0 Nov05 ?        00:00:10 postgres: walwriter
postgres 28159 28152  0 Nov05 ?        00:00:04 postgres: autovacuum launcher
postgres 28160 28152  0 Nov05 ?        00:00:09 postgres: stats collector
postgres 28161 28152  0 Nov05 ?        00:00:00 postgres: logical replication launcher

# pstree -p 28152         >> postmaster 의 pid(28152)
postmaster(28152)-+-postmaster(28154) 
                  |-postmaster(28156)
                  |-postmaster(28157)
                  |-postmaster(28158)
                  |-postmaster(28159)
                  |-postmaster(28160)
                  `-postmaster(28161)

 

postgres : Backend Process

• Client가 요청한 SQL 및 Command를 처리하는 프로세스로 Client와의 연결이 끊어지면 종료됩니다.
• postmaster 프로세스에 의해 시작되며 Client 와는 1:1 관계입니다.
• max_connections (Default:100) 수치만큼 Client가 동시에 연결 될 수 있습니다.

 

Utility Process (Background Process)

PostgreSQL의 백그라운드 프로세스는 버전 별 차이가 있지만, 이 중 가장 중요한 2개의 필수 프로세스(BG Writer, WAL Writer)와 5개의 선택적 프로세스에 대해 다루도록 하겠습니다.

 

BG Writer

• Oracle의 DBWR 프로세스와 유사하며, Shared Buffer의 Dirty Block을 디스크에 기록하는 프로세스입니다.
• BG Writer는 bgwriter_delay (200 ms)주기로 최대 bgwriter_lru_maxpages (100 Pages)를 디스크에 기록합니다.
• 주기적으로 BG Writer가 Dirty Block을 디스크에 기록해두면, Checkpoint발생 시 Flush 해야 하는 Dirty Block의 양을 줄일 수 있어 안정적인 I/O를 유지할 수 있습니다.

 

WAL(Write Ahead Log/Xlog) Writer

• WAL Buffer를 주기적으로 확인하여 기록되지 않은 모든 트랜잭션 레코드를 디스크(WAL 파일)에 기록하는 프로세스입니다.
• WAL Writer는 트랜잭션 Commit 혹은 로그파일 공간이 모두 다 찼을 때 WAL Buffer를 디스크(WAL 파일)에 내려 쓰며, WAL 파일은 Database복구에 사용됩니다.

📌 WAL의 핵심 개념은 데이터파일의 수정이 트랜잭션 로그에 기록된 후에 이루어져야 한다는 것 입니다.

 

Checkpointer

• Checkpoint를 수행하는 프로세스로 PostgreSQL 9.2버전에 추가되었습니다.
• PostgreSQL 9.1버전 이하에서는 BG Writer가 주기적으로 Checkpoint를 수행하였으나, 9.2버전부터 Checkpointer 프로세스가 추가되면서 해당 기능이 BG Writer로부터 분리되었습니다.
• PostgreSQL Server 다운 또는 충돌 등의 문제가 발생한 경우, 마지막 Checkpoint 레코드를 확인하여 복구 작업을 시작합니다.

 

Checkpoint의 발생 조건은 아래와 같습니다.

1. 이전 Checkpoint 발생 이후 checkpoint_timeout(5분)의 시간이 지난 경우

2. WAL 파일의 크기가 max_wal_size를 초과하는 경우

3. smart 또는 fast 모드로 Database Server를 종료하는 경우

4. pg_basebackup 또는 pg_start_backup으로 백업을 시작하는 경우

5. super유저에 의해서 checkpoint Command를 실행한 경우

📌 단, 이전 Checkpoint 이후로 기록된 WAL이 없으면 checkpoint_timeout을 초과했더라도 새로운 Checkpoint가 발생하지 않습니다.

 

Archiver

• Oracle의 ARCH(아카이브 프로세스)와 마찬가지로 Archiving을 수행하는 프로세스입니다.
• Archiving은 WAL 세그먼트가 전환될 때 WAL 파일을 Archive영역으로 복사하는 기능이며, 복사된 WAL 파일을 Archive 파일이라고 합니다.
• Archive 영역의 경로는 archive_command로 설정하며, 복사 대신 scp 명령 또는 파일 백업도구를 설정하여 다른 호스트로 전송할 수 있습니다.
• 해당 파일은 PITR(Point In Time Recovery). 즉, Database를 특정 시점의 특정 상태로 복원하는 데 사용됩니다.

 

Stats Collector

• PostgreSQL의 Database 통계 정보를 수집하는 프로세스입니다.
• Session 정보(pg_stat_activity) 및 테이블 통계정보(pg_stat_all_tables)와 같은 DBMS 사용 통계를 수집하여 pg_catalog에 정보를 업데이트 합니다.
• Optimizer는 최적의 Query 실행 계획을 생성하기 위해 해당 정보를 참조합니다.
• Server가 완전히 종료되면 통계 정보의 복사본이 pg_stat 하위 디렉토리에 저장되므로 Server를 다시 시작해도 통계가 유지될 수 있습니다.

 

Autovacuum Launcher

• Autovacuum을 수행/관리하는 프로세스입니다.
• Autovacuum Workers라는 여러 프로세스로 구성된 Daemon 프로세스이며, 이 프로세스로 인해 vacuum 실행이 자동화됩니다.
• Autovacuum Launcher 프로세스는 Autovacuum Workers 프로세스를 주기적으로 호출하여 vacuum 및 vacuum analyze를 실행합니다.
• autovacuum_naptime(1분)마다 Autovacuum Launcher 프로세스가 Database를 확인하여 autovacuum_max_workers(3개)의 Autovauum Workers 프로세스를 호출합니다.

📌 PostgreSQL에서는 Row를 Update 할 경우, 해당 Row를 물리적으로 변경하지 않고 새로운 영역을 할당 받아 사용하기 때문에 변경 이전의 Row공간들이 재사용되거나 사라지지 않습니다. 이 영역을 정리해주는 작업(VACUUM)이 반드시 필요하며 주기적으로 해주는 것이 좋습니다.

 

Logger

• 오류메시지를 로그파일에 기록하는 프로세스입니다.
• Utility 프로세스, Backend 프로세스 및 Postmaster Daemon 활동에 대한 정보를 기록하며 모든 프로세스 정보는 $PGDATA/pg_log 아래에 저장됩니다.

 

---

Memory의 분류

PostgreSQL은 Server 시작 시 공용 메모리 공간인 Shared Memory가 할당하며 Backend 프로세스를 위한 Local Memory도 할당합니다.

 

Shared Memory란 Data Block 및 트랜잭션 로그와 같은 정보들을 캐싱하는 공간으로 PostgreSQL Server의 모든 프로세스들에 의해 공유되는 영역이기도 합니다. 또한 Process, Lock, global 통계 정보 역시 해당 영역에 위치합니다.

 

이와는 별개로, Backend 프로세스별로 할당되어 공유가 불가능한 Local Memory라는 영역도 존재하는데, 해당 영역은 Sort, Vacuum 등의 요청을 처리하기 위한 작업 영역입니다.

 

 

Shared Memory

Shared Memory는 모든 프로세스가 공유해서 사용하며 Oracle의 SGA영역과 유사합니다. Shared Memory의 구성 요소 중 대표적인 4가지 영역에 대해 알아보겠습니다.

 

Shared Buffer

• Oracle의 Buffer Cache와 유사하며 Data와 Data의 변경사항을 Block 단위로 캐싱하여 I/O를 빠르게 처리하기 위한 영역입니다.
• postgresql.conf의 shared_buffers 파라미터 값으로 크기를 설정할 수 있습니다. Default값은 128MB이며, 1GB 이상의 RAM이 있는 서버의 경우 시스템 메모리의 25%를 권장합니다.
• Shared Buffer에 기록되는 단위는 block_size (Default 8K) 단위입니다.

📌 PostgreSQL에서 Page라는 용어를 주로 사용하지만 Block과 혼용하여 사용하기도 합니다. 두 용어의 차이를 존재하는 위치에 따라 분류하기도 하지만 본 문서에서는 모두 동일한 의미로 사용합니다.

 

WAL Buffer (Write Ahead Log Buffer)

• Session들이 수행하는 트랜잭션에 대한 변경 로그를 캐싱하는 공간으로 복구 작업 시 Data를 재구성할 수 있도록 하는 영역입니다.
• postgresql.conf의 wal_buffers 파라미터 값으로 크기를 설정할 수 있습니다. Default값은 -1로 shared_buffers의 1/32와 같은 값으로 지정합니다.

 

Clog Buffer (Commit Log Buffer)

• 각 트랜잭션의 상태(in_progress, committed, aborted) 정보를 캐싱하는 공간으로 모든 트랜잭션의 상태가 있으며 완료 여부를 확인할 수 있도록 하는 영역입니다.
• 따로 사이즈를 설정할 수 있는 Parameter는 없으며 Database 엔진에 의해 자동 관리됩니다.

 

Lock Space

• Shared Memory 영역 중 Lock과 관련된 내용을 보관하는 영역으로 PostgreSQL 인스턴스에서 사용하는 모든 유형의 Lock정보를 저장합니다. (Lock정보는 모든 백그라운드 프로세스 및 사용자 프로세스에 의해 공유됩니다.)
• 사용자가 특정 테이블에 Access하는 경우, 특정 트랜잭션이 해당 테이블을 삭제 또는 수정(DDL) 하지 않도록 활동을 추적해야 합니다. 이 활동에 대한 정보를 저장하는 공간이 바로 Lock Space입니다.

📌 Lock Space에서 유지할 수 있는 Lock의 수는 max_locks_per_transaction * (max_connections + max_prepared_transactions)입니다.

 

Local Memory (Process Memory)

개별 Backend 프로세스가 할당 받아 사용하는 공간으로 Oracle의 PGA와 유사합니다. 해당 영역의 수치는 개별 공간의 크기를 의미하므로 전체 Connection 수치를 감안하여 설정해야 합니다.

 

또한 기본적으로 Local Memory는 세션 단위로 할당되지만 트랜잭션 단위로 임의 조정이 가능합니다.

 

-- 세션 단위 work 메모리 조정
SET work_mem = '16MB';

-- 트랜잭션 단위 메모리 조정
SET LOCAL work_mem = '16MB';

-- 설정 reset
RESET work_mem

 

Maintenance Work Memory

• 유지 관리 작업에 사용되는 메모리로 maintenance_work_mem의 기본값은 64MB입니다.
• Vacuum관련 작업, 인덱스 생성, 테이블 변경, Foreign Key 추가 등의 작업에 사용되는 공간입니다.
• 관련 작업의 성능을 향상시키리면 해당 영역의 사이즈를 증가시켜야 합니다.

 

Temp Buffer

• Temporary 테이블에 사용되는 공간으로 temp_buffers의 기본값은 8MB입니다.
• Temp 테이블을 사용하는 경우에만 할당되는 영역이며, Session단위로 할당되는 비 공유 메모리 영역이므로 과도한 Temp 테이블 사용시 문제가 될 수 있습니다.
• 해당 영역은 Temp 파일과 상관이 없습니다. (Work Memory 참조)

 

Work Memory

• 과도한 Sort/Hash 작업이 발생하여 Temp 파일을 사용하기 전에 사용되는 공간으로 work_mem의 기본값은 4MB입니다.
• 여타 Local Memory 와 동일하게 동시에 여러 Session에서 과도한 Sort/Hash 연산을 수행할 경우 문제가 될 수 있습니다.

📌 정렬작업(Sort) 에는 ORDER BY, DISTINCT, MERGE JOIN 등이 있으며, Hash Operation에는 HASH JOIN, HASH AGGREGATION, IN SUBQUERY 등이 있습니다.

 

Catalog Cache

• System Catalog 메타데이터를 이용할 때 사용하는 공간입니다. 세션들이 메타데이터를 조회하는 경우가 빈번하고, 이때 디스크에서 읽을 경우 속도저하가 발생할 수 있기 때문에 개별 메모리에 존재합니다.

 

Optimizer & Executor

• 수행한 Query들에 대한 최적의 실행계획을 수립하고 실행계획에 따른 실행을 담당하는 메모리 공간입니다.

 

 

 

 

기고 | 컨설팅본부 기술기획팀

 

 

 

[NOW엑셈 170회] 다른 이야기도 궁금하시다면?
🤩 엑셈 뉴스룸 | 성장하는 엑셈의 미래를 찾습니다!   ❗️ 엑셈 인사이트 | 맥스게이지, 확장과 도전 그리고 확신  🔍 DB인사이드 | PostgreSQL Architecture - Process, Memory  🧠 PHILINNOVATOR | 뇌의 진화와 1차 인지혁명 🔖 이벤트 | 'SQL Server 튜닝 가이드' 출간 이벤트