Linux에서 EPAS 및 PostgreSQL 데이터베이스 서버 구성 및 튜닝
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 서버 설계하기
아래 내용은 PostgreSQL용 베어메탈 서버 및 가상 머신(VM) 환경에 초점을 맞춥니다. (향후 버전에서 클라우드 및 컨테이너 환경 설계가 추가될 수 있습니다.)
베어메탈 서버
베어메탈 서버를 설계할 때는 CPU, RAM, 디스크, 그리고 경우에 따라 네트워크 카드를 고려해야 합니다.
CPU 선택
CPU 선택은 성능 최적화의 핵심 요소입니다. 대규모 데이터를 처리할 때 CPU 속도는 필수이며, L3 캐시가 큰 CPU일수록 성능이 향상됩니다. OLTP(온라인 트랜잭션 처리) 성능을 위해서는 코어 수가 많고 각 코어가 빠를수록 운영체제와 PostgreSQL의 효율이 높아집니다.
CPU에는 최소 두 종류의 캐시가 있습니다.
- L1 캐시(기본 캐시): 가장 작고 빠르며 CPU 코어에 내장되어 있습니다.
- L2 캐시(보조 캐시): L1보다 느리지만 더 크며, L1에 데이터를 공급합니다.
L1과 L2는 각 코어에 독립적으로 존재하는 반면, L3 캐시는 모든 코어가 공유합니다. L3는 L1·L2보다 느리지만 RAM보다는 빠릅니다. 병렬 쿼리 처리 시 코어 간 공유되는 L3 캐시 크기가 성능에 직접적인 영향을 주므로, L3 캐시가 큰 CPU는 대규모 데이터 세트와 병렬 쿼리 모두에서 이점을 제공합니다.
RAM 관리
Linux에서 PostgreSQL 성능을 극대화하려면 RAM이 가장 중요합니다. 운영체제는 사용 가능한 메모리를 최대한 활용해 데이터를 캐시하며, 캐시가 많을수록 디스크 I/O가 줄고 쿼리 시간이 단축됩니다.
새 하드웨어를 구입할 때는 가능한 한 많은 RAM을 확보하세요. 나중에 RAM을 추가하는 것은 경제적·기술적으로 더 비쌀 수 있습니다(핫스왑 RAM이 없다면 다운타임 필요). PostgreSQL의 여러 매개변수가 사용 가능한 메모리에 따라 조정됩니다.
디스크 최적화
애플리케이션이 I/O 중심(읽기·쓰기 집약적)이라면 더 빠른 드라이브가 성능을 크게 끌어올립니다. NVMe, SSD 등 여러 선택지가 있습니다.
- WAL 디스크 분리: WAL(Write-Ahead Logging)은 반드시 데이터 디스크와 분리하세요. 쓰기 집약적 환경에서 병목이 될 수 있으므로 별도의 빠른 드라이브에 배치합니다. 최소 RAID 1을 사용하고, 쓰기 작업이 많다면 RAID 10을 고려하세요.
- 인덱스·데이터 분리: 특히 SATA 드라이브에서 실행하는 경우, 인덱스와 데이터를 별도의 테이블스페이스·드라이브로 분리하면 성능이 향상됩니다. 다만 SSD·NVMe에서는 일반적으로 선택 사항입니다. 데이터 드라이브에는 RAID 10을 권장합니다.
네트워크 설정
네트워크 튜닝은 백업·복제 성능을 좌우합니다. 데이터가 크게 늘어나면 더 빠르거나 본딩된(bonded) 네트워크 카드를 사용해 베이스 백업 속도를 높일 수 있습니다.
가상 머신(VM)
VM은 가상화 계층 때문에 베어메탈 대비 약간의 성능 저하가 있고, 공유 리소스로 인해 가용 CPU와 디스크 I/O 성능도 줄어듭니다.
성능을 높이려면 **CPU와 디스크를 호스트에 고정(pinning)**하세요. 호스트에서 실행 중인 다른 VM으로 인한 병목을 제거하거나 최소화할 수 있습니다. 또한 설치 전에 디스크 공간을 사전 할당하여, 데이터베이스 작업 중 호스트가 디스크 공간을 동적으로 할당하지 않도록 합니다.
사전 할당이 불가능하다면, postgresql.conf에서 아래 두 매개변수를 조정할 수 있습니다.
wal_recycle비활성화 — PostgreSQL은 기본적으로 WAL 파일을 이름 변경 방식으로 재활용하지만, Copy-On-Write(COW) 파일 시스템에서는 새 WAL 파일을 생성하는 편이 더 빠를 수 있습니다. 비활성화하면 성능이 향상됩니다.wal_init_zero비활성화 — PostgreSQL은 기본적으로 WAL 레코드 삽입 전에 WAL 공간을 미리 할당하는데, 이 과정이 COW 파일 시스템에서 WAL 작업 속도를 떨어뜨립니다.off로 설정하면 파일 생성 시 최종 바이트만 기록해 예상 크기를 보장합니다(단, 디스크 공간이 사전 할당된 경우에만 효과적).
운영체제 설정
마운트 포인트
전용 **IOPS(Input/Output Operations Per Second)**를 가진 별도의 마운트 포인트를 사용하고, 성능을 위해 SSD를 권장합니다.
/pgdata/16— EPAS/PG 데이터 디렉터리용 마운트 포인트 (PGDATA 경로:/pgdata/16/data)/pgwaldata/16— WAL(Write-Ahead Log)용 마운트 포인트 (WAL 경로:/pgwaldata/16/wal)
인덱스 사용량과 양에 따라, 워크로드별로 인덱스를 위한 별도 마운트 포인트를 구성하는 것이 좋습니다. 로그 디렉터리(기본값 /PGDATA/log)는 다른 프로세스·사용자가 접근할 수 있도록 올바른 권한을 부여한 별도 마운트 포인트에 배치하세요.
파일 시스템
PG/EPAS 데이터 디렉터리, WAL, 기타 데이터를 호스팅하는 마운트 포인트에는 XFS 파일 시스템을 사용하세요.
atime 비활성화
PostgreSQL은 데이터 파일에 atime(마지막 액세스 시각 타임스탬프)을 사용하지 않으므로, 이를 비활성화하면 CPU를 절약할 수 있습니다. 데이터·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 처리량을 개선할 수 있습니다. 기본값은 보통 128kB이지만, 데이터베이스·테이블스페이스를 호스팅하는 디스크에서는 4,096kB를 권장합니다. (아래 tuned 데몬 설정으로 조정할 수 있습니다.)
I/O 스케줄러
- CentOS/RHEL 7 →
deadline - Rocky/RHEL 8 →
mq-deadline - SSD를 사용하거나 자체 재정렬 메커니즘이 있는 전용 I/O 컨트롤러를 쓰는 경우 → RHEL 7은
noop, RHEL 8은none
더티 메모리(Dirty Memory)
더티 메모리(수정됐지만 아직 디스크에 커밋되지 않은 메모리)는 최신 시스템에서 RAM 대비 비율로 정의됩니다. 일정 비율 이상 수정되면 시스템이 순차 접근 모드로 전환되고, 더티 메모리 플러시와 무관한 모든 I/O 요청이 차단되어 성능에 큰 영향을 줍니다. 쓰기 패턴이 강한 데이터베이스에서 데이터가 늘수록 발생 가능성이 높아집니다.
최신 하드웨어·일부 VM에서는 RAM의 1%만으로도 스토리지가 감당하기 어려운 데이터가 생겨 심각한 I/O 대기가 발생할 수 있습니다. 그래서 최신 Linux 커널은 더티 메모리를 비율이 아닌 바이트 단위로 설정할 수 있습니다.
vm.dirty_bytes— 권장값은 기본 스토리지 장치·컨트롤러의 캐시 크기 수준입니다. 값을 알 수 없다면 1GB가 적절합니다.vm.dirty_background_bytes— 백그라운드 쓰기 임계값으로, 보통vm.dirty_bytes의 1/4 수준으로 설정합니다. 이렇게 하면 임계값에 도달하기 훨씬 전에 데이터를 조금씩 미리 디스크로 내보내, 값이 너무 작을 때 생기는 과도한 백그라운드 쓰기를 방지합니다.
대부분의 스토리지 캐시는 약 1~4GB로 크지 않으므로, 스토리지 부하를 피하면서 백그라운드 쓰기를 촉진하는 것이 중요합니다. 캐시가 더 크다면 vm.dirty_background_bytes를 vm.dirty_bytes 대비 더 작은 비율로 설정할 수 있습니다.
권장 tuned 프로파일
아래는 EPAS/PostgreSQL을 위한 EDB의 Linux 튜닝 권장 설정입니다.
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_ratio=80
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 서비스 파일을 수정하지 않고, 기본 데이터 디렉터리 위치에 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 — 최적값은 CPU 코어 수의 4배이지만, 현실적으로는 너무 작을 수 있습니다. 다음 공식을 권장합니다.
GREATEST(4 × CPU 코어 수, 100)
이 값을 초과해야 한다면 pgbouncer 같은 연결 풀러 사용을 권장합니다. 반대로 그렇게 많은 연결이 필요 없다면 값을 낮추세요.
password_encryption — scram-sha-256으로 설정하세요.
리소스 사용
shared_buffers — 워크로드에 따라 가장 큰 차이를 보이는 매개변수입니다. 어떤 워크로드는 데이터 볼륨이 매우 커도 1~2GB 같은 작은 값에서 최상의 성능을 내고, 어떤 워크로드는 큰 값이 필요합니다. 합리적인 시작점은 전체 RAM / 4이며, RAM 규모를 반영한 세부 설정은 아래 의사코드를 참고하세요.
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)
메모리가 적은 시스템의 부담을 줄이면서도 사용자 세션을 처리하도록 조정한 값입니다. RAM이 훨씬 많은 서버는 비례 조정된 설정을 충분히 흡수하지만, 64GB를 넘어서면 큰 연속 메모리 할당 유지에 따른 오버헤드로 성능 향상이 한계에 부딪힐 수 있습니다.
work_mem — 권장 시작점:
(전체 RAM − shared_buffers) / (16 × CPU 코어 수)
maintenance_work_mem — VACUUM, CREATE INDEX, ALTER TABLE, ADD FOREIGN KEY, 데이터 로드 같은 유지 관리 작업에 쓸 최대 메모리를 정합니다. 이런 작업은 I/O를 늘리므로, 메모리를 더 주면 더 빨리 끝납니다. 권장 시작값:
15% × (전체 RAM − shared_buffers) / autovacuum_max_workers (최대 1GB)
effective_io_concurrency — Read-ahead에 사용되며, 데이터가 저장된 디스크 개수로 설정합니다. 디스크 개수의 배수가 더 나은 경우도 있습니다. SSD를 쓰는 경우 200을 권장합니다.
WAL 최적화
wal_compression — full_page_writes가 켜져 있거나 베이스 백업 중일 때 WAL에 기록되는 전체 페이지 이미지를 압축합니다. 설정: on
wal_log_hints — pg_rewind에 필요합니다. 설정: on (체크섬이 활성화된 인스턴스에서는 항상 활성으로 간주)
wal_buffers — 동기화 전 백엔드에 WAL 데이터를 저장하는 메모리 양을 제어합니다. 기본 WAL 세그먼트 크기는 16MB이며 버퍼링에 필요한 메모리는 적습니다. 더 큰 버퍼는 성능에 긍정적일 수 있습니다. 설정: 64MB
checkpoint_timeout — 타임아웃이 길수록 WAL 볼륨은 줄지만 장애 복구는 느려집니다. 권장: 최소 15분 (단, 비즈니스의 RPO에 따라 조정).
checkpoint_completion_target — 체크포인트를 완료하려는 목표 시간으로, I/O 스파이크 없이 쓰기를 분산시킵니다. 권장: 0.9 (PostgreSQL 13 이상은 기본값 0.9)
max_wal_size — 설정이 까다로운 매개변수입니다. 최적값은 checkpoint_timeout과 시스템 최대 WAL 처리량의 함수입니다. 너무 작으면 성능이 크게 저하되고, 너무 크면 성능엔 영향이 없으나 디스크 부족 위험이 있습니다(소프트 제한).
- 디스크 공간이 충분하면(WAL용 수백 GB 이상) 값을 높게 설정하세요. 고성능 시스템에서는 200GB 이상도 적절합니다.
- 디스크 공간이 제한적이면 가능한 한 높게 설정해 여유를 확보하되 부족을 방지하세요.
- 전용 디스크 파티션 사용 시(권장) 파티션 크기의 **50~75%**가 적합합니다.
세부 조정: pg_stat_bgwriter 뷰에서 checkpoints_timed와 checkpoints_req를 모니터링하세요. max_wal_size가 너무 작으면 요청된 체크포인트(requested checkpoints) 비율이 올라가는데, 이는 다음 타임드 체크포인트까지 필요한 WAL 세그먼트를 보관할 공간이 부족하다는 신호입니다. 일시적 급증은 괜찮지만 상시화되면 안 되며, 디스크가 허용하는 범위에서 값을 늘려 요청된 체크포인트를 최소화하세요.
archive_mode — 변경 시 서버 재시작이 필요하므로 on으로 설정하는 것이 좋습니다.
archive_command — archive_mode가 켜져 있으면 유효한 명령을 지정해야 합니다. 아직 준비되지 않았다면 POSIX 시스템에서 기본값 : to be configured를 사용할 수 있습니다.
쿼리 튜닝
random_page_cost — SSD 디스크 사용 시 1.1을 권장합니다.
effective_cache_size — shared_buffers + Linux 버퍼 캐시(예: free 명령의 buff/cache 열)의 합으로 설정하세요.
cpu_tuple_cost — 쿼리 중 각 행 처리의 상대 비용입니다. 기본값 0.01은 최적값보다 낮을 가능성이 있으며, 보다 현실적인 비용 계산을 위해 0.03으로 조정하면 실행 계획 정확도가 개선됩니다.
로깅 및 문제 보고
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(동적 런타임 도구 아키텍처)의 타이밍 데이터 수집을 제어하던 파라미터입니다. 버전에 따라 동작이 다르므로 주의하세요.
- 16 이하: 데이터 수집을 시작하려면
on으로 설정합니다. - 17: DRITA 기능이 제거되었으나 파라미터만 남아 있으므로
off로 둡니다. - 18: 파라미터 자체가 제거되었습니다.
Autovacuum 모니터링
log_autovacuum_min_duration — Autovacuum 활동을 완전히 모니터링하려면 0(모든 활동 기록)으로 설정하세요.
autovacuum_max_workers — Autovacuum 작업자 수입니다(기본 3, 변경 시 재시작 필요). 각 테이블은 작업자 하나만 사용하므로, 수를 늘리면 테이블 간 병렬 작업과 더 빈번한 Vacuum에 유용합니다. 권장: 5
autovacuum_vacuum_cost_limit — 과부하를 막기 위해 PostgreSQL은 Autovacuum의 I/O 할당량을 제한합니다. 읽기/쓰기마다 할당량이 소모되고, 소진되면 고정 시간 동안 대기합니다. 이 한도를 늘리면 Vacuum이 수행할 수 있는 I/O가 늘어납니다. 기본값이 낮은 편이므로 5,000을 권장합니다.
클라이언트 연결 최적화
idle_in_transaction_session_timeout — 트랜잭션에서 유휴 상태로 남은 세션은 잠금을 유지하고 Vacuum을 방해할 수 있습니다. 권장: 10분 (잠금 경합 방지에 효과적)
lc_messages — 로그 분석기는 번역되지 않은 메시지만 이해합니다. 설정: C (로그 분석을 용이하게 함)
shared_preload_libraries — 성능 분석을 위해 pg_stat_statements를 추가하면 오버헤드는 적고 가치가 높습니다. 선택 사항이지만 활성화를 권장합니다.
PostgreSQL on Linux: 자주 묻는 질문(FAQ)
PostgreSQL을 Linux에서 쓸 수 있나요? 네. Linux는 PostgreSQL이 개발·테스트되는 대표적인 플랫폼 중 하나입니다. Ubuntu, CentOS, Fedora, Debian 등 다양한 배포판에서 사용할 수 있습니다.
왜 PostgreSQL에 Linux를 쓰나요? 많은 조직과 개발자가 PostgreSQL 운영체제로 Linux를 선호하는 이유는 다음과 같습니다.
- 서버 환경에서 특히 성능이 뛰어나, PostgreSQL이 높은 처리량과 낮은 지연을 낼 수 있습니다.
- 서버 배포에서 안정성과 신뢰성이 높습니다. 데이터베이스 운영에서 중단이나 크래시를 피하는 것이 핵심이므로 중요합니다.
- 사용자 권한, 접근 제어, 보안 패치, 파일 시스템 암호화 등 뛰어난 보안 기능을 갖췄습니다.
- Linux와 PostgreSQL 모두 오픈소스 철학을 공유하며, 커뮤니티 기여와 투명한 프로세스를 지향합니다.
- 자유롭게 사용·공유할 수 있어 비용을 절감합니다.
- 네트워크 설정, 시스템 리소스 최적화 등 PostgreSQL 성능을 위한 커스터마이징이 유연합니다.
- 클라우드 호환성이 높아 물리 인프라 없이도 PostgreSQL을 쉽게 쓸 수 있습니다.
PostgreSQL에 가장 좋은 Linux 배포판은? 필요와 취향에 따라 다릅니다.
- Ubuntu: 널리 쓰이며 커뮤니티가 크고 문서가 충실합니다.
- RHEL / CentOS: 안정성과 신뢰성으로 유명하며, 장기 지원과 보안 업데이트가 필요할 때 적합합니다.
- Debian: 안정성과 예측 가능성이 필요하다면 견고한 패키지 관리 시스템이 좋은 선택입니다.
- Fedora: 최신 기능과 업데이트를 지향한다면 더 혁신적인 선택지입니다.
- openSUSE: 유연성과 사용성으로 알려져 있고, 서버·데스크톱 환경 모두에서 동작합니다.
- Arch Linux: 최신 기능을 원하는 사용자를 위한 롤링 릴리스 모델로, 최신 소프트웨어 버전을 제공합니다.
Linux에서 Postgres는 어디에 설치되나요? 설정 파일은 보통 /etc/postgresql/<version>/main 디렉터리에 있습니다. 예를 들어 PostgreSQL 14를 설치했다면 설정 파일은 /etc/postgresql/14/main에 있습니다.
Linux에서 Postgres에 어떻게 접속하나요?
- 터미널을 엽니다.
psql명령에 연결 파라미터를 붙여 실행합니다. 기본 구문:psql -U username -d database_name -h hostname- 필요하면 비밀번호를 입력합니다.
mydatabase=#같은 프롬프트가 보이면 SQL 명령을 실행할 수 있습니다.
Linux에서 MySQL과 PostgreSQL의 차이는? MySQL은 단순함과 고성능에 더 집중하는 반면, PostgreSQL은 복잡한 쿼리, 트랜잭션 무결성, SQL 표준 준수에 강합니다. MySQL은 integer·varchar·text 등 비교적 단순한 데이터 타입을 지원하고, PostgreSQL은 배열·JSON·XML·기하 타입 등 더 폭넓고 고급한 타입을 지원합니다. MySQL은 SQL 표준을 부분적으로만 따르지만 PostgreSQL은 표준을 엄격히 준수합니다.
Linux에서 Postgres 데이터는 어디에 저장되나요? 데이터베이스·테이블·인덱스 파일이 저장되는 데이터 디렉터리는 보통 /var/lib/postgresql/{version}/main/에 있습니다. 다만 설치·설정 방식에 따라 위치가 달라질 수 있습니다.
Linux에서 Postgres 사용자를 어떻게 조회하나요?
- 터미널을 엽니다.
psql명령으로 PostgreSQL에 접속합니다(사용자·데이터베이스 지정이 필요할 수 있음).pg_roles테이블을 조회합니다. 예:SELECT rolname FROM pg_roles;
Linux에서 Postgres 버전을 어떻게 확인하나요? 세 가지 방법이 있습니다.
psql에 접속한 뒤SELECT version();조회.- 인터랙티브 셸 없이, 터미널에서
sudo -u postgres postgres --version실행. - 패키지 관리자로 확인. Ubuntu/Debian은
dpkg -l | grep postgresql, CentOS/Red Hat은yum list installed | grep postgresql.
Linux에서 Postgres 서버가 실행 중인지 어떻게 확인하나요? 다섯 가지 방법이 있습니다.
- systemd 사용 시:
systemctl status postgresql - 서버 상태만 확인:
pg_isready - 프로세스 필터링:
ps aux | grep postgres pg_ctl status -D /var/lib/postgresql/{version}/main(버전 번호로 교체)- 기본 포트 리스닝 확인:
sudo netstat -plnt | grep postgres또는sudo ss -ltn | grep postgres
Linux에서 Postgres 데이터베이스를 어떻게 종료하나요? 네 가지 방법이 있습니다.
- 패키지 관리자(apt/yum)로 설치한 경우:
sudo systemctl stop postgresql(시스템의 모든 클러스터 중지) - 여러 클러스터 실행 시:
sudo pg_ctlcluster {version} {cluster_name} stop - 구형 SysV-init:
sudo service postgresql stop sudo -u postgres pg_ctl -D /var/lib/postgresql/{version}/main stop(버전·데이터 디렉터리 경로 조정)
EDB Postgres AI 및 EPAS 튜닝, 더 알아보기
프로덕션 환경의 상세 튜닝이나 PoC가 궁금하시다면 EDB Korea로 문의해 주세요.
이메일: salesinquiry@enterprisedb.com
전화: 02-501-5113
본문: Configure and Tune EPAS and PostgreSQL Database Servers on Linux
이메일: salesinquiry@enterprisedb.com
