본문 바로가기
스터디/PostgreSQL

PostgresSQL 아키텍쳐

by 취미툰 2023. 11. 30.
반응형

PostgreSQL은 클라이언트 - 서버 모델 기반입니다.

Postmaster라는 메인 프로세스와 파생된 프로세스들로 구성되어 있습니다.

 

간단히 아키텍쳐를 설명한 그림이 있어서 첨부하였습니다.

출처 : https://www.cloudduggu.com/postgresql/architecture/

 

 

OS에서 확인한 PostgreSQL의 프로세스.

[root@ysbae ~]# ps -ef |grep postgres
postgres   970     1  0 14:45 ?        00:00:00 /usr/bin/postgres -D /var/lib/pgsql/data -p 5432
postgres   972   970  0 14:45 ?        00:00:00 postgres: logger process
postgres   974   970  0 14:45 ?        00:00:00 postgres: checkpointer process
postgres   975   970  0 14:45 ?        00:00:00 postgres: writer process
postgres   976   970  0 14:45 ?        00:00:00 postgres: wal writer process
postgres   977   970  0 14:45 ?        00:00:00 postgres: autovacuum launcher process
postgres   978   970  0 14:45 ?        00:00:00 postgres: stats collector process
root      1191  1173  0 14:48 pts/0    00:00:00 grep --color=auto postgres

 

1) postgres(postmaster)

DB를 기동/중지하기 위한 필수 프로세스이자, 가장 먼저 시작되는 프로세스.

위의 OS상에서는 이 프로세스가 되겠네요.

postgres   970     1  0 14:45 ?        00:00:00 /usr/bin/postgres -D /var/lib/pgsql/data -p 5432

 

역할로는 다양한 백그라운드 프로세스를 시작하고,

Shared Memery 영역을 할당하고,

Client의 연결요청을 대기하며, Client로부터 연결요청이 생기면 Connect를 위한 프로세스를 생성하기도 하고,

최상위 프로세스로써 하위 프로세스들의 비정상 작동 유무를 체크하고 문제 발생시 재기동하는 역할도 수행합니다.

 

2) Postgres Backend Process

Client가 요청한 SQL 및 Command를 처리하는 프로세스로 Client와의 연결이 끊어지면 종료

Postmaster 프로세스에 의해 시작되며 Client와는 1:1관계

max_connections 수치만큼 Client가 동시에 연결될 수 있으며 ,OS 상에 그 수만큼 프로세스들이 떠있게 됩니다.

 

아래는 pgadmin으로 접속을 했을 때 나타난 backend process입니다. 세션이 여러개가 되면 이와 같은 프로세스들이 여러개 뜹니다.

postgres  1278  1258  0 14:59 ?        00:00:00 postgres: postgres postgres 10.0.2.2(64324) idle

 

3) 백그라운드 프로세스

BG_Writer (Writer)

Shared Buffer의 Dirty Block을 디스크에 기록하는 프로세스입니다.

bgwriter_delay 주기로 최대 bgwriter_lru_maxpages를 디스크에 기록하며

주기적으로 디스크에 기록함으로써, Checkpoint발생 시 flush해야하는 Dirty Block의 양을 줄일 수 있어 안정된 I/O를 유지할 수 있습니다.

postgres  1262  1258  0 14:55 ?        00:00:00 postgres: writer process

 

pg_settings의 값을 확인해보니 delay 주기는 기본 200ms이고,한번에 최대 100개의 블록을 disk로 쓸수 있게 default 세팅으로 되어 있습니다.

SELECT name, context , unit
, setting , boot_val , reset_val
FROM pg_settings
WHERE name
in('bgwriter_delay','bgwriter_lru_maxpages')
ORDER BY context,name;

name                 |context|unit|setting|boot_val|reset_val|
---------------------+-------+----+-------+--------+---------+
bgwriter_delay       |sighup |ms  |200    |200     |200      |
bgwriter_lru_maxpages|sighup |    |100    |100     |100      |

 

WAL Writer

WAL buffer라는 로그를 주기적으로 확인하여 기록되지 않은 모든 트랜잭션 레코드를 디스크(WAL 파일)에 기록합니다.

트랜잭션의 Commit 또는 로그파일 공간이 모두 다 찼을때 WAL Buffer를 디스크에 내려쓰며, 향 후 DB 복구에 사용됩니다.

postgres  1263  1258  0 14:55 ?        00:00:00 postgres: wal writer process

 

관련된 파라미터입니다.

fsync는 PostgreSQL 서버에서 파일 작성 시 OS의 fsync를 호출하여 파일 작성 성공을 보장하는 파라미터입니다.

wal_writer_delay는 wal writer 기록간 sleep 시간입니다.

synchronous_commit은 client에세 commit success를 보내기 전 wal파일의 disk기록을 보장합니다.

SELECT name, context , unit
, setting , boot_val , reset_val
FROM pg_settings
WHERE name
in('wal_level','fsync','synchronous_commit','wal_writer_delay')
ORDER BY context,name;

name              |context   |unit|setting|boot_val|reset_val|
------------------+----------+----+-------+--------+---------+
wal_level         |postmaster|    |minimal|minimal |minimal  |
fsync             |sighup    |    |on     |on      |on       |
wal_writer_delay  |sighup    |ms  |200    |200     |200      |
synchronous_commit|user      |    |on     |on      |on       |

 

Checkpointer

Checkpoint를 수행하는 프로세스이고, 9.2이상버전부터 생겼습니다.

이전 버전에서는 Writer 프로세사가 주기적으로 체크포인트를 수행하였습니다.

PostgreSQL 서버 다운 또는 충돌등의 문제가 발생한 경우, 마지막 체크포인트 레코드를 확인하여 복구작업을 시작합니다.

