EPAS 및 PostgreSQL 데이터베이스 서버를 Linux에서 구성 및 튜닝하기

Lætitia Avrot
2024년 8월 1일

EDB Postgres Advanced Server(EPAS) 및 PostgreSQL을 Linux에서 최적화할 수 있는 구성 및 튜닝 권장 사항을 확인하세요.

이 튜닝 가이드는 2020년에 Dave Page, Devrim Günduz, Shaun Thomas, Stacy Scoggins, Vibhor Kumar, Vik Fearing이 작성한 원본을 기반으로 합니다.

2024년 업데이트 버전은 Lætitia Avrot와 Vibhor Kumar가 작성했습니다.

이 권장 사항은 시작점으로, 벤치마크 및 기타 측정 작업이 추가로 필요합니다. 이는 모든 구성 설정을 다룬 포괄적인 목록이 아니며, 기본값으로 설정되지 않은 가장 중요한 매개변수 설정만을 포함합니다.

최적의 튜닝을 위해 EDB의 전문 서비스 팀 또는 EDB의 공인 파트너와 협력하세요.

강력한 PostgreSQL 서버 설계하기

다음 내용은 베어메탈 서버와 가상 머신(VM)에 초점을 맞추고 있습니다. 향후 버전에서는 클라우드 및 컨테이너화된 설계가 포함될 수 있습니다.

베어메탈

PostgreSQL용 베어메탈 서버를 설계할 때는 CPU, RAM, 디스크, 그리고 경우에 따라 네트워크 카드를 고려해야 합니다.

CPU

규모 데이터를 처리할 때 CPU 속도는 필수적이며, L3 캐시가 더 큰 CPU는 성능을 향상시킵니다. OLTP(온라인 트랜잭션 처리) 성능을 위해서는 더 많은 코어와 빠른 코어를 사용하면 운영 체제와 PostgreSQL의 효율성이 높아집니다.

CPU에는 최소한 두 가지 캐시가 있습니다: **L1 캐시(기본 캐시)**와 L2 캐시(보조 캐시).

• L1 캐시는 가장 작고 빠르며 CPU 코어에 내장되어 있습니다.
• L2 캐시는 L1보다 느리지만 더 크며, L1에 데이터를 공급하는 역할을 합니다.

L1과 L2는 각각의 코어에 독립적으로 존재하는 반면, L3 캐시는 모든 코어에서 공유됩니다.

• L3 캐시는 L1 및 L2보다 느리지만 RAM보다는 빠릅니다.
• 더 큰 L3 캐시는 대규모 데이터 세트를 처리할 때 CPU 성능을 높이며, PostgreSQL의 병렬 쿼리에서도 성능 이점을 제공합니다.

RAM

RAM은 가장 저렴한 하드웨어로, PostgreSQL 성능을 향상시키는 데 매우 유리합니다. 운영 체제는 사용 가능한 메모리를 최대한 활용하여 데이터를 캐시합니다. 더 많은 캐시는 디스크 I/O를 줄이고 쿼리 시간을 단축시킵니다.

새 하드웨어를 구입할 때는 가능한 한 많은 RAM을 추가하세요. 나중에 RAM을 추가하는 것은 경제적으로나 기술적으로 더 비용이 많이 들 수 있습니다(핫스왑 RAM이 없는 경우 다운타임이 필요). PostgreSQL의 여러 매개변수는 사용 가능한 메모리에 따라 조정됩니다.

Disk

애플리케이션이 I/O 중심적(읽기 및/또는 쓰기 집약적)이라면, 더 빠른 드라이브를 선택하면 성능이 크게 향상됩니다. NVMe 및 SSD 드라이브를 포함한 여러 솔루션이 가능합니다.

우선, WAL(Write-Ahead Logging) 디스크를 데이터 디스크와 분리하세요. WAL은 쓰기 집약적인 데이터베이스에서 병목현상이 될 수 있으므로, 이를 별도의 빠른 드라이브에 배치하십시오. 최소한 RAID 1을 사용하고, 데이터베이스 쓰기 작업이 많다면 RAID 10을 고려해야 합니다.

