이번 장에서는 PostgreSQL의 구조에 대해 설명하겠습니다. PostgreSQL은 클라이언트-서버 모델을 사용하고 있습니다. 클라이언트는 사용자 어플리케이션과 같은 PostgreSQL을 사용하는 외부 프로그램을 의미합니다. 일반적으로 PostgreSQL(PostgreSQL 서버)은 하나의 데이터베이스 클러스터를 운영하는 프로세스 집합을 의미하며 이는 클라이언트-서버 모델에서 서버를 의미합니다. 해당 문서에서는 PostgreSQL 서버에 대해서 설명하겠습다.
프로세스 구조
PostgreSQL 서버의 프로세스 구조에 대해 논의하기 전, 실제 PostgreSQL에서 어떤 프로세스들이 동작하는지 다음 명령어를 수행하여 직접 확인해보겠습니다.
root@a4ac31d234ff:/# ps -fu postgres
UID PID PPID C STIME TTY TIME CMD
postgres 1 0 0 Jan09 ? 00:00:05 postgres
postgres 62 1 0 Jan09 ? 00:00:00 postgres: checkpointer
postgres 63 1 0 Jan09 ? 00:00:01 postgres: background writer
postgres 64 1 0 Jan09 ? 00:00:01 postgres: walwriter
postgres 65 1 0 Jan09 ? 00:00:02 postgres: autovacuum launcher
postgres 66 1 0 Jan09 ? 00:00:06 postgres: stats collector
postgres 67 1 0 Jan09 ? 00:00:00 postgres: logical replication launcher postgres 167 1 0 Jan09 ? 00:00:00 postgres: postgres postgres [local] idle postgres 6228 1 0 00:27 ? 00:00:00 postgres: postgres postgres [local] idle
본 문서에서는 위 결과와 공식 문서의 내용을 종합하여 PostgreSQL의 프로세스를 다음과 같이 3가지로 분류하고자 합니다.
Postgres 프로세스
Postgres 프로세스는 PostgreSQL의 데이터베이스 서버입니다.
Postgres is the PostgreSQL database server. / Postgres PostgreSQL Server Application
– PostgreSQL 공식 문서 –
Postgres 프로세스는 PostgreSQL 서버 시작 시, 최초로 생성되어 다른 백엔드 프로세스와 백그라운드 프로세스를 생성합니다. 일례로 Postgres 프로세스는 클라이언트로부터 커넥션 생성 요청을 받으면, 백엔드 프로세스를 새로 시작하여 새로운 커넥션에 할당합니다. 또한 PostgreSQL 필요 시(PostgreSQL 서버 시작 포함) 또는 다른 프로세스로부터 요청을 받은 경우 필요한 백그라운드 프로세스를 생성합니다.
하나의 데이터베이스 클러스터는 하나의 Postgres 프로세스에 의해 관리됩니다.
백엔드 프로세스
백엔드 프로세스는 자신에게 배정된 커넥션을 통해 요청된 쿼리 또는 명령을 수행하기 위한 일종의 워커 프로세스입니다. 해당 프로세스는 새로운 커넥션이 맺어질 때마다 Postgres 프로세스에 의해 생성(fork)되고, 커넥션이 끊어질 때 종료됩니다. 백엔드 프로세스는 커넥션과 1:1로 맵핑되며 커넥션으로 이어진 클라이언트와 TCP/IP를 기반으로 통신하게됩니다.
위 예시에서는 PID(Process ID)가 167, 6228인 프로세스가 백엔드 프로세스에 해당합니다. 부모 프로세스의 PID를 의미하는 PPID(Parent Process ID)가 1인 것으로 보아 각각의 백엔드 프로세스는 새로운 커넥션이 추가 될때마다 Postgres 프로세스에 의해 새로 생성되는 것을 확인할 수 있습니다.
PostgreSQL은 max_connections 파라미터로 최대 커넥션 갯수(Default: 100)를 조절할 수 있습니다.
특이사항으로 PostgreSQL은 내부적으로 커넥션 풀링을 사용하고 있지 않습니다. 즉, 클라이언트에서 커넥션을 맺고 끊는 과정을 반복할 경우 데이터베이스의 성능 저하가 발생하게 됩니다 (커넥션을 맺고 끊는 동작은 비용이 큰 작업입니다). 해당 문제는 pgbouncer, pgpool-II와 같은 내부적으로 커넥션 풀링을 가능하게하는 Extension을 사용하여 개선할 수 있습니다.
백그라운드 프로세스
데이터베이스를 운영하기 위해서는 쿼리를 처리하는 것 뿐만 아니라 다양한 부가 작업이 필요합니다. 이를 위해서 여러 프로세스들이 백그라운드에서 동작하고 있습니다. PostgreSQL에서는 다음과 같은 백그라운드 프로세스들이 부가 작업을 수행하고 있습니다.
각 백그라운드에 대한 설명은 다음과 같습니다.
백그라운드 프로세스 목록
| process | description | references |
|---|---|---|
| Background Writer | 공유 버퍼에 저장되어 있던 Dirty Page(데이터가 변경되었으나 디스크에 반영되지 않은 Page)를 디스크에 기록한다. | section 8.6 |
| Checkpointer | – | section 9.7 |
| Auto-vacuum Launcher | Auto-vaccum을 수행하기 위하여 Postgres 프로세스에 Auto-vaccum Worker 프로세스 생성을 요청한다. | section 6.5 |
| WAL Writer | 디스크에 기록되지 않은 WAL Buffer의 트랜잭션 레코드를 디스크에 기록. | section 9.9 |
| Statistics Collector | PostgreSQL의 세션, 테이블 등의 통계(pg_stat_activity, pg_stat_all_tables)를 수집하여 pg_catalog에 업데이트 한다. | |
| Logger | 모든 프로세스에서 발생한 오류 메시지를 pg_log 디렉토리의 로그 파일에 기록한다. | |
| Archiver | 아카이빙을 수행한다. WAL 세그먼트가 전환될 때, WAL 파일을 아카이빙 영역으로 복사하는 동작을 수행합니다. |
https://www.postgresql.org/docs/current/tutorial-arch.html
https://www.postgresql.org/docs/15/app-postgres.html
https://www.interdb.jp/pg/pgsql02.html
메모리 구조
PostgreSQL의 메모리 영역은 용도와 접근성에 따라 크게 로컬 메모리와 공유 메모리로 분류할 수 있습니다. 각 세부 메모리 영역들은 동적 또는 정적 파라미터로 조정이 가능합니다. 동적 파라미터를 지원할 경우 재시작 없이 SET 명령어로 조정이 가능하지만 정적 파라미터의 경우, postgresql.conf에 설정 후 재기동해야 변경 사항이 반영됩니다.
로컬 메모리 영역 (Local Memory Area)
로컬 메모리는 백엔드 프로세스가 각각 할당받아 사용하는 공간으로 주로 백엔드 프로세스가 자신이 담당하는 커넥션을 통해 요청된 쿼리를 수행하기 위해 사용됩니다. 로컬 메모리는 프로세스 별로 할당되므로 다른 프로세스에서 참조/접근이 불가능합니다. 로컬 메모리의 각 영역들에 대한 설명은 다음과 같습니다.
로컬 메모리 영역 목록
| sub-area | description | references |
|---|---|---|
| Work Memory | Executor에서 Sort, Hash 수행 시, Temp 파일을 사용하기 전에 사용하는 메모리 공간입니다. work_mem 동적 파라미터로 조정 가능 합니다. (default: 4MB) * Sort: ORDER BY, DISTICT, MERGE JOIN, … * Hash: HASH JOIN, HASH AGGREGATION, IN SUBQUERY, … | chapter 3 |
| Maintenance Work Memory | 데이터베이스 유지 관리 작업(vacuum, 인덱스 생성, 테이블 변경, 외래키 추가)에 사용되는 메모리 공간입니다. maintenance_work_mem 동적 파라미터로 조정 가능합니다. (default: 64MB) | chapter 6.1 |
| Temp Buffer Memory | Temporary 테이블에 사용 시, 임시로 할당되는 공간입니다. temp_buffers 동적 파라미터로 조정 가능합니다. (default: 8MB) | |
| Catalog Cache | System Catalog의 메타 데이터를 이용할 때 사용하는 메모리 영역입니다. 각 세션에서 조회하는 빈도가 높기 때문에 디스크에서 읽을 경우 성능 저하가 발생할 수 있어 로컬 메모리 영역을 사용합니다. | |
| Optimizer & Executor | Planner와 Executor에서 쿼리를 수행할 최적 플랜을 찾는 과정에서 사용하는 메모리 영역입니다. | chapter 3 |
로컬 메모리의 크기 중 몇몇 영역은 파라미터(temp_buffers, work_mem, maintenance_work_mem)로 조정이 가능합니다. 로컬 메모리는 하나의 백엔드 프로세스가 할당받는 영역이므로 커넥션의 갯수를 고려하여 적절한 값을 설정하는 것이 좋습니다. 다음은 로컬 메모리 중 Work Memory를 조정하는 예시입니다.
SET work_mem = ’16MB’; — 세션 단위 조정
SET LOCAL work_mem = ’16MB’; — 트랜잭션 단위 조정
RESET work_mem; — 리셋
공유 메모리 영역 (Shared Memory Area)
공유 메모리는 PostgreSQL 서버의 모든 프로세스와 공유되는 공간으로 데이터 블록, 트랜잭션 로그 등 여러 프로세스에서 공유가 필요한 정보를 저장하는 공간으로 사용됩니다. 공유 메모리는 PostgreSQL 서버가 기동될 때 시스템 메모리에서 할당받고 종료될 때 다시 시스템 메모리로 반환됩니다. 공유 메모리의 각 영역에 대한 설명은 다음과 같습니다.
공유 메모리 영역 목록
| sub-area | description | references |
| Shared Buffer pool | 데이터와 데이터의 변경사항을 page 단위로 캐싱하여 I/O 를 빠르게 처리하기 위한 영역입니다. shared_buffers 정적 파라미터로 조정이 가능합니다. (default: 128MB) | chapter 8 |
| WAL buffer | 각 세션 에서 수행되는 트랜잭션에 대한 변경 로그를 캐싱하여 Recovery 작업 수행 시, 데이터를 재구성 할 수 있도록합니다. wal_buffers 정적 파라미터로 조정이 가능합니다. | chapter 9 |
| Commit log Buffer | 각 트랜잭션의 상태 정보를 캐싱하는 공간입니다. | chapter 5.4 |
Reference.
https://www.postgresql.org/docs/current/runtime-config-resource.html
https://www.interdb.jp/pg/pgsql02.html
지금까지 PostgreSQL의 프로세스와 메모리 아키텍처에 관해 알아보았습니다
‘ PostgreSQL의 쿼리 엔진_ Overview’편을 바로 이어서 확인해보세요!