postgres  1261  1258  0 14:55 ?        00:00:00 postgres: checkpointer process

 

300초가 default입니다. 300초마다 체크포인트가 자동적으로 발생하네요.

SELECT name, context , unit
, setting , boot_val , reset_val
FROM pg_settings
WHERE name --like '%wal%'
in('checkpoint_timeout','max_wal_size')
ORDER BY context,name;

name              |context|unit|setting|boot_val|reset_val|
------------------+-------+----+-------+--------+---------+
checkpoint_timeout|sighup |s   |300    |300     |300      |

 

Archiver

아카이빙을 실행하는 프로세스

WAL 세크먼트가 전환될 때 WAL 파일을 아카이브영역으로 복사하는 기능입니다.

현재 테스트DB에는 off로 되어있어서 프로세스가 따로 떠있지는 않습니다.

해당 파일은 PITR 복구시 사용됩니다.

 

SELECT name, context , unit
, setting , boot_val , reset_val
FROM pg_settings
WHERE name --like '%wal%'
in('archive_mode','archive_command','archive_timeout')
ORDER BY context,name;

name           |context   |unit|setting   |boot_val|reset_val|
---------------+----------+----+----------+--------+---------+
archive_mode   |postmaster|    |off       |off     |off      |
archive_command|sighup    |    |(disabled)|        |         |
archive_timeout|sighup    |s   |0         |0       |0        |

 

Stat Collector

통계정보를 수집하는 프로세스

세션정보 및 테이블 통계정보와 같은 DBMS 사용통계를 수집하여 pg_catalog에 정보를 업데이트합니다.

옵티마이저는 최적의 실행계획을 생성하기 위해 해당 정보를 참조합니다.

postgres  1265  1258  0 14:55 ?        00:00:00 postgres: stats collector process

 

Logger

오류메세지를 로그파일에 기록하는 프로세스

모든 프로세스들의 정보를 $PGDATA/pg_log아래에 저장됩니다.

 

postgres  1259  1258  0 14:55 ?        00:00:00 postgres: logger process

 

Autovacuum Launcher

Autovacuum launcher을 수행/관리하는 프로세스.

autovacuum Workers라는 여러 개의 프로세스로 구성된 데몬 프로세스이며 autovacuum workers 프로세스를 주기적으로 호출하여 vacuum 및 vacuum analyze를 실행합니다.

postgres  1264  1258  0 14:55 ?        00:00:00 postgres: autovacuum launcher process
SELECT name, context , unit
, setting , boot_val , reset_val
FROM pg_settings
WHERE name --like '%wal%'
in('autovacuum','autovacuum_max_workers','autovacuum_naptime')
ORDER BY context,name;

name                  |context   |unit|setting|boot_val|reset_val|
----------------------+----------+----+-------+--------+---------+
autovacuum_max_workers|postmaster|    |3      |3       |3        |
autovacuum            |sighup    |    |on     |on      |on       |
autovacuum_naptime    |sighup    |s   |60     |60      |60       |

 

 

메모리

두가지 범주로 구분됩니다.

Local memory와 shared memory입니다.

local memory는 backend프로세스가 사용하기 위해 할당되고

shared memory는 postgresql내의 모든 프로세스에서 사용합니다.

 

Shared Memory

Shared Buffer

Data와 Data 변경사항을 Block단위로 캐싱하여 I/O를 빠르게 처리하기 위한 영역

postgresql.conf의 shared_buffers 파라미터 값으로 크기를 설정할 수 있습니다.

shared_buffers = 32MB                   # min 128kB

1GB 이상의 RAM이 있는 서버의 경우 시스템 메모리의 25%를 권장합니다.

Shaerd Buffer에 기록되는 단위는 Block 단위입니다.

 

Wal Buffer

세션들이 수행하는 트랜잭션에 대한 변경로그를 캐싱하는 공간입니다.

postgresql.conf의 wal_buffers파라미터 값으로 크기를 설정할 수 있습니다.

#wal_buffers = -1                       # min 32kB, -1 sets based on shared_buffers

저의 테스트서버는 주석처리가 되어있네요.

 

CLOG Buffer

각 트랜잭션의 상태 정보를 캐싱하는 공간(in_progress,commited,aborted)

따로 사이즈를 설정할 수 있는 파라미터는 없으며 자동관리됨.

 

Lock Space

Lock과 관련된 내용을 보관하는 영역

 

Local Memory

개별 backend 프로세스가 할당받아 사용하는 공간.

maintence work memory

유지관리 작업에 사용되는 메모리

postgresql.conf의 maintence_work_mem 파라미터 값으로 설정할 수 있음.

#maintenance_work_mem = 16MB            # min 1MB

주석처리가 되어 있네요.

 

Temp buffer

postgresql.conf의 temp_buffers의 파라미터 값으로 설정할 수 있움.

Temp테이블을 사용하는 경우에만 할당되는 영역이며 세션 단위로 할당되는 비 공유 메모리영역이므로 과도한 Temp 테이블 사용시 문제를 야기할 수 있음.

해당 영역은 Temp파일과 상관없음.

#temp_buffers = 8MB                     # min 800kB

 

work memory

Sort/Hash 작업이 발생하여 Temp파일을 사용하기 전에 사용되는 공간

postgresql.conf의 work_mem의 파라미터값으로 설정할 수 있음.

여러 세션에서 과도하게 사용시 문제가 될 수 있음.

#work_mem = 1MB                         # min 64kB

 

 

오라클과 비슷하면서 다른부분이 있네요.

vacuum이라는건 이 DB만의 특징인거 같습니다.

postgresql를 운영할 일이 많아질거 같아서 꾸준히 정리해서 올리도록하겠습니다.(__)

 

출처 : tmax OpenSQl for PostgresSQL 교육자료

반응형

댓글