특히 PostgreSQL이 SATA 드라이브에서 실행되는 경우, 인덱스와 데이터를 별도의 테이블스페이스와 드라이브로 분리하면 성능이 향상됩니다. 그러나 SSD와 NVMe 드라이브에서는 이는 일반적으로 선택 사항입니다. 데이터 드라이브에는 RAID 10을 사용하는 것이 좋습니다.

네트워크 카드

네트워크 카드는 PostgreSQL 성능과 무관해 보일 수 있지만, 데이터가 크게 증가하면 더 빠르거나 본딩된 네트워크 카드를 사용하여 베이스 백업 속도를 높일 수 있습니다.

가상 머신(Virtual Machines)

가상 머신(VM)은 가상화 계층 때문에 베어메탈 서버에 비해 약간의 성능 저하가 있습니다. 또한, 공유 리소스 때문에 사용 가능한 CPU와 디스크 I/O 성능도 감소합니다.

VM에서 PostgreSQL 성능을 향상시키려면, VM을 특정 CPU와 디스크에 고정하세요. 이렇게 하면 호스트 머신에서 실행 중인 다른 VM으로 인한 성능 병목현상을 제거하거나 최소화할 수 있습니다.

설치 전에 디스크 공간을 사전 할당하여 데이터베이스 작업 중에 호스트가 디스크 공간을 동적으로 할당하지 않도록 하십시오. 만약 사전 할당이 불가능한 경우, PostgreSQL 설정 파일(postgresql.conf)에서 아래 두 가지 매개변수를 변경할 수 있습니다.

1. wal_recycle 매개변수 비활성화
   PostgreSQL은 기본적으로 WAL 파일을 이름 변경 방식으로 재활용합니다. 그러나 Copy-On-Write(COW) 파일 시스템에서는 새 WAL 파일을 생성하는 것이 더 빠를 수 있습니다. 이 매개변수를 비활성화하면 성능이 향상됩니다.
2. wal_init_zero 매개변수 비활성화
   PostgreSQL은 기본적으로 WAL 레코드가 삽입되기 전에 WAL 공간을 미리 할당합니다. 이 과정은 COW 파일 시스템에서 WAL 작업 속도를 저하시킵니다. 이 매개변수를 비활성화하면 VM 성능이 향상됩니다. 이 값을 “off”로 설정하면 파일 생성 시 최종 바이트만 기록되어 예상 크기를 보장합니다. 단, 이는 디스크 공간이 사전 할당된 경우에만 효과적입니다.

EPAS 및 PostgreSQL 서버를 위한 운영 체제 설정 팁

마운트 포인트(Mount Points)

EPAS/PG 클러스터를 위해 전용 **IOPS(Input/Output Operations Per Second)**를 가진 별도의 마운트 포인트를 사용하세요. 성능 향상을 위해 SSD를 사용하는 것이 좋습니다.

1. /pgdata/16: EPAS/PG 데이터 디렉터리를 위한 마운트 포인트.
   • PGDATA 디렉터리 경로: /pgdata/16/data
2. /pgwaldata/16: **WAL(Write Ahead Log)**을 위한 마운트 포인트.
   • WAL 디렉터리 경로: /pgwaldata/16/wal

사용자 정의 테이블에 필요한 인덱스 사용량 및 인덱스의 양에 따라 워크로드별로 인덱스를 위한 별도의 마운트 포인트를 구성하는 것이 좋습니다.

PostgreSQL 로그 디렉터리(/PGDATA/log 기본값)는 다른 프로세스나 사용자가 접근할 수 있도록 올바른 권한을 설정하여 별도의 마운트 포인트에 배치하세요.

파일 시스템(Filesystem)

PG/EPAS 데이터 디렉터리, WAL, 및 기타 PG/EPAS 데이터를 호스팅하는 마운트 포인트에는 XFS 파일 시스템을 사용하세요.

atime

PostgreSQL은 데이터 파일에 대해 atime(파일이 마지막으로 액세스된 시간의 타임스탬프)을 사용하지 않으므로, 이를 비활성화하면 CPU 사용을 절약할 수 있습니다.

PostgreSQL 데이터 및 WAL 파일이 저장된 드라이브의 defaults 값 근처에 **noatime**을 추가하세요.

/dev/mapper/pgdata-01-data /pgdata xfs defaults,noatime 1 1

다음 명령어를 실행하여 설정을 즉시 활성화하세요.

mount -o remount,noatime,nodiratime /pgdata

이 설정은 초기 단계에 적합하며, 운영 체제와 PostgreSQL을 지속적으로 모니터링하여 세부적인 튜닝을 위한 데이터를 수집하세요.

Read-ahead

디스크 Read-ahead 값을 증가시키면 디스크 요청 횟수를 줄여 I/O 처리량을 개선할 수 있습니다. 기본값은 일반적으로 128 kB로 설정되어 있지만, 데이터베이스 또는 테이블스페이스를 호스팅하는 디스크에서는 4,096 kB로 설정하는 것이 좋습니다.

아래와 같이 tuned 데몬을 사용하여 Read-ahead 매개변수를 조정할 수 있습니다.

I/O 스케줄러

CentOS/RHEL 7에서는 deadline I/O 스케줄러를, Rocky/RHEL 8에서는 mq-deadline을 사용하세요.

만약 시스템이 **SSD(솔리드 스테이트 스토리지)**를 사용하거나 자체 재정렬 메커니즘이 있는 전용 I/O 컨트롤러를 사용하는 경우, RHEL 7에서는 noop, RHEL 8에서는 none 스케줄러를 사용하는 것이 좋습니다.

더티 메모리(Dirty Memory)

현대 Linux 시스템에서는 더티 메모리(수정되었지만 아직 디스크에 커밋되지 않은 메모리)를 전체 RAM 크기의 비율로 정의합니다. 특정 비율 이상의 메모리가 수정되면, 시스템은 순차 접근 모드로 전환되며, 디스크에 더티 메모리를 플러시하는 작업과 관련되지 않은 모든 I/O 요청이 차단됩니다. 이러한 상황은 성능에 큰 영향을 미칠 수 있습니다. 특히 데이터베이스의 쓰기 패턴에서는 데이터 양이 증가할수록 이러한 문제가 발생할 가능성이 높아집니다.

현대 하드웨어 및 일부 VM에서는 시스템 RAM의 1%만으로도 저장 장치가 감당할 수 없는 데이터가 생성될 수 있으며, 이는 심각한 I/O 대기 시간을 초래할 수 있습니다. 이러한 이유로, 최신 Linux 커널은 더티 메모리를 비율이 아닌 바이트 단위로 설정할 수 있습니다.

권장 설정값은 기본 스토리지 장치나 컨트롤러의 캐시 크기 수준이어야 합니다. 이러한 값을 알 수 없는 경우 1GB로 설정하는 것이 적절합니다.

또한, 현재 Linux 시스템은 vm.dirty_background_ratio로 정의된 임계값을 초과한 경우에만 백그라운드에서 더티 메모리를 디스크에 기록하는 경향이 있습니다. 기본값은 RAM의 5~10% 수준이며, 1% 이상으로 설정되어 있습니다.

최신 커널에서는 vm.dirty_background_bytes를 사용하여 백그라운드 쓰기 임계값을 바이트 단위로 설정할 수도 있습니다.

이 값은 vm.dirty_bytes로 지정한 값의 1/4 수준으로 설정하는 것이 일반적입니다. 이렇게 하면 디스크 서브시스템으로 데이터를 미리 조금씩 전달하여 vm.dirty_bytes에서 지정한 임계값에 도달하기 훨씬 전에 쓰기가 시작됩니다. 이로 인해 값이 너무 작게 설정되었을 때 발생할 수 있는 과도한 백그라운드 쓰기를 방지할 수 있습니다.

대부분의 스토리지 서브시스템 캐시는 약 1~4GB 수준으로 매우 크지 않기 때문에, 스토리지 부하를 피하면서 백그라운드 쓰기를 촉진하는 것이 중요합니다.

vm.dirty_bytes의 1/4 수준으로 vm.dirty_background_bytes를 설정하고, 환경에 따라 값을 조정할 수 있습니다.

더 큰 캐시가 있는 경우, vm.dirty_background_bytes는 vm.dirty_bytes에 비례하여 더 작은 값으로 설정될 수 있습니다.

기타 운영 체제 매개변수

아래는 EPAS/PostgreSQL을 위해 Linux 운영 체제를 튜닝할 때 사용할 수 있는 EDB의 권장 사항입니다. 위의 지침을 참고하여 설정하세요:

mkdir /etc/tuned/edb



export DIRTY_BYTES=$((1024*1024*1024))

export DIRTY_BG=$((${DIRTY_BYTES}/4))

export MEM_TOTAL=$(grep MemTotal /proc/meminfo | awk '{print $2}')



cat</etc/tuned/edb/tuned.conf

[main]

summary=Tuned profiles for EnterpriseDB Postgres Advanced Server

[cpu]

governor=performance

energy_perf_bias=performance

min_perf_pct=100

[disk]

readahead=4096

[sysctl]

vm.overcommit_memory=2

vm.overcommit_kbytes=${MEM_TOTAL}

vm.swappiness=1

vm.dirty_bytes=${DIRTY_BYTES}

vm.dirty_background_bytes=${DIRTY_BG}

[vm]

transparent_hugepages=never

EOF



systemctl enable --now

tuned-adm profile edb

EPAS/PG 클러스터 초기화

다음 initdb 명령어를 사용하여 EPAS PGDATA 폴더를 부트스트랩합니다:

PGSETUP_INITDB_OPTIONS="-X /pgwaldata/16/wal --pgdata=/pgdata/16/data"

/usr/edb/as16/bin/edb-as16-setup initdb

systemctl을 사용하여 서비스 파일을 확장합니다:

systemctl edit edb-as-16

편집 창에 아래 내용을 추가합니다:

[Service]

Environment=PGDATA=/pgdata/16/data

저장 후 종료하고, 서비스를 활성화하고 시작합니다:

systemctl enable --now edb-as-16

시스템의 systemd 서비스 파일을 수정하지 않고 PostgreSQL 설치 디렉터리의 기본 데이터 디렉터리 위치에 대해 PGDATA에 대한 심볼릭 링크를 생성하는 것도 권장됩니다:

sudo -u enterprisedb rmdir /var/lib/edb/as16/data

sudo -u enterprisedb ln -s /pgdata/16/data /var/lib/edb/as16/data

systemctl enable --now edb-as-16

데이터베이스 서버 설정 및 인증

max_connections

max_connections의 최적값은 CPU 코어 수의 4배입니다.
그러나 이 값은 현실적인 상황에서 너무 작을 수 있습니다.
대신, 다음 공식을 사용하는 것이 좋습니다:plaintext코드 복사GREATEST(4 x CPU 코어 수, 100)

위 값을 초과하는 경우, pgbouncer와 같은 연결 풀러를 사용하는 것을 권장합니다.

password_encryption

이 매개변수는 scram-sha-256으로 설정하는 것이 권장됩니다.

Linux에서 PostgreSQL의 리소스 사용

shared_buffers

이 매개변수는 작업 부하에 따라 가장 큰 차이를 보입니다.

일부 작업 부하는 데이터베이스 볼륨이 매우 크더라도 1GB 또는 2GB와 같은 작은 값에서 최상의 성능을 발휘합니다.

다른 작업 부하에서는 큰 값이 필요할 수 있습니다.

합리적인 시작점은 전체 RAM / 4이며, 더 세밀한 설정은 RAM의 변동성을 반영한 아래의 의사 코드(pseudo-code)를 기반으로 할 수 있습니다:

base = RAM / 4



if RAM < 3 GB:

    base = base * 0.5

else if RAM < 8 GB:

    base = base * 0.75

else if RAM > 64 GB:

    base = greatest(16 GB, RAM / 6)



shared_buffers = least(base, 64 GB)

이는 메모리가 적은 시스템이 PostgreSQL의 shared_buffers에 높은 메모리를 할당했을 때 발생할 수 있는 부담을 줄이는 동시에 사용자 세션을 처리할 수 있도록 조정한 설정입니다.

반면, RAM 용량이 훨씬 많은 서버는 비례적으로 조정된 shared_buffers 설정을 충분히 흡수할 수 있습니다.
그러나 64GB를 초과하는 설정에서는, 큰 연속 메모리 할당을 유지하는 데 따른 오버헤드로 인해 성능 향상의 한계가 나타날 수 있습니다.

work_mem

work_mem의 권장 시작점은 다음과 같습니다:

((전체 RAM - shared_buffers) / (16 x CPU 코어 수))

maintenance_work_mem

이 매개변수는 VACUUM, CREATE INDEX, ALTER TABLE, ADD FOREIGN KEY, 데이터 로드 작업과 같은 유지 관리 작업에서 사용할 최대 메모리 양을 결정합니다. 이러한 작업은 데이터베이스 서버의 I/O를 증가시킬 수 있으므로, 더 많은 메모리를 할당하면 작업이 더 빨리 완료될 수 있습니다.

권장 시작값은 다음과 같습니다:

15% x (전체 RAM - shared_buffers) / autovacuum_max_workers (최대 1GB까지)

effective_io_concurrency

이 매개변수는 특정 작업에서 Read-ahead를 위해 사용되며, 데이터가 저장된 디스크의 개수로 설정해야 합니다.
하지만 디스크 개수의 배수를 사용하는 경우 성능이 향상되는 경우도 있습니다.
**SSD(솔리드 스테이트 디스크)**를 사용하는 경우, 이 값을 200으로 설정하는 것이 좋습니다.

Postgres 서버 Write-Ahead Logs(WAL)를 위한 매개변수

wal_compression

이 매개변수를 활성화하면, full_page_writes가 켜져 있거나 기본 백업 중일 때 PostgreSQL 서버가 WAL에 기록된 전체 페이지 이미지를 압축합니다. 설정: "on"

wal_log_hints

pg_rewind를 사용하려면 이 매개변수가 필요합니다. 설정: "on"

참고: Postgres 인스턴스에 체크섬이 활성화된 경우, 이 설정은 항상 활성화된 것으로 간주됩니다.

wal_buffers

이 매개변수는 동기화 전에 WAL 데이터를 백엔드에서 저장할 수 있는 메모리 양을 제어합니다.

기본적으로 WAL 세그먼트 크기는 16MB로 설정되어 있으며, 세그먼트를 버퍼링하는 데 메모리 사용량은 적습니다. 더 큰 버퍼 크기는 성능에 긍정적인 영향을 미칠 수 있습니다. 설정: 64MB

checkpoint_timeout

더 긴 타임아웃은 WAL 볼륨을 줄이지만, 장애 복구 속도는 느려질 수 있습니다.

권장값: 최소 15분, 그러나 비즈니스 요구 사항의 **RPO(복구 목표 시점)**에 따라 달라질 수 있습니다.

checkpoint_completion_target

이 매개변수는 PostgreSQL이 체크포인트를 완료하려고 목표로 하는 시간을 결정합니다.

체크포인트가 I/O 스파이크를 유발하지 않고, 쓰기 작업이 일정 기간 동안 분산되도록 설정합니다.

권장값: 0.9

참고: PostgreSQL 13 이상 버전에서는 기본값이 0.9입니다.

max_wal_size

이 매개변수는 설정하기 까다로울 수 있습니다. 최적 값은 checkpoint_timeout과 시스템의 최대 WAL 처리량의 함수로 결정됩니다. 너무 작게 설정하면 성능이 크게 저하될 수 있으므로 신중히 조정해야 합니다. 너무 크게 설정하면 디스크 공간이 부족해질 위험이 있지만, 성능에는 영향을 미치지 않습니다.

참고: max_wal_size는 소프트 제한입니다.

설정 권장사항:

• 디스크 공간이 충분한 경우: WAL 용으로 수백 GB 이상의 공간이 있다면, 값을 높게 설정하세요. 고성능 시스템에서는 200GB 이상도 적절합니다.
• 디스크 공간이 제한된 경우: 가능한 한 높은 값으로 설정하여 여유 공간을 확보하고 디스크 공간 부족을 방지하세요.
• 전용 디스크 파티션 사용 시(권장): 파티션 크기의 **50~75%**로 설정하는 것이 적합합니다.

세부 조정을 위한 방법:

• pg_stat_bgwriter 뷰에서 **checkpoints_timed**와 checkpoints_req 값을 모니터링하세요.
• max_wal_size가 너무 작으면 요청된 체크포인트(requested checkpoints) 비율이 증가하며, 이는 다음 타임드 체크포인트에 도달하기에 필요한 WAL 세그먼트를 보관할 공간이 부족하다는 신호입니다.
• 활동이 일시적으로 급증하여 일부 요청된 체크포인트가 발생하는 것은 괜찮지만, 이것이 일반적인 상황이 되면 안 됩니다.
• 디스크 공간이 허용하는 한도 내에서 max_wal_size를 증가시켜 요청된 체크포인트 수를 최소화하세요.

archive_mode

이 매개변수를 변경하려면 서버를 재시작해야 하므로 **”on”**으로 설정하는 것이 좋습니다.

archive_command

archive_mode가 활성화된 경우, 유효한 **archive_command**를 지정해야 합니다.

아카이브 설정이 아직 준비되지 않은 경우, POSIX 시스템에서는 기본값인 **”: to be configured”**를 사용할 수 있습니다.

PostgreSQL 서버 쿼리 튜닝

random_page_cost

SSD 디스크를 사용하는 경우, 권장 값은 1.1입니다.

effective_cache_size

이 매개변수는 shared_buffers와 Linux 버퍼 캐시(예: free 명령의 buff/cache 열에서 확인 가능)의 합으로 설정해야 합니다.

cpu_tuple_cost

쿼리 중 각 행을 처리하는 데 드는 상대적인 비용을 지정합니다. 현재 기본값은 0.01로 설정되어 있지만, 이는 최적값보다 낮을 가능성이 있습니다.

보다 현실적인 비용 계산을 위해 값을 0.03으로 증가시키는 것이 좋습니다.

Postgres 서버 문제 보고 및 로깅

logging_collector

log_destination에 stderr 또는 csvlog가 포함된 경우, 이 매개변수를 **”on”**으로 설정합니다.

log_directory

logging_collector가 **”on”**이면, 로그 디렉터리를 데이터 디렉터리 외부에 설정하세요. 이렇게 하면 로그가 기본 백업의 일부로 포함되지 않습니다.

log_checkpoints

이 매개변수를 **”on”**으로 설정하세요.

log_min_duration_statement

성능이 낮은 쿼리를 조기에 식별하기 위해, 이 매개변수를 1초로 설정하여 1초 이상 실행되는 쿼리를 기록합니다.

초기값으로 적합하지만, 너무 길다면 더 높은 값으로 설정한 후 더 느린 쿼리를 수정한 다음 값을 줄이는 것이 좋습니다.

트랜잭션 작업에서 250ms 이상의 쿼리는 느린 것으로 간주될 수 있습니다. 하지만 비즈니스 분석과 같은 다른 워크로드에서는 5초 이상의 쿼리도 느리지 않을 수 있습니다.

log_line_prefix

로그에 포함될 접두사는 최소한 시간, 프로세스 ID, 행 번호, 사용자 및 데이터베이스 정보, 애플리케이션 이름을 포함해야 합니다.

권장 값:'%m [%p]: u=[%u] db=[%d] app=[%a] c=[%h] s=[%c:%l] tx=[%v:%x] '

*주의: 끝에 공백을 포함하는 것을 잊지 마세요.

log_lock_waits

이 매개변수를 **”on”**으로 설정하세요. 이는 느린 쿼리를 진단하는 데 필수적입니다.

log_statement

이 매개변수를 **”ddl”**로 설정하세요.

기본 감사 기록을 남기는 것 외에도, 잘못된 테이블 삭제와 같은 치명적인 실수를 파악하는 데 도움이 됩니다.

log_temp_files

이 매개변수를 **”0″**으로 설정하세요.

이는 생성된 모든 임시 파일을 기록하며, work_mem이 잘못 설정되었음을 나타낼 수 있습니다.

log_connections

이 매개변수를 **”on”**으로 설정하세요.

모든 연결을 기록하며, 보안 목적으로 유용하고 연결 풀러가 필요한지 또는 올바르게 설정되었는지 확인하는 데 도움이 됩니다.

log_disconnections

이 매개변수를 **”on”**으로 설정하세요.

모든 연결 종료를 기록합니다.

timed_statistics (EPAS)

DRITA(동적 런타임 도구 아키텍처) 기능의 타이밍 데이터 수집을 제어합니다.

이 매개변수를 **”on”**으로 설정하여 데이터를 수집하기 시작합니다.

Linux에서 PostgreSQL의 Autovacuum 프로세스 모니터링

log_autovacuum_min_duration

Autovacuum 활동을 모니터링하면 이를 조정하는 데 도움이 됩니다.

권장 값: 0 (모든 Autovacuum 활동을 기록)

autovacuum_max_workers

Autovacuum 작업자 수를 설정합니다.

기본값은 3이며, 변경하려면 데이터베이스 재시작이 필요합니다.

각 테이블은 하나의 작업자만 사용할 수 있으므로, 작업자 수를 늘리면 테이블 간 병렬 작업과 더 빈번한 Vacuum에 유용합니다.

기본값은 낮은 편이므로, 5로 늘리는 것이 좋습니다.

autovacuum_vacuum_cost_limit

Autovacuum으로 인해 데이터베이스에 과도한 부하가 걸리지 않도록, PostgreSQL은 I/O 할당량을 제한합니다.

각 읽기/쓰기 작업은 이 할당량을 소모하며, 할당량이 소진되면 Autovacuum은 고정된 시간 동안 대기합니다.

이 설정은 할당량 한도를 늘려 Vacuum이 수행할 수 있는 I/O 양을 증가시킵니다.

기본값은 낮은 편이므로, 5,000으로 늘리는 것이 권장됩니다.

EPAS 및 PostgreSQL 서버의 클라이언트 연결 기본값

idle_in_transaction_session_timeout

트랜잭션에서 유휴 상태로 남아 있는 세션은 잠금을 유지하고 Vacuum 작업을 방해할 수 있습니다.

권장 값: 10분

lc_messages

로그 분석기는 번역되지 않은 메시지만 이해할 수 있습니다.

설정: “C”

shared_preload_libraries

pg_stat_statements를 추가하면 오버헤드는 적지만 가치가 높습니다.

권장 사항: 선택 사항이지만 활성화하는 것을 권장합니다.

본문: Configure and Tune EPAS and PostgreSQL Database Servers on Linux

이메일: salesinquiry@enterprisedb.